LXD 5.20 llega con licencia AGPLv3, mejoras y mas

Logo de LXD

Logo de LXD

La nueva versión de LXD 5.20 ya fue liberada y presenta nuevas funciones y aspectos destacados tales como el cambio de licencia de Apache 2.0 a AGPLv3, soluciona el orden de dispositivos de arranque, asi como también la corrección de errores y más.

Para quienes desconocen de LXD, deben saber que esta es una herramienta que facilita la gestión centralizada de contenedores y máquinas virtuales en un clúster de servidores. Se presenta como un proceso en segundo plano que acepta solicitudes a través de la red mediante la API REST. Además, LXD ofrece soporte para varios backends de almacenamiento, que incluyen árbol de directorios, ZFS, Btrfs y LVM.

Entre las características clave de LXD se encuentran las snapshots con un segmento de estado, que permiten capturar y restaurar el estado de un contenedor en un momento específico. También ofrece la capacidad de migrar contenedores en ejecución de una máquina a otra sin interrupciones, así como herramientas para almacenar imágenes de contenedores.

¿Que hay de nuevo en LXD 5.20?

En esta nueva versión que se presenta de LXD 5.20, la principal novedad es él cambió de licencia del proyecto y la introducción de la necesidad de firmar un Acuerdo CLA sobre la transferencia de derechos de propiedad al código tras la aceptación de cambios en LXD.

La modificación de la licencia de Apache 2.0 a AGPLv3, representa un cambio significativo en los términos de distribución y uso del proyecto. Esta decisión se basa en el deseo de Canonical de unificar la licencia de LXD con otros productos de servidor que utilizan AGPLv3.

Como resultado de este cambio, el proyecto LXD se entregará bajo términos mixtos: parte del código estará bajo AGPLv3, mientras que el código de terceros sobre el cual Canonical no tiene derechos de propiedad permanecerá bajo Apache 2.0. Es importante destacar que Canonical no tiene la capacidad de cambiar la licencia para todo el código de LXD, por lo que se produce una división en los términos de licencia del proyecto.

La transición a esta nueva licencia implica que el código de versiones anteriores sigue disponible bajo la licencia Apache 2.0, pero los cambios realizados en componentes con la nueva licencia se publicarán únicamente bajo la licencia AGPLv3.

Canonical menciona que:

Es importante tener en cuenta que este cambio no impide que nuestros usuarios utilicen, modifiquen o proporcionen soluciones de software basadas en LXD, siempre que compartan el código fuente si lo modifican y lo ponen a disposición de otros. Las condiciones de la licencia están diseñadas para alentar a quienes buscan modificar el software a contribuir al proyecto y a la comunidad.

Aunque en realidad esto plantea desafíos para la cooperación entre proyectos, como Incus, ya que la licencia AGPLv3 impone restricciones que obstaculizan la transferencia de cambios de LXD a Incus y viceversa. La compatibilidad unidireccional entre las licencias Apache 2.0 y AGPLv3 agrega complejidad a la colaboración entre proyectos, ya que el código bajo la licencia Apache 2.0 puede incluirse en el código bajo la licencia AGPLv3, pero no al revés.

Por la parte de los cambios que se destacan de esta nueva versión de LXD 5.20 se encuentra la solución al orden de dispositivos de arranque CSM, ya que se agregó soporte al firmware EDK2 del paquete snap de LXD para respetar la configuración disk de los dispositivos boot.priority cuando se usa el modo security.csm. Anteriormente, esto causaba un problema al importar máquinas virtuales basadas en BIOS que no arrancaban usando UEFI porque el firmware de la máquina virtual intentaba arrancar los dispositivos UEFI primero, y esto significaba que el arranque de la red PXE se intentaba antes que el disco root basado en BIOS, lo que provocaba largos periodos de retrasos en el arranque.

Otro de los cambios que se destaca es el nuevo modo de depuración de problemas de arranque de VM, y es ahora es posible iniciar VM con firmware UEFI de EDK2  (boot.debug_edk2=true). El registro de depuración se guarda en el archivo $LXD_DIR/logs/<instance_name>/edk2.log.

Ademas de ello, se ha eliminado el soporte de Shiftfs con lo cual ahora para asignar ID de usuario se debe utilizar el montaje idmapped, que ahora son compatibles con ZFS y Cephfs (además del soporte de larga data para ext4, xfs y btrfs).

Por otra parte, ahora es posible conectar y desconectar dispositivos disk en caliente (hot-plug and hot-unplug), ya que el entorno host se ha movido del código base de la bifurcación de Incus.

De los demás cambios que se destacan:

  • El código de autorización se ha modularizado para proporcionar soporte OpenFGA además de autorización mediante certificados TLS y RBAC.
  • Para compilar LXD ahora se requiere al menos Go 1.20.
  • Se eliminó la compatibilidad con el firmware UEFI de 2 MB (debe usar firmware de 4 MB).
  • Se ha cambiado el nombre del identificador de dispositivo org.linuxcontainers.lxd a com.canonical.lxd (el identificador antiguo todavía se admite por compatibilidad con versiones anteriores).
  • La compatibilidad con la creación de almacenamientos basados ​​en la tecnología NVME se ha trasladado del código base de la bifurcación de Incus.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.


Sé el primero en comentar

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.