FATBOZZ: Co presne ten modul dela? Z popisu na webu jsem to uplne nepochopil. To vytvori system wide symlink, nebo jen pro pouziti Ansible (v ansible home?)
A tim "install" se mysli, ze vytvori symlink, nebo ze to nainstaluje balik package managerem?

A tohle by se nehodilo ?
community.general.alternatives module – Manages alternative programs for common commands — Ansible Documentation
https://docs.ansible.com/ansible/latest/collections/community/general/alternatives_module.html

QUIP: OK sry, v *BSD nejsem zbehlej a na deb-based linuxu kde se vetsinou pohybuju je tohle soucasti python* balicku..

HEINZZ No to jsem popisoval tady QUIP. Da se to zaridit, aby tam symlinky byly, ale defaultne nejsou.
Ten muj konkretni pripad by to ted asi vyresilo nejjednodusim zpusobem.
Ale je pro me zajimave i zamysleni nad tou manipulaci s ansible_python_interpreter v ramci jednotlivych tasku v playbooku (tak nejak akademicky) :).

A neslo by si pro Ansible udelat dedikovany pyenv aby nebyl zavislej na systemovym Pythonu?

HEINZZ:

Hele a proč prostě nepoužít ..? *BSD nemá tyhle symlinky?

CHOROBA: No pokud ti neprojde zadny ansible task, protoze mas spatny python, tak z toho asi cesta nevede :) Ja bych to v mem pripade zjistoval jeste pred tim upgradem.

A nebo si udelas playbook, ktery postupne vyzkousi vsechny verze interpreteru, ktere prichazeji v uvahu :)

mi spis reknete, jak zjidtit ansiblem verzi pythonu, kdyz mi zjistovani verze pythonu zemre na spatny verzy pythonu ;-D

ZBYNEK: I nad tim jsem premyslel, on na to i existuje balicek, ktery tohle dela (tech symlinku je tam vic), ale je to pak symlink jen na jednu "defaultni" verzi Pythonu, zatim co tech verzi muze byt nainstalovanych nekolik soucasne (2.7, 3.7 - 3.11). Hlavne pri prechodu z 2.7 na 3. to byl docela problem, u tech 3.x uz to tak zasadni neni.

Cest je mnoho, staci si vybrat tu jednu spravnou :)

INDIAN: Jo, neco takoveho bych si predstavoval, jen jeste premyslim o tom, jak to rozsirit o nejake "podminky", abych tam nemusel mit natvrdo zadratovanou tu verzi, respektive jak pred taskem s "pkg upgrade" zjistit, ze se tentokrat bude menit i verze Pythonu a ze je teda potreba po provedeni "pkg upgrade" pretizit ansible_python_interpreter.

Zkratka tenhle playbook pro update poustim tak 2x do mesice, ale jen jednou za dva roky se zmeni verze Pythonu.

Ale mozna bude jednodussi, mit pro tenhle pripad samostatny specializovany playbook, prave pro to, ze se to deje jednou za dva roky, nez se snazit nejak vymyslet automatickou detekci a podminkovani.

QUIP: jestli sem to dobre pochopil, potrebujes po tom upgradu ihned pouzivat novou verzi interpreteru?
co ho jednoduse po tom upgradu pretizit?

Pouzivam Ansible pro nektere hromadne ukoly udrzby FreeBSD serveru (HW i virtualni) a mam tu takovy jeden problem pri upgrade verze Pythonu.

V hosts mam
V playbooku pro provedeni aktualizace balicku je nekolik tasku, jednim z nich je provedeni "pkg upgrade", jenze to ted spusti i aktualizaci Pythonu z 3.7 na 3.9, takze pro nasledujici task uz neni k dispozici ten definovany interpreter python3.7, takze nasledujici task v tom playbooku selze a je po legraci.

Pro stroje, ktere uz touhle aktualizaci prosly, mam pak dalsi skupinu Takze dalsi spusteni nejakeho playbooku uz funguje zase normalne, kdyz do te skupiny pridam ty prave zaktualizovane stroje.

Je to tak trochu "vejce nebo slepice" problem.
A jak to elegantne resit?
Napada me, ze pro tenhle pripad, kdy dochazi ke zmene verze Pythonu, budu muset mit jiny playbook, ktery uz nebude mit zadny dalsi task po provedeni "pkg ugprade" a k nemu dalsi playbook, ktery spustim az po tom upgrade a uprave hosts (ale ztraci to tu eleganci toho, ze playbook bude fungovat vzdy a sam - takhle ja budu muset predem "tusit", ze dochazi ke zmene verze Pythonu v repozitari balicku)

Nebo by slo detekovat tuhle zmenu pred jejim provedenim, po provedeni pkg upgrade provest zmenu v lokalnim hosts file dalsim taskem stejneho playbooku a pak pokracovat s dalsimi tasky s jinym interpreterem (da se tahle zmena ansible_python_interpreter provest a reflektovat uprostred nejakeho playbooku?)? Ale cele mi to prijde takove nejake neelegantni, navic kdyz je to neco, co se provede treba jednou za dva roky.

INDIAN: občas mám pocit, že se ve vyhledávání v Google točím pořád dokola na skoro stejných výsledcích ... a pak zkusím DuckDuckGo ... :-)

INDIAN: od nejakyho preposledniho? upgrade ansible z oficial repository mi prestal funkovat jumphost.
proste uplne ignoruje "-o " variables. netusim proc, ale zas me to nejak akutne netrapi, tak sem se v tom vic nehrabal

QUIP: jj, tenhle odkaz byl mezi prvnima, zkusil sem uz snad vsecko co sem dogooglil... bouzel v tyhle konfiguraci chodi cely hotovy reseni od dodavatele a jinak se na ty servery nedostanu
zkusim aspon jeste zjistit podrobnou SSH konfiguraci na obou serverech

INDIAN: Takhle to nepouzivam, takze osobni zkusenost nepredam (ja mam na stroji B i C stejny klic, tedy z agenta na A), ale tady nekdo resi stejnou situaci jako ty:
linux - SSH from A through B to C, using private key on B - Server Fault
https://serverfault.com/questions/337274/ssh-from-a-through-b-to-c-using-private-key-on-b