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
[freebsd:vars]
ansible_python_interpreter=/usr/local/bin/python3.7
ansible_perl_interpreter=/usr/local/bin/perl5
#ansible_shell_type=csh
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
[py39host:vars]
ansible_python_interpreter=/usr/local/bin/python3.9
ansible_perl_interpreter=/usr/local/bin/perl5
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.