Toolbox: mit coretoolbox zusammenführen oder nicht

Wir haben das heute im Fedora CoreOS Meeting diskutiert.

  * 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)

Also @debarshiray @cgwalters reicht es aus, die zu untersuchenden Themen zu nennen:

1. Wird das debarshiray/toolbox-Projekt in Ordnung sein, wenn libpod nicht angeboten wird (dh entweder shell out oder varlink verwendet wird), um die Größe der Toolbox nicht zu sprengen?
2. Wenn wir zu Punkt 1 einen Konsens erzielen können, stimmen Sie @cgwalters zu, dass entweder Rust oder Golang ausreichende Werkzeuge sind (ohne Berücksichtigung persönlicher "Vorlieben")

Wenn wir zu Punkt 1 einen Konsens erzielen können, stimmen Sie @cgwalters zu, dass entweder Rust oder Golang ausreichende Werkzeuge sind (ohne Berücksichtigung persönlicher "Vorlieben")

Ja sicher.

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

(dh entweder berappen oder varlink verwenden), um die Größe der Toolbox nicht zu sprengen?

Ich bin froh, Podman von einer Wrapper-Go-Binärdatei zu berappen, da die überhöhte Größe durch den Verkauf in libpod ein Deal Breaker für CoreOS ist.

Ich bin froh, Podman von einer Wrapper-Go-Binärdatei zu berappen, da die überhöhte Größe durch den Verkauf in libpod ein Deal Breaker für CoreOS ist.

Wenn wir umschreiben, warum nehmen Sie dann nicht meine vorhandene Rust-Implementierung? Das ist ein wichtiger Punkt dabei - ich habe bereits funktionierenden Code, den ich aktiv verwende.

Ein guter Punkt für Rust BTW ist, dass das Upstream-Varlink-Zeug eine Menge großartigen Rust-Code enthält. Das besagte varlink-go existiert ebenfalls.

Wenn wir umschreiben, warum nehmen Sie dann nicht meine vorhandene Rust-Implementierung? Das ist ein wichtiger Punkt dabei - ich habe bereits funktionierenden Code, den ich aktiv verwende.

Um dies weiter zu konkretisieren, hier ein Vorschlag – wir verschieben debarshiray/toolbox nach coreos/toolbox und haben dann einen Commit, der den größten Teil des Codes durch cgwalters/coretoolbox ersetzt – @debarshiray wird zusammen mit anderen aus der CoreOS-Gruppe Co-Maintainer. (Oder wir könnten zu Fedora-Silverblue/GH org wechseln, da es derzeit eher damit verbunden ist, aber wir möchten auch die Host-Root-Fälle erfassen, was mehr Coreos/ ist.)

Ich habe die Nase voll von diesem ständigen passiv-aggressiven Ton, der versucht, die Coretoolbox überall hin zu schieben, und von einem Verhalten, das sehr danach aussieht, als würde man versuchen, dieses Projekt zu übernehmen.

Bitte hör auf!

Angesichts dessen, wie oft wir in der jüngeren Vergangenheit darüber gesprochen haben, und Ihres seltsam ausweichenden und aggressiven Verhaltens, kann ich das nicht mehr gut annehmen.

Das Toolbox-Projekt existiert, weil Silverblue unbedingt eine Möglichkeit brauchte, Entwicklern die Möglichkeit zu bieten, ihre eigene Entwicklungsumgebung einzurichten. Einige von uns, die an Silverblue arbeiteten, haben mit viel Hilfe des Podman-Teams etwas mit wurzellosem Podman gehackt, das uns gab, was wir brauchten. Ein großer Teil dieses Aufwands bestand darin, Podman ohne Root zum Laufen zu bringen, da wir Silverblue-Benutzern nicht sagen können, dass sie jetzt plötzlich root sein müssen, um eine Shell zu erhalten.

Sie sind sich der Realität wahrscheinlich nicht bewusst, da coretoolbox erst im April 2019 auftauchte. Zu diesem Zeitpunkt hatten sich viele große Turbulenzen gelegt. Doch im Sommer 2018, als der wurzellose Podman kaum existierte, ging es sehr stürmisch zu.

Sagen Sie, was Sie über Shell-Skripte wollen, es ist unglaublich einfach, ein Skript zu teilen und zu erwarten, dass die andere Partei in der Lage ist, es zu optimieren und auszuführen; und wenn Ihr Entwicklungsworkflow hauptsächlich darin besteht, zufällige Podman-Beschwörungen auszulösen und zu sehen, was hängen bleibt und was nicht und warum nicht, ist diese Leichtigkeit absolut entscheidend, um Fortschritte zu erzielen. Auf keinen Fall können Sie eine zufällige Person bitten, sich etwas Rust oder Go oder einen anderen Code zu schnappen, und erwarten, dass sie es innerhalb weniger Minuten ausprobieren. Viele werden sich wahrscheinlich sträuben, nicht zu wissen, wie man es baut, und Sie können vergessen, jemals an den Punkt zu kommen, an dem Sie sie durch den richtigen Podman-Build oder eine Konfigurationskorrektur oder was auch immer halten.

Ich möchte auch darauf hinweisen, dass ich noch nie ein echtes Feedback vom CoreOS-Team erhalten habe. Noch nie.

Im letzten Jahr war ich bei mehreren IRC-Meetings, habe mit verschiedenen Leuten im wirklichen Leben gesprochen, und alles, was ich gehört habe, war im Grunde ja, ja, wir lieben Toolbox, wir werden Patches schicken, damit es unter CoreOS funktioniert . Außer, ich habe keinen einzigen Patch gesehen.

Das erste wirkliche Feedback kam am 8. Juli dieses Jahres über die aufgeblähten Abhängigkeiten , die durch die Toolbox-RPM hereingezogen wurden, die ich verfolgt und behoben habe.

In der Zwischenzeit war das Silverblue-Team damit beschäftigt, die Entwicklung von Podman kontinuierlich zu verfolgen, Podman-Versionen in allen unterstützten Zweigen zu testen, an der Verbesserung automatisierter Tests zu arbeiten, eine schwierige Migration nach der anderen zu bewältigen ... Die Liste geht weiter.

Du denkst, du hast funktionierenden Code? Haben Sie Unterlagen? Hast du Tests ?

Oh, und wie viele Benutzer haben Sie? Wie viele Benutzer aus der Wildnis haben Sie in die Hand genommen, um herauszufinden, warum ein alter Container nicht mehr mit neuen Tools funktioniert? Wie viele Regressionen haben Sie den Stack von GNOME bis zur OCI-Laufzeit rauf und runter aufgespürt?

Wir haben viele echte Endbenutzer, die Toolbox in freier Wildbahn verwenden. Wir können nicht einfach aufstehen und gehen und plötzlich alles ändern. Wir haben eine Menge Cgroups v2-Bugs, die unbedingt und dringend für Fedora 31 ausgearbeitet werden müssen.

Sie fragen sich, warum Toolbox immer noch in POSIX-Shell geschrieben ist? Hier ist Ihre Antwort - wir waren beschäftigt.

Silverblue-Benutzer erwarten normalerweise nicht, dass sie wissen müssen, wie ihr Betriebssystem funktioniert oder wie die Container-Technologie funktioniert. Sie erwarten, toolbox enter laufen zu lassen und eine Shell zu bekommen. Sie bekommen keine Muschel, sie werfen die Hände hoch und beschweren sich.

Jedes zufällige Hindernis bei der Verwendung von Silverblue im Vergleich zu älteren Workstations ist eine Hürde für die Einführung.

Sie glauben zu wissen, wie wichtig Toolbox ist? Vertrauen Sie mir, wir wissen es. Für Silverblue ist Toolbox fast so wichtig wie Bash.

Ich habe auch noch nie eine konkrete Liste mit Spezifikationen von CoreOS gesehen. Kein Wunder, dass https://github.com/coreos/fedora-coreos-tracker/issues/38 von einem Detail zum anderen schlängelt, ohne jemals die harten Anforderungen anzugeben.

Vergleichen Sie das mit https://fedoraproject.org/wiki/Workstation/Desktop_Containers

Ich denke, es ist ziemlich klar, wie wichtig die Toolbox für Silverblue ist, möglicherweise viel mehr als CoreOS, denn schließlich sind wir gekommen, um die ganze Routinearbeit zu erledigen.

Wir hätten Toolbox leicht in eine Richtung bringen können, die für CoreOS grundlegend problematisch ist, wie das Schreiben in Go mit libpod oder was auch immer, aber wir haben es nicht getan, oder? Selbst wenn alles, was Sie tun konnten, Rust-Fanboyismus war, ohne jemals anzugeben, was Ihre tatsächlichen Bedürfnisse sind.

Wir haben auch eine Reihe interessanter Ideen aus der Coretoolbox mit vollständiger Zuordnung aufgenommen , ohne dass Sie einen einzigen Finger rühren müssen.

Wie wäre es, wenn Sie lernen, etwas Dankbarkeit zu zeigen und zuerst Danke zu sagen?

Was die zukünftige Ausrichtung von Toolbox angeht...

Toolbox wird in Go neu geschrieben. Es ist die Sprache, in der der Rest des OCI-Ökosystems, einschließlich Podman, geschrieben ist. Es gibt keine Möglichkeit, an Toolbox zu arbeiten, ohne den Podman-Stack zu berühren. Es ist in unserem besten Interesse, so gut wie möglich auf einer Linie zu bleiben. Es wäre eine unnötige Hürde, den Mitwirkenden zu sagen, dass sie sowohl Rust- als auch Go-Kenntnisse haben müssen, um an Toolbox zu arbeiten.

Wir wollen Varlink nicht verwenden, wenn wir es vermeiden können. Es ist etwas, das wir derzeit überhaupt nicht in Silverblue verwenden, das Podman-Team ist nicht sehr glücklich damit, und trotzdem wäre es riskant, eine grundlegend neue Technologie mitten in etwas so Entscheidendes zu stecken. Ich würde unsere Bemühungen lieber darauf konzentrieren, Podman so robust wie möglich zu machen.

Was das Verkaufen libpod im Vergleich zu podman , werden wir uns an letzteres halten, wie wir es auf dem CoreOS-Meeting besprochen haben, um /usr/bin/toolbox so klein wie möglich zu halten.

Ich persönlich würde mich freuen, wenn CoreOS die Toolbox verwendet, und werde weiterhin zuhören und die Anforderungen von CoreOS so weit wie möglich berücksichtigen. Natürlich sind Beiträge willkommen und so. Ich werde es Ihnen auch nicht übel nehmen, wenn CoreOS aus irgendeinem Grund beschließt, Toolbox nicht zu verwenden.

Ich werde dieses Projekt jedoch nicht aus irgendeinem vagen Grund oder nur weil jemand im Internet entdeckt hat, dass wurzelloser Podman eine Sache ist, an einen anderen Ort verschieben. Diejenigen, die jeden Tag auftauchen, um sich mit all den langweiligen Schwierigkeiten auseinanderzusetzen, können entscheiden.

Schließen.

Wie wäre es, wenn Sie lernen, etwas Dankbarkeit zu zeigen und zuerst Danke zu sagen?

Danke!

Angesichts dessen, wie oft wir in der jüngeren Vergangenheit darüber gesprochen haben, und Ihres seltsam ausweichenden und aggressiven Verhaltens, kann ich das nicht mehr gut annehmen.

Hm, ändern wir das! Ich weiß nicht, was ausweichend ist. Es tut mir leid, dass Sie Aggression wahrnehmen. Sicherlich habe ich schon oft sachliche Meinungen vertreten, aber bitte nichts persönlich nehmen. Am wichtigsten; Der Grund, warum ich weiterhin solche Gespräche führe, ist, dass ich zusammenarbeiten möchte!

Ich habe die Nase voll von diesem ständigen passiv-aggressiven Ton, der versucht, die Coretoolbox überall hin zu schieben, und von einem Verhalten, das sehr danach aussieht, als würde man versuchen, dieses Projekt zu übernehmen.

Ah, aber - wir sprechen hier über etwas ziemlich Wichtiges. Ich schätze all die Arbeit, die Sie geleistet haben, absolut. Aber wir haben technische Meinungsverschiedenheiten.

Lassen Sie es mich klar sagen: Ich persönlich möchte unbedingt mehr Kontrolle über die zukünftige Ausrichtung dieses Projekts. Das ist nicht dasselbe wie totale Kontrolle. Ich glaube an "groben Konsens und funktionierenden Code". Ich denke, wir könnten zusammenarbeiten! Sie und ich kennen uns, ich hoffe, Sie stimmen zu.

Wie Sie wissen, wurde coretoolbox gestartet, weil ich versucht habe, einen Patch beizusteuern, und er nicht zusammengeführt wurde. Behalten wir das also im Hinterkopf! Ich habe zuerst versucht, das Shell-Skript zu hacken.

Oh, und wie viele Benutzer haben Sie?

Ach, nicht viele. Aber es gibt zB diesen Kommentar .

Selbst wenn alles, was Sie tun konnten, Rust-Fanboyismus war, ohne jemals anzugeben, was Ihre tatsächlichen Bedürfnisse sind.

Hmm, das ist jetzt einfach unnötig. Wir haben bereits die Gründe für die Verwendung einer echten Sprache besprochen, wie Optionsparsing, Konfigurationsdateien, vernünftige Fehlerbehandlung usw. Abgesehen davon liebe ich Rust auch, es stimmt :wink:

Ich werde dieses Projekt jedoch nicht aus irgendeinem vagen Grund oder nur weil jemand im Internet entdeckt hat, dass wurzelloser Podman eine Sache ist, an einen anderen Ort verschieben. Diejenigen, die jeden Tag auftauchen, um sich mit all den langweiligen Schwierigkeiten auseinanderzusetzen, können entscheiden.

Hier ist eine andere Sichtweise - angesichts der Kritikalität denke ich, dass das Projekt in eine Betreuerschaft verschoben werden sollte, die nicht nur Sie und Ihre persönliche github-Domäne umfasst. Ich möchte unbedingt zu einem solchen Projekt beitragen.

Toolbox wird in Go neu geschrieben. Es ist die Sprache, in der der Rest des OCI-Ökosystems, einschließlich Podman, geschrieben ist. Es gibt keine Möglichkeit, an Toolbox zu arbeiten, ohne den Podman-Stack zu berühren. Es ist in unserem besten Interesse, so gut wie möglich auf einer Linie zu bleiben. Es wäre eine unnötige Hürde, den Mitwirkenden zu sagen, dass sie sowohl Rust- als auch Go-Kenntnisse haben müssen, um an Toolbox zu arbeiten.

Hier sind wir also offensichtlich immer wieder stecken geblieben - aber ich denke, das Sprachproblem sollte nach der Betreuerschaft kommen. Siehst du, dass dieses Projekt in deinem persönlichen GH unter alleiniger Führung verbleibt, oder siehst du, dass es z. B. in die Coreos/GH-Org oder Fedora-Silverblue/GH-Org übergeht und mehrere Betreuer hat?

Was ist der beste Weg, um die Toolbox auf FCOS aws ami (v31.20200223.3.0) auszuführen?

Ich habe versucht, Toolbox auszuführen, aber es funktioniert nicht

toolbox create
toolbox: TOOLBOX_PATH not set

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