Toolbox: fusionner avec coretoolbox, ou non

Nous en avons discuté lors de la réunion Fedora CoreOS aujourd'hui .

  * AGREED: regarding golang vs rust that is up to the author of
    toolbox. we do care about size and exploding the number of
    container-runtime implementations. If Golang is chosen we prefer
    that we don't vendor libpod, but rather either shell out or use the
    varlink API to manage containers.  (dustymabe, 17:33:38)

donc @debarshiray @cgwalters suffit-il de dire les sujets à investiguer :

1. le projet debarshiray/toolbox sera-t-il d'accord avec le fait de ne pas vendre libpod (c'est-à-dire de débourser ou d'utiliser varlink) afin de ne pas exploser la taille de la boîte à outils ?
2. si nous pouvons obtenir un consensus sur le point 1, alors @cgwalters êtes-vous d'accord que la rouille ou le golang sont des outils suffisants (sans tenir compte des "préférences" personnelles)

si nous pouvons obtenir un consensus sur le point 1, alors @cgwalters êtes-vous d'accord que la rouille ou le golang sont des outils suffisants (sans tenir compte des "préférences" personnelles)

Oui bien sûr.

1. will the debarshiray/toolbox project be ok with not vendoring libpod

(c'est-à-dire débourser ou utiliser varlink) afin de ne pas exploser la taille de la boîte à outils?

Je suis heureux de payer Podman à partir d'un wrapper Go binaire, car la taille gonflée de la vente en libpod est un facteur décisif pour CoreOS.

Je suis heureux de payer à Podman à partir d'un wrapper Go binaire, car la taille gonflée de la vente dans libpod est un facteur décisif pour CoreOS.

Si nous réécrivons, pourquoi ne pas prendre mon implémentation Rust existante ? C'est un point important à cet égard - j'ai déjà un code de travail que j'utilise activement.

Un bon point pour Rust BTW est que le truc varlink en amont a beaucoup de bon code Rust. Cela dit varlink-go existe aussi.

Si nous réécrivons, pourquoi ne pas prendre mon implémentation Rust existante ? C'est un point important à cet égard - j'ai déjà un code de travail que j'utilise activement.

Pour étoffer cela davantage, voici une proposition - nous déplaçons debarshiray/toolbox vers coreos/toolbox, puis avons un commit qui remplace la majeure partie du code par cgwalters/coretoolbox - @debarshiray devient co-responsable avec d'autres membres du groupe CoreOS. (Ou nous pourrions passer à fedora-silverblue/ GH org, car il est actuellement plus associé à cela, mais nous voulons également capturer les cas racine de l'hôte, ce qui est plus coreos/)

J'en ai marre de ce ton agressif passif constant qui essaie de pousser coretoolbox partout, et d'un comportement qui ressemble beaucoup à essayer de prendre le contrôle de ce projet.

S'il te plaît, arrête!

Compte tenu du nombre de fois où nous en avons parlé dans un passé récent, et de votre comportement étrangement évasif et agressif, je ne peux plus bien assumer.

Le projet Toolbox existe car Silverblue avait absolument besoin d'un moyen de proposer aux développeurs de mettre en place leur propre environnement de développement. Certains d'entre nous travaillant sur Silverblue, avec beaucoup d'aide de l'équipe Podman, ont piraté quelque chose en utilisant Podman sans racine qui nous a donné ce dont nous avions besoin. Une grande partie de cet effort consistait simplement à faire fonctionner Podman sans racine, car nous ne pouvons pas dire aux utilisateurs de Silverblue qu'ils doivent maintenant être root pour obtenir un shell.

Vous n'êtes probablement pas au courant de la réalité car coretoolbox n'est apparu qu'en avril 2019. À ce moment-là, de nombreuses turbulences majeures s'étaient apaisées. Cependant, à l'été 2018, alors que Podman sans racine existait à peine, les choses étaient très orageuses.

Dites ce que vous voulez à propos des scripts shell, il est incroyablement facile de partager un script et de s'attendre à ce que l'autre partie puisse le modifier et l'exécuter ; et lorsque votre flux de travail de développement consiste principalement à lancer des incantations Podman aléatoires et à voir ce qui colle et ce qui ne colle pas et pourquoi pas, cette facilité est absolument essentielle pour progresser. Il n'y a aucun moyen de demander à une personne au hasard de récupérer du Rust or Go ou n'importe quel code et de s'attendre à ce qu'elle l'essaye en quelques minutes. Beaucoup rechigneront probablement à ne pas savoir comment le construire, et vous pouvez oublier de jamais arriver au point de les tenir à travers la bonne construction de Podman ou un correctif de configuration ou autre.

Je préciserai également que je n'ai jamais vu de vrais retours de la part de l'équipe CoreOS. Jamais.

Au cours de l'année dernière, j'ai assisté à plusieurs réunions IRC, parlé avec diverses personnes dans la vraie vie, et tout ce que j'ai entendu est essentiellement oui, oui, nous aimons Toolbox, nous allons envoyer des correctifs pour le faire fonctionner sur CoreOS . Sauf que je n'ai pas vu un seul patch.

Le premier vrai retour a eu lieu le 8 juillet de cette année à propos des dépendances gonflées introduites par le RPM de la boîte à outils, que j'ai poursuivi et corrigé.

Pendant ce temps, l'équipe Silverblue a été occupée à suivre en permanence le développement de Podman, à tester les versions de Podman dans toutes les branches prises en charge, à améliorer les tests automatisés, à effectuer une migration difficile après l'autre... La liste est longue.

Vous pensez avoir un code fonctionnel ? Avez-vous de la documentation? Avez-vous des tests ?

Oh, et combien d'utilisateurs avez-vous ? Combien d'utilisateurs sauvages avez-vous tenus à la main pour savoir pourquoi un ancien conteneur ne fonctionne plus avec de nouveaux outils ? Combien de régressions avez-vous suivi de haut en bas de la pile de GNOME à l'environnement d'exécution OCI ?

Nous avons beaucoup de vrais utilisateurs finaux qui utilisent Toolbox dans la nature. Nous ne pouvons pas simplement nous lever et partir, et soudainement tout changer. Nous avons une tonne de bogues Cgroups v2 qui doivent absolument et urgemment être résolus pour Fedora 31 .

Vous vous demandez pourquoi Toolbox est toujours écrit en shell POSIX ? Voilà votre réponse - nous avons été occupés.

Les utilisateurs de Silverblue ne s'attendent généralement pas à devoir connaître le fonctionnement de leur système d'exploitation ou les tenants et les aboutissants de la technologie des conteneurs. Ils s'attendent à exécuter toolbox enter et à obtenir un shell. Ils ne reçoivent pas d'obus, ils lèvent la main et se plaignent.

Chaque obstacle aléatoire à l'utilisation de Silverblue, par rapport à l'ancienne Workstation, est un obstacle à l'adoption.

Vous pensez savoir à quel point Toolbox est critique ? Croyez-moi, nous savons. Pour Silverblue, Toolbox est presque aussi critique que Bash.

Je n'ai jamais non plus vu de liste concrète de spécifications de CoreOS. Pas étonnant que https://github.com/coreos/fedora-coreos-tracker/issues/38 serpente d'un détail à l'autre sans jamais préciser quelles sont les exigences strictes.

Comparez cela à https://fedoraproject.org/wiki/Workstation/Desktop_Containers

Je pense qu'il est assez clair à quel point Toolbox est crucial pour Silverblue, peut-être beaucoup plus que CoreOS, car finalement nous nous sommes présentés pour faire tout le travail fastidieux.

Nous aurions pu facilement prendre Toolbox dans une direction qui est fondamentalement problématique pour CoreOS, comme l'écrire en Go avec libpod vendu ou autre, mais nous ne l'avons pas fait, n'est-ce pas ? Même quand tout ce que vous pouviez faire était le fanboyisme de Rust sans jamais préciser quels sont vos besoins réels.

Nous avons également absorbé un tas d'idées intéressantes de coretoolbox avec une attribution complète sans que vous ayez à lever le petit doigt.

Que diriez-vous d'apprendre à montrer de la gratitude et à dire merci d' abord ?

Quant à l'orientation future de Toolbox...

Toolbox sera réécrit en Go. C'est le langage dans lequel le reste de l'écosystème OCI, y compris Podman, est écrit. Il n'y a rien de tel que de travailler sur Toolbox sans toucher à la pile Podman. Il est dans notre intérêt de rester aussi alignés que possible. Ce serait un obstacle inutile de dire aux contributeurs qu'ils doivent maîtriser à la fois Rust et Go pour travailler sur Toolbox.

Nous ne voulons pas utiliser Varlink, si nous pouvons l'éviter. Ce n'est pas du tout quelque chose que nous utilisons actuellement dans Silverblue, l'équipe Podman n'en est pas très satisfaite, et quoi qu'il en soit, il serait risqué de mettre une technologie fondamentalement nouvelle au milieu de quelque chose d'aussi crucial. Je préfère concentrer nos efforts pour rendre Podman aussi robuste que possible.

