Zmiana wersji systemu operacyjnego w środowisku developerskim

[lgpawel]

Dobrze byłoby być niedługo gotowymi na uruchomienie SZ na nowszym systemie operacyjnym, niż obecnie, a na potrzeby naszych prac, ale też wstępnego etapu testowania kompatybilności należy też analogicznie zmienić środowisko developerskie. Wstępnie bawiłem się tym już dawno temu w #1563, a zmiany polegały na:

• wyborze boxu ubuntu/jammy64 zamiast ubuntu/focal64 w Vagrantfile
• podbiciu wersji PostgreSQL z 12 do 14 w infra/playbooks/dev/postgres.yml (i .github/workflows/test.yml)
• dodaniu zmiany uprawnień do katalogu domowego użytkownika vagrant na 775 w infra/playbooks/dev/playbook.yml
• podbiciu wersji pyyaml w zależnościach Pythonowych (choć ten pakiet chyba w ogóle nie jest już wykorzystywany w SZ i można go całkiem wykomentować, a docelowo zapewne zniknie też z master-dev EDIT: zdaje się, że jest potrzebny, choć niejawnie, do testów w aplikacji records) i wygląda na to, że przynajmniej postawienie i provisioning maszyny wirtualnej się udawały (co nie jest, rzecz jasna, kompletnym sukcesem).

W międzyczasie coś się niestety zepsuło, bo powyższe kroki (acz z inną wersją Vagranta, niż rok temu, ale – poza poboczną kwestią, o której niżej – poniższe problemy nie wyglądają na związane z tym) kończą się nieudanym provisioningiem, który nie daje się naprawić równie szybko, jak w przypadku problemów z pyyamlem. Konkretniej, nawet po podbiciu do najnowszych numerów wersji dla bokeh i typing_extensions ten pierwszy pakiet nie wydaje się być kompatybilny z zainstalowaną wersją numpy (2.coś, w bieżącej konfiguracji jest to 1.24.4), mimo że nie mamy go jawnie w zależnościach... A to może nie być jedyny, tylko pierwszy problematyczny pakiet.

Swoją drogą możliwe, że coś mamy nie najlepiej skonfigurowane, skoro tego rodzaju błędy (najwyraźniej wynikające z uruchamiania kodu pakietu, który jest stricte po to, żeby wyświetlać coś na stronach, i to dość nielicznych) pojawiają się przy provisioningu. Dobrze byłoby, gdyby udało się to przy okazji zdiagnozować i może zmienić. EDIT: podczas manage.py migrate importowane są wszystkie urls.py, a więc u nas pośrednio także bokeh i to przy samym tym imporcie pojawia się błąd.

"Poboczna kwestia" to komunikat wypisywany przy provisioningu:

Vagrant gathered an unknown Ansible version:


and falls back on the compatibility mode '1.8'.

Alternatively, the compatibility mode can be specified in your Vagrantfile:
https://www.vagrantup.com/docs/provisioning/ansible_common.html#compatibility_mode

(ten nadmiar złamań wierszy oznacza chyba, że "gathered [...] version" jest pustym napisem). Teraz czegoś takiego nie mamy (i to dla odmiany prawie na pewno jest z winy innej wersji Vagranta) i być może nie jest to (samo w sobie, w tej chwili) problemem, ale oczywiście dobrze byłoby nie zostawiać takich niewiadomych. Wersje ansible dla kompletności (choć winny jest raczej Vagrant) – w obecnej konfiguracji:

ansible 2.9.6
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/vagrant/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.10 (default, Sep 11 2024, 16:02:53) [GCC 9.4.0]

oraz przy próbie postawienia SZ na nowszym Ubuntu:

ansible 2.10.8
  config file = None
  configured module search path = ['/home/vagrant/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.10.12 (main, Sep 11 2024, 15:47:36) [GCC 11.4.0]