LXD, un gestionnaire de conteneurs système, un outil pour LXC
avant les nouvelles qui est sorti il y a quelques semaines par Canonical, SÀ propos de la modification du modèle de développement de LXD comme un projet d'entreprise, plutôt qu'un projet communautaire autonome, Incus a été créé en réponse à cela.
Pour ceux qui ne connaissent pas LXD, sachez que ce fournit des outils pour la gestion centralisée des conteneurs déployé dans un cluster de plusieurs serveurs. la trousse à outils LXC est utilisé comme runtime pour exécuter des conteneurs et LXD est implémenté en tant que processus d'arrière-plan qui accepte les requêtes sur le réseau via une API REST et prend en charge plusieurs backends de stockage, des instantanés d'état, la migration en direct des conteneurs en cours d'exécution d'une machine à une autre et le stockage d'images des outils de conteneur.
Et est-ce après 8 ans de développement dans le cadre des conteneurs Linux, Canonique, qui est le créateur et principal développeur de LXD, a décidé que c'était le plus optimal pour le développement LXD. Cette décision a conduit à déplacer le code LXD du référentiel lxc/lxd vers canonical/lxd , et la page d'accueil du projet est devenue ubuntu.com/lxd, et l'intégration continue pour LXD sera migrée vers les serveurs de Canonical.
Ce mouvement a soulevé de nombreuses inquiétudes aux développeurs, puisqu'un des problèmes qui inquiète le plus est le code supplémentaire ajouté à LXD, qui est nécessaire pour s'exécuter au format snap et rend LXD plus difficile à utiliser et à tester.
À ce sujet, Mark Shuttleworth, a déclaré que Canonical n'a pas l'intention d'arrêter de prendre en charge d'autres distributions dans LXD, et que le projet continue de se développer publiquement sur GitHub et accepte les correctifs et les modifications d'autres contributeurs.
Voilà pourquoi En réponse à cela, les "Forks" ont été créés, Incus, que curieusement il y en a deux et coïncident dans le même nom, mais que ils ont été créés par des personnes différentes, l'un par Alexa Sarai, qui travaille pour SUSE et maintient les packages LXD dans le projet openSUSE et l'autre par Stéphane Graber, ancien responsable du projet LXD.
A propos de ce dernier, Stéphane Graber, je voudrais mentionner que ra annoncé son poste de chef de projet LXD, une semaine après que Canonical a repris LXD, car il n'a pas l'intention de signer un accord CLA avec Canonical. Stefan a créé un fork de LXD, également sous le nom d'Incus et que dans son commentaire sur l'annonce du nouveau fork, par Alexa Sarai, Stefan a confirmé que le deuxième dépôt de fork devait être considéré comme le principal.
À propos de la nouvelle fourche par Alexa Sarai, il est mentionné que il est prévu de développer un fork du système de gestion de conteneurs LXD. Le fork a été créé en raison de préoccupations selon lesquelles Canonical ne prendrait plus correctement en charge d'autres distributions dans LXD, car, comme indiqué dans les plans de Canonical de se concentrer sur la livraison de LXD au format snap, qui se positionne comme le format principal pour l'installation de LXD.
Et c'est en particulier, la plupart des utilisateurs de LXD ne sont pas sur Ubuntu, mais sur la plate-forme ChromeOS, qui utilise l'outil de construction Gentoo Linux ebuild/portage.
Incus (par Alexa Sarai) travaille actuellement sur la suppression des dépendances redondantes et désactiver les liens vers les outils et technologies spécifiques aux produits Canonical. Le développement de la fourche sera réalisé avec la participation de la communauté et en tenant compte des intérêts des projets tiers.
Il est mentionné que le fork a été créé dans la version LXD 5.16, qui rend possible la mise à niveau des versions LXD jusqu'à LXD 5.16 inclus. La mise à niveau à partir d'une version ultérieure de LXD peut ne pas fonctionner car les deux projets commenceront probablement à diverger à partir de ce moment.
Incus continuera de surveiller et d'importer les modifications LXD pertinentes au fil du temps, bien que les modifications et fonctionnalités spécifiques aux produits Ubuntu ou Canonical soient peu susceptibles d'être portées.
Enfin, si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant