Compania Canonical a publicat o nouă versiune a sistemului de gestionare a containerelor LXD 5.20, care se remarcă prin schimbarea licenței proiectului și introducerea necesității semnării unui acord CLA privind transferul drepturilor de proprietate asupra codului în momentul acceptării modificărilor în LXD. Licența pentru codul adăugat în LXD de angajații Canonical a fost modificată de la Apache 2.0 la AGPLv3, iar codul participanților externi, pentru care Canonical nu are drepturi de proprietate, rămâne sub Apache 2.0. Deoarece Canonical nu are capacitatea de a schimba licența pentru tot codul LXD, proiectul va fi acum livrat sub condiții mixte - o parte din cod sub AGPLv3 și o parte sub Apache 2.0. Trecerea la noua licență este explicată de dorința de a unifica licența cu alte produse server Canonical care utilizează AGPLv3.
Codul versiunilor mai vechi rămâne, la fel ca înainte, disponibil sub licența Apache 2.0, dar toate modificările aduse componentelor relicențiate vor fi publicate numai sub licența AGPLv3, ceea ce va împiedica fork-ul Incus să transfere modificări din LXD fără a-și traduce baza de cod la licența AGPLv3. Licențele Apache 2.0 și AGPLv3 au o compatibilitate unidirecțională, care se reduce la faptul că codul sub licența Apache 2.0 poate fi inclus în codul sub licența AGPLv3, dar invers nu este posibil. Modificarea înseamnă încetarea completă a colaborării între proiectele LXD și Incus, deoarece transferul modificărilor din LXD în Incus este împiedicat de noua licență, iar din Incus în LXD necesitatea semnării acordului CLA, pe care dezvoltatorii Incus nu intenționează să-l semneze.
O caracteristică a licenței AGPLv3 este introducerea de restricții suplimentare pentru aplicațiile care asigură funcționarea serviciilor de rețea. Atunci când se utilizează componente AGPL în funcționarea serviciilor de rețea, dezvoltatorul este obligat să pună la dispoziția utilizatorului codul sursă al tuturor modificărilor aduse acestor componente, chiar dacă software-ul care stă la baza serviciului nu este distribuit și este utilizat exclusiv în infrastructura internă pentru organizarea funcționării serviciului. Licența AGPL impune, de asemenea, condiții de copyleft, adică pentru a include cod AGPL din LXD în propriul său proiect, baza de cod a propriului proiect trebuie să fie relicențiată sub licența AGPL.
LXD oferă instrumente pentru gestionarea centralizată a containerelor și mașinilor virtuale desfășurate într-un cluster format din mai multe servere. LXD este implementat ca un proces de fundal care acceptă cereri prin rețea prin intermediul API-ului REST și suportă diverse backend-uri de stocare (arbori de directoare, ZFS, Btrfs, LVM), snapshot-uri de stări, migrarea live a containerelor active de pe o mașină pe alta și instrumente pentru stocarea imaginilor containerelor. Ca runtime pentru executarea containerelor, se utilizează instrumentele LXC, care includ biblioteca liblxc, un set de utilitare (lxc-create, lxc-start, lxc-stop, lxc-ls etc.), șabloane pentru construirea containerelor și un set de legături pentru diferite limbaje de programare. Izolarea se realizează folosind mecanismele de bază ale nucleului Linux (spații de nume, cgroups, Apparmor, SELinux, Seccomp). Pe lângă LXC, în LXD sunt utilizate și componente de la proiectele CRIU și QEMU.
Printre funcționalitățile adăugate în LXD 5.20 se numără:
- În timpul creării grupurilor de stocare bazate pe Cephfs, a fost adăugată posibilitatea de a crea metadate și date pentru grupurile OSD (Object Storage Daemon), folosind parametrii cephfs.create_missing, cephfs.meta_pool și cephfs.data_pool. De exemplu: lxc storage create mypool cephfs source=cephfs \ cephfs.create_missing=true \ cephfs.data_pool=xyz_data \ cephfs.meta_pool=xyz_meta
- În pachetul snap LXD a fost adăugat la firmware-ul EDK2 suportul pentru configurarea priorității de boot de pe diferite discuri în modul security.csm.
- În firmware-ul EDK2 UEFI a fost adăugat modul de depanare (boot.debug_edk2=true) pentru diagnosticarea problemelor la bootare mașini virtuale. Jurnalul de depanare este salvat în fișierul $LXD_DIR/logs/<instance_name>/edk2.log.
- Codul de autorizare a fost transformat într-o bază modulară, ceea ce a permis suportul pentru OpenFGA, în plus față de autorizarea prin certificate TLS și Canonical RBAC.
- Pentru compilarea LXD este acum necesară o versiune minimă a limbajului Go 1.20.
- Supportul pentru Shiftfs a fost eliminat. Pentru maparea identificatorilor utilizatorilor, se recomandă utilizarea montării cu idmap, care este suportată pentru Ext4, XFS, Btrfs, ZFS și Cephfs.
- Supportul pentru firmware-urile UEFI cu dimensiunea de 2MB a fost eliminat (se recomandă utilizarea firmware-urilor cu dimensiunea de 4MB).
- Din codul sursă al fork-ului Incus a fost transferat suportul pentru crearea de stocări bazate pe tehnologia NVME. Pentru a specifica tipul de disc, a fost adăugat un nou parametru de configurare „io.bus”, care este setat în mod implicit la valoarea „virtio-scsi”. Când valoarea este schimbată în „nvme”, dispozitivul din mașina virtuală va fi vizibil ca NVME SSD.
- Din codul sursă al fork-ului Incus a fost transferat suportul pentru conectarea și deconectarea la cald (hot-plug/hot-remove) a căilor de fișiere sau a unor secțiuni individuale, trecute din mediu gazdă. În trecut, această redirecționare prin driverul virtio-fs sau FS 9p necesita oprirea mașinii virtuale. Pentru a evita această restricție, a fost utilizată capacitatea QEMU de a conecta PCI-dispozitive la cald și de a monta calea în cadrul sistemului guest prin incus-agent.
- Identificatorul dispozitivului org.linuxcontainers.lxd a fost redenumit în com.canonical.lxd (pentru a menține compatibilitatea înapoi, suportul pentru vechiul identificator a fost păstrat).
Sursa: opennet.ro