En ce qui concerne la vente libpod par rapport au déboursement à podman , nous nous en tiendrons à ce dernier comme nous en avons discuté lors de la réunion CoreOS pour garder /usr/bin/toolbox aussi petit que possible.

Je serais personnellement heureux de voir CoreOS utiliser Toolbox et continuerai à écouter et à répondre aux besoins de CoreOS autant que possible. Bien sûr, les contributions sont les bienvenues et tout ça. Je ne vous en voudrai pas non plus si CoreOS décide de ne pas utiliser Toolbox pour une raison quelconque.

Cependant, je ne vais pas déplacer ce projet vers un autre endroit pour une vague raison insipide, ou simplement parce que quelqu'un sur Internet a découvert que Podman sans racine est une chose. Ceux qui se présentent tous les jours pour faire face à toutes les difficultés ennuyeuses décident.

Fermeture.

Que diriez-vous d'apprendre à montrer de la gratitude et à dire merci d'abord ?

Merci!

Compte tenu du nombre de fois où nous en avons parlé dans un passé récent, et de votre comportement étrangement évasif et agressif, je ne peux plus bien assumer.

Hum, changeons ça ! Je ne sais pas ce qui est évasif. Je suis désolé que vous perceviez de l'agressivité. J'ai certainement souvent des opinions techniques bien arrêtées, mais s'il vous plaît, ne prenez rien personnellement. Le plus important; la raison pour laquelle je continue à avoir des conversations comme celle-ci, c'est parce que je veux travailler ensemble !

J'en ai marre de ce ton agressif passif constant qui essaie de pousser coretoolbox partout, et de ce comportement qui ressemble beaucoup à essayer de reprendre ce projet.

Ah mais - nous parlons de quelque chose d'assez important ici. J'apprécie absolument tout le travail que vous avez fait. Mais nous avons des désaccords techniques.

Permettez-moi de le dire clairement : personnellement, je veux absolument plus de contrôle sur l'orientation future de ce projet. Ce n'est pas la même chose que le contrôle total. Je crois au "consensus approximatif et au code de travail". Je pense qu'on pourrait travailler ensemble ! Toi et moi nous connaissons, j'espère que tu seras d'accord.

Comme vous le savez, coretoolbox a démarré parce que j'ai essayé de contribuer un patch et il n'a pas été fusionné. Alors gardons cela à l'esprit ! J'ai d' abord essayé de pirater le script shell.

Oh, et combien d'utilisateurs avez-vous ?

Oh, pas beaucoup. Mais, il y a par exemple ce commentaire .

Même quand tout ce que vous pouviez faire était le fanboyisme de Rust sans jamais préciser quels sont vos besoins réels.

Hmm, maintenant c'est juste inutile. Nous avons déjà expliqué les raisons d'utiliser un vrai langage, comme l'analyse d'options, les fichiers de configuration, la gestion saine des erreurs, etc. Cela dit, j'aime aussi Rust, c'est vrai :wink:

Cependant, je ne vais pas déplacer ce projet vers un autre endroit pour une vague raison insipide, ou simplement parce que quelqu'un sur Internet a découvert que Podman sans racine est une chose. Ceux qui se présentent tous les jours pour faire face à toutes les difficultés ennuyeuses décident.

Voici une autre façon de voir les choses - encore une fois, compte tenu de la criticité, je pense que le projet devrait passer à une maintenance qui n'est pas seulement vous et votre domaine personnel github. Je veux absolument contribuer à un tel projet.

Toolbox sera réécrit en Go. C'est le langage dans lequel le reste de l'écosystème OCI, y compris Podman, est écrit. Il n'y a rien de tel que de travailler sur Toolbox sans toucher à la pile Podman. Il est dans notre intérêt de rester aussi alignés que possible. Ce serait un obstacle inutile de dire aux contributeurs qu'ils doivent maîtriser à la fois Rust et Go pour travailler sur Toolbox.

Donc, c'est évidemment là que nous sommes restés bloqués - mais je pense que le problème de la langue devrait venir après la maintenance. Voyez-vous ce projet rester dans votre GH personnel sous votre seule responsabilité, ou le voyez-vous passer par exemple à l'org coreos/ GH ou fedora-silverblue/ GH et avoir plusieurs mainteneurs ?

Quelle est la meilleure façon d'exécuter la boîte à outils sur FCOS aws ami (v31.20200223.3.0) ?

J'ai essayé d'exécuter la boîte à outils mais cela ne fonctionne pas

toolbox create
toolbox: TOOLBOX_PATH not set

TOOLBOX_PATH=/usr/bin/toolbox toolbox create
toolbox: this is not a toolbox container