verwandte Anfrage: #2566

Ich habe damit begonnen, daran zu arbeiten.
Suchen wir in Anbetracht der Kommentare zu #2566 nach --values ​​oder --set (oder beiden?)

In der von mir geöffneten Ausgabe ( #3198 ) ist ein netter Anwendungsfall beschrieben, in dem ich gerne Folgendes tun könnte:

helm package --version 1.2.3 --set image.tag 1.2.3

Auf diese Weise sind die Diagrammversion und die Docker-Image-Version ein und dieselbe.

Ich habe gerade den ersten Entwurf fertiggestellt und eine PR dafür gepostet.

@ngeor , @sslavic der von mir eingereichte PR fügt sowohl die Optionen --set als auch --values ​​hinzu, könnten Sie bitte einen Blick darauf werfen?

Hallo @adshmh , sieht gut aus; Leider kenne ich Go nicht, aber ich sehe, dass Sie es mit den Testfällen und allem abgedeckt haben, also tut es wahrscheinlich, was es sagt :) Danke!

Wann wird diese Funktion verfügbar sein? In 2.9.0 ?

3471 hat die Frist für 2.9 verpasst, also wird es in 2.10 sein.

Öffnen Sie dies erneut, da # 3471 zurückgesetzt werden muss.

Was macht das mit den Kommentaren/etc im Archivpaket? zB werden sie ausgezogen oder allein gelassen oder ??

Derzeit versuche ich dasselbe mit yq zu tun, aber es gibt nur die endgültigen Werte nach der Verarbeitung aus. dh alle Kommentare, Leerzeilen für die Organisation usw. sind weg.

3471 hat alle Kommentare entfernt, weshalb wir diese PR zurücksetzen mussten. Weitere Informationen finden Sie unter https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783

Zurückgesetzt von 2.10 "feat: add --set and --values ​​options to 'helm package'" https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

Neuigkeiten dazu?
Danke

Das gleiche wie oben; niemand hat an einem Follow-up gearbeitet, um die Fehler in #3471 zu beheben, also wurde dies nicht implementiert. Sie können Helm gerne forken und gegen #3471 kompilieren, wenn Sie damit einverstanden sind, dass Kommentare aus der Wertedatei entfernt werden.

Ist das erledigt? Ich habe die Versionen 2.11.0 und 2.12.0 ausprobiert, keine davon scheint helm package --set... zu haben

+1. Es wird uns in CI wirklich helfen, das Pasen und Aktualisieren von Yamls von Werten vor dem Packen zu stoppen.

+1

--set-string kann auch nützlich sein, warum nicht alle Override-Optionen zulassen, die in install/upgrade vorhanden sind.
Führen Sie einfach denselben Code aus, der zum Überschreiben der Werte für den Paketbefehl verwendet wurde. Es ist sinnvoll, dass das Paket die Überschreibungswerte enthält. Diese Flags sollten genau wie bei Installation/Upgrade geteilt werden.

2.13.1 hat auch keine solche Funktion, gibt es dafür einen Zeitplan?

Wie bereits erwähnt, arbeitet derzeit niemand daran und es gibt keinen Zeitplan, wann ein Fix verfügbar sein wird. Fühlen Sie sich frei, dieses anzunehmen. Werfen Sie einen Blick auf #3471 für Ideen.

in Helm 3 implementiert . Schließen!

Wenn man sich den Code ansieht, scheint #3471 versehentlich in Helm 3 angekommen zu sein, wurde aber aufgrund dieses Kommentars nie herausgezogen, wie wir es für Helm 2 getan haben: https://github.com/helm/helm/pull/3471#issuecomment -381779783

Ich öffne diese Funktionsanfrage erneut, da wir die Flags --set und --values ​​in Helm 3 mit https://github.com/helm/helm/pull/7201 entfernen. Sie haben sowieso nie funktioniert ... Alles, was über --set oder --values gesetzt wurde, wurde nie in das Paket eingefügt, und es führte einige fatale Regressionen mit helm package ein, nämlich die Tatsache, dass es entfernt wurde Kommentare aus values.yaml heraus, die mehrere Community-Mitglieder als Dokumentation verwenden.

Vielleicht habe ich ein Missverständnis, aber ich habe gerne --set mit Paket verwendet, um Werte festzulegen, und es hat von 3.0.0 bis 3.0.2 großartig funktioniert, definitiv kein "no-op", wie in #7201 beschrieben.

Meine Pipelines sind seit 3.0.3 kaputt. Dies funktionierte in 3.0.2. Warum wird dies nicht als nützlich erachtet, wenn wir --version und --app-version haben. Wie sollen wir das Bild und das Tag bearbeiten, um mit --app-version übereinzustimmen? Basch ?

Wenn Sie sich den Code noch einmal ansehen, haben Sie Recht, @lukaslarson und @maxhillaert. Dies war jedoch immer noch ein Feature, das rückgängig gemacht werden sollte, da es alle Kommentare aus der Wertedatei des Pakets entfernte. Es wurde in Helm 2 entfernt, gelangte aber versehentlich in Helm 3. Es war nie für den Versand vorgesehen.

Wenn jemand an der Neuimplementierung von #3471 arbeiten möchte, die Kommentare enthält, würden wir uns gerne PRs ansehen.

@bacongobbler Das hat uns einiges kaputt gemacht. Ich wäre daran interessiert, an einer PR zu arbeiten, aber es scheint nicht trivial zu sein, also würde ich gerne den Ansatz überprüfen.

Es sieht so aus, als ob gopkg.in/yaml.v3 das Aufbewahren von Kommentaren beim Roundtrip unterstützt. Mein Vorschlag wäre, Values zu einem Yaml Node zu machen. Gehen Sie dann beim Zusammenführen von Werten durch den Baum der geparsten Ausgabe und nicht durch verschachtelte Karten. Dies ist sicherlich weniger ergonomisch, aber der beste Weg, um Kommentare sicher zu erhalten.

Dies ist ein kleines Problem, da wir überall sigs.k8s.io/yaml verwenden, das an v2 der zugrunde liegenden Bibliothek gepinnt ist. Dies würde zumindest erfordern, dass es als separate Abhängigkeit eingeführt wird, was irgendwie igitt ist. Ich bin mir nicht sicher, was hier der beste Ansatz ist, um zu vermeiden, alles zu berühren, was mit Yaml zu tun hat.

Die beste Option scheint die Migration zu yaml.v3 zu sein, also scheint es, als wären Sie auf dem richtigen Weg.

Wenn Sie mit der Arbeit an einem PoC/Fork von Helm beginnen möchten, der yaml.v3 anstelle von sig.k8s.io/yaml verwendet, wäre dies ein guter Weg nach vorne. Auf diese Weise können wir damit beginnen, seine Funktionalität im Vergleich zu dem, was in master enthalten ist, zu bewerten.

Sobald wir festgestellt haben, dass yaml.v3 der beste Weg nach vorne ist, können wir herausfinden, wie wir vom Standpunkt des SDK aus vorgehen.

Hilft das, dich zu entsperren?

@jmcelwain Arbeitest du aktiv daran? Wenn nicht, übernehme ich das gerne.

@sreya92 Ich war bei der Arbeit beschäftigt. Hier habe ich aufgehört: Der Wechsel zu yaml.v3 war größtenteils einfach, mit Ausnahme dieses Bits hier . Ich war mir nicht sicher, was der beste Ansatz ist, um damit umzugehen, ohne die Abhängigkeit anzubieten und sie dort auf v3 zu aktualisieren.

Es sieht so aus, als ob einige Arbeiten am Upgrade durchgeführt wurden, aber es gibt keine weiteren Informationen in Problemen usw., und ich habe mich nicht darum gekümmert, ein Problem zu öffnen. Die andere Option wäre, einfach beide Abhängigkeiten beizubehalten, aber das scheint grob.

Meine persönliche Meinung wäre, dass dies ein Blocker für dieses Problem ist, es sei denn, Betreuer sind der Meinung, dass es sich lohnt, zwei Kopien ähnlicher Bibliotheken mit sich herumzutragen. Ich bin mir nicht sicher, was das LoE hier ist, aber wir sollten wahrscheinlich daran arbeiten, github.com/ghodss/yaml auf v3 zu bringen und die Anbieterversion in k8s ebenfalls zu aktualisieren. Das würde das alles viel einfacher machen.

https://github.com/ghodss/yaml/issues/61 geöffnet, um dort nach der Möglichkeit eines Upgrade-Pfads zu fragen. Ich werde warten, bis ich von ihnen höre, bevor ich mit irgendetwas anderem fortfahre - das Aktualisieren von Abhängigkeiten ist meiner Meinung nach anderen Optionen vorzuziehen.

@jmcelwain Es gibt nicht viel Code in https://github.com/ghodss/yaml , es gibt nicht bediente Pull-Requests von 2017: https://github.com/ghodss/yaml/pulls , und der Code ist MIT lizenziert.

Zieht diese Abhängigkeit wirklich ins Gewicht? Es handelt sich um ein paar Marshalling-Helfer, die es jedoch schaffen, ein Problem aufzuhalten, das, wenn es gelöst wird, die Fähigkeit für viele Projekte verbessern könnte, Paketstandardwerte während der Erstellungszeit dynamisch festzulegen (unser Anwendungsfall besteht darin, nicht mehrere unterschiedliche Orte zum Speichern von Versions-Tags verwalten zu müssen etwas wie --set image.tag=${GIT_TAG} , um Diagramm- und Bildversionen für ein Projekt zu verriegeln).

Kann ich vorschlagen, dass wir nicht länger warten und einfach den erforderlichen Code in helm kopieren (ich würde mich nicht darum kümmern, ihn zu verkaufen, sondern einfach absorbieren und nach Bedarf anpassen). Ich denke, es ist ein Projekt, das groß genug ist, um die Wartung dieses Wrappers zu übernehmen, und YAML-Marshalling ist eine Kernkompetenz (was nicht heißt, dass Sie Ihren eigenen Parser pflegen sollten, aber ...!)

Da uns dies im Moment Schmerzen bereitet (und uns davon abhält, von Helm 3.0.2 zu aktualisieren), würde ich es gerne versuchen.

Diese Situation würde ich lieber vermeiden. Es gibt nicht genügend Betreuer, um sowohl einen Paketmanager als auch einen YAML-Parser zu pflegen. Das würde eine erhebliche Wartungsbelastung für das Team bedeuten.

@bacongobbler es ist _kein_ Yaml-Parser. Es verwendet gopkg.in/yaml.v2 , um das eigentliche Parsen durchzuführen. Es sind etwa 900 Zeilen reflect Wrapper-Code um diesen Parser herum. Das Problem ist, dass sie gopkg.in/yaml.v3 nicht verwenden, was dieses Problem lösen würde.

Es scheint mir, dass die Wartungsbelastung durch die Verwendung dieses kleinen Zwischenprodukts zu Ihrer tatsächlichen Abhängigkeit eine größere Belastung darstellt als die Wartung dieses Codestückchens.

Wie bereits erwähnt, können Sie gerne einen PR-Upstream vorschlagen, der ghodss/yaml auf yaml.v3 aktualisiert. Wenn sie es nicht akzeptieren, zögern Sie nicht, das Projekt zu forken und es zu pflegen, wenn Sie das Gefühl haben, dass Sie die Wartungslast übernehmen können.

Lassen Sie mich jedoch klarstellen: Wir _werden keine_ Pull-Anforderungen akzeptieren, die ghodss/yaml des Anbieters in Helm verzweigen. Wir können nicht die zusätzliche Wartungslast einer gesamten Go-Bibliothek übernehmen, nur um eine Funktion zu unterstützen.

@bacongobbler bitte schau dir meine PR hier an: https://github.com/helm/helm/pull/7963

Es sind 900 Codezeilen mit den enthaltenen Tests und entfernten überflüssigen Funktionen.

Im Moment verlassen Sie sich auf etwas, das wie eine relativ ungepflegte Bibliothek aussieht, die einen viel größeren Platzbedarf hat als das, was ich dort hinzugefügt habe.

eine ganze Go-Bibliothek, nur um eine Funktion zu unterstützen

Sie verwenden alle eine Funktion aus dieser gesamten Go-Bibliothek, und um dies zu tun, haben Sie sich die Mühe gemacht, einen permanenten Fork zu erstellen, der weiter verschleiert, woher der Code kommt.

Fühlen Sie sich frei, das Projekt zu forken und zu warten, wenn Sie der Meinung sind, dass Sie die Wartungslast übernehmen können.

Ich meine, Sie führen bereits eine Single-Purpose-Fork dieses Codes aus. Wenn das Projekt abgebrochen wird, profitieren Sie nicht wirklich von der Wartung durch den ursprünglichen Autor.

Wenn Sie möchten, kann ich diese kleine Menge Code aus meiner PR nehmen und sie in ein Repo stellen und sagen, dass ich sie pflegen werde (und ich werde es versuchen), aber es scheint ziemlich albern zu sein.

Lassen Sie mich jedoch klarstellen: Wir akzeptieren keine Pull-Anfragen, die Fork und Vendor ghodss/yaml in Helm enthalten.

Fürs Protokoll, ich hatte diese PR bereits vorangetrieben, als ich dies las, also hoffe ich, dass Sie es sich noch einmal überlegen, weil ich denke, dass Sie einen zwischengespeicherten Gedanken über „Verkauf“ und „gesamte Go-Bibliothek“ haben (dem ich oft zustimmen könnte ), ohne sich den beteiligten Code anzusehen. Aber lassen Sie uns den eigentlichen fraglichen Code auf der PR besprechen. Ich freue mich, ein Codebesitzer für diesen Code zu sein, wenn das hilft. Stellen wir uns vor, ich hätte es als Beitrag geschrieben ... Ich habe es irgendwie getan.

Vielleicht werden sie es zusammenführen: https://github.com/ghodss/yaml/pull/62

Die andere Alternative, die ich kurz untersucht habe, war die Möglichkeit, die YAML-zu-JSON-Konvertierung durch eine andere Abhängigkeit zu ersetzen oder durch ein Zwischenformat zu serialisieren. Ich bin mit dem Go-Ökosystem nicht vertraut genug, um zu wissen, ob dies ein praktikabler Weg ist - ich war etwas überrascht, dass ich bei einem kurzen Blick nicht mehr serialisierungsartige Bibliotheken finden konnte.

Irgendeine Idee, wann wir das --set zurücksetzen können, da wir dies verwenden, um das Helm-Packaging zu automatisieren. Es war in Helm 3.0.2 und jetzt, da die Aktualisierung nicht mehr unterstützt wird.

Wir sind immer noch daran gehindert, https://github.com/ghodss/yaml/pull/62 zusammenzuführen.

Wenn Sie sich den Code noch einmal ansehen, haben Sie Recht, @lukaslarson und @maxhillaert. Dies war jedoch immer noch ein Feature, das rückgängig gemacht werden sollte, da es alle Kommentare aus der Wertedatei des Pakets entfernte. Es wurde in Helm 2 entfernt, gelangte aber versehentlich in Helm 3. Es war nie für den Versand vorgesehen.

Wenn jemand an der Neuimplementierung von #3471 arbeiten möchte, die Kommentare enthält, würden wir uns gerne PRs ansehen.

Spielt es eine Rolle, ob Kommentare entfernt werden? Wenn es einen Vorbehalt bei der Verwendung von --set gibt, sind Kommentare mir egal.

Wir sind immer noch daran gehindert, ghodss/yaml#62 zusammenzuführen.

Ich schätze, wir stecken mit der Verwendung von 3.0.2 fest :(

3471 hat Kommentare entfernt, unabhängig davon, ob Sie --set verwendet haben oder nicht, sodass Benutzer, die diese Funktion nie verwendet haben, kaputt gegangen sind. Es hat die Abwärtskompatibilität für alle gebrochen. Daher kann es nicht mit einem Vorbehalt wieder eingeführt werden, und deshalb warten wir auf eine ordnungsgemäße Korrektur stromaufwärts.

weshalb wir bei 3.0.2 bleiben müssen

Wir sind immer noch daran gehindert, ghodss/yaml#62 zusammenzuführen.

Aber da diese Abhängigkeit anscheinend nicht mehr gepflegt wird, wäre es vielleicht besser, eine gegabelte Version zu verwenden, oder?

Ein Wechsel ist eine gute Idee – muss aber auf Helm 4 verschoben werden. Jemand sollte ein spezielles Problem für den Wechsel von YAML-Parsern einreichen, damit wir dies für den Helm 4-Prozess nachverfolgen können.

Lassen Sie mich jedoch klarstellen: Wir akzeptieren keine Pull-Anfragen, die Fork und Vendor ghodss/yaml in Helm enthalten. Wir können nicht die zusätzliche Wartungslast einer gesamten Go-Bibliothek übernehmen, nur um eine Funktion zu unterstützen.

Angesichts der Tatsache, dass https://github.com/ghodss/yaml nicht mehr gepflegt wird und es auf https://github.com/ghodss/yaml/pull/62 kein Lebenszeichen gibt, lohnt es sich, diese Position zu überdenken, und Neubewertung von https://github.com/helm/helm/pull/7963 ?

Wir sind nicht daran interessiert, den Wartungsaufwand für die Unterstützung einer gesamten YAML-Parsing-Bibliothek nur für eine Funktion zu übernehmen.

Ich fordere die Community auf, eine Zusammenarbeit mit den bestehenden Betreuern von ghodss/yaml in Betracht zu ziehen, um eine neue Gruppe von Betreuern zu finden, die bereit sind, das Projekt zu unterstützen, das Projekt zu forken oder eine neue Bibliothek zu finden, die Kommentare aufbewahren kann.

Also was wäre es?

• neue Betreuer finden, die ghodss/YAML unterstützen !?
• jemanden finden, der ghodss/YAML forkt und YAML.v3 verwendet (und es weiterhin unterstützt) !!
• Verwenden Sie direkt YAML.v3
• schlagen vor, YAML-Parser für Helm 4 zu wechseln

eine ganze YAML-Parsing-Bibliothek

Dies stellt den Umfang des hier betroffenen Codes falsch dar. Es sind ein paar Wrapper um andere Parser.

Wir sind nicht daran interessiert, den Wartungsaufwand für die Unterstützung einer gesamten YAML-Parsing-Bibliothek nur für eine Funktion zu übernehmen.

Vielleicht erklärt diese Verwirrung vieles - der Parser ist https://github.com/go-yaml/yaml , nicht ghodss/YAML. Von https://github.com/ghodss/yaml :

Ein Wrapper um Go-Yaml

Die einfache Lösung ist also: Hören Sie einfach auf, den Wrapper zu verwenden.

Die „Wrapper“ haben einen tiefgreifenden Einfluss auf einige der Verhaltensweisen. Nachdem die Parser (und Wrapper-Bibliotheken) zu Beginn des Projekts ein paar Mal gewechselt wurden, sind sich die Hauptbetreuer der kleinen Diskrepanzen zwischen ihnen sehr bewusst und wissen, wie diese zu Kompatibilitätsproblemen auf hoher Ebene führen.

Es besteht die Möglichkeit, dass wir in Betracht ziehen, einen Fork von ghodss/yaml zu verwenden, WENN UND NUR WENN die Besitzer dieses Forks sich zur kontinuierlichen Wartung verpflichtet haben.

Vielleicht kann ich präziser sein - hören Sie auf, die aufgegebene Wrapper-Bibliothek zu verwenden, und führen Sie das äquivalente/identische Wrapper-Verhalten in helm aus, was https://github.com/helm/helm/pull/7963 in etwa 250 LOC plus tut Prüfungen.

Ja, idealerweise würde stattdessen jemand in ghodss/yaml reparieren, aber es wird nicht mehr gepflegt. Die Alternative wartet doch nicht bis Helm 4?

Ich denke, Forking ist wahrscheinlich die beste Option, IMO; @ghodss scheint seit Anfang 2019 keine Aktivität mehr auf GH gehabt zu haben, und das letzte Commit zum Repo war vor anderthalb Jahren (von @bradfitz). Die letzte (einzige) Veröffentlichung war 2017. Wenn es irgendwelche latenten Sicherheitsprobleme im Code gibt, werden sie nicht auf main behoben.

Ich würde nachdrücklich dafür plädieren, einen Fork zu übernehmen, wenn jemand bereit ist, sich zu seiner Wartung zu verpflichten; Ich sehe keine Nachteile in Bezug auf die weitere Verwendung eines moribunden und aufgegebenen Pakets. Ich stimme zu, dass der Wechsel zu einem anderen Wrapper als größere Änderung sinnvoller ist (scheint so schwer zu sein, dass es sich leicht um eine Helm 4-Sache handeln könnte, aber ich werde nicht weiter spekulieren), aber ich denke, das könnte gelöst werden mit einer replace Zeile in go.mod .

Ich bin bereit, mich zu verpflichten, einen Fork mitzubetreuen, wenn jemand anderes es auch tut; Ich habe im Moment nicht genug Bandbreite, um es selbst zu tun, aber ich kann genug beitragen.

Zugegeben, ich interessiere mich hauptsächlich dafür, damit ich meinen Haufen von sed -Skripten loswerden kann, um meine Helm-Diagramme zu verpacken, aber wenn das nötig ist, soll es so sein.

Hallo
Ich habe gerade ein Plugin erstellt, das es erlaubt, Werte beim Packen zu setzen. Im Moment unterstützt es nur das Flag set (weil ich das :sweat_smile: brauchte), aber ich beabsichtige, andere Flags hinzuzufügen. Zögern Sie nicht, PRs zu pushen, wenn Sie möchten, oder Bemerkungen hinzuzufügen, um sie zu verbessern.
Danke

Nur für den Fall, dass jemand nicht mitverfolgt hat, es gab einige Fortschritte bei der Kontaktaufnahme mit einem Betreuer von ghodss/yaml#62, also werden wir hoffentlich bald gute Nachrichten hören!

Diese Ausgabe wurde als veraltet gekennzeichnet, da sie seit 90 Tagen ohne Aktivität geöffnet ist. Dieser Thread wird automatisch in 30 Tagen geschlossen, wenn keine weiteren Aktivitäten stattfinden.

Definitiv nicht altbacken. Ich habe versucht, Zeit zu finden, um https://github.com/ghodss/yaml/pull/62 nachzugehen und zu sehen, ob wir helfen können, es zusammenzuführen, um den Fortschritt bei diesem Problem freizugeben. Da meine Organisation unsere Abhängigkeit von Helm erhöht hat, möchten wir weiterhin in der Lage sein, Werte in ein pro-CI-Build-Paketdiagramm zu backen.

Ich habe alle Kommentare gelöscht, die um eine Statusaktualisierung gebeten haben, da sie nichts zur aktuellen Konversation beitragen. @jmcelwain hat vor nicht weniger als 5 Tagen ein Status-Update bereitgestellt (danke, übrigens) und ist so gut wie jedes andere. Wie bereits erwähnt, ist die Lösung dieses Problems knifflig und beinhaltet das Aktualisieren oder Verzweigen mehrerer Abhängigkeiten, sodass eine gewisse Sorgfalt erforderlich ist.

Wenn wir weitere Informationen zu teilen haben, werden wir den Thread aktualisieren.

Als Problemumgehung habe ich https://github.com/mikefarah/yq verwendet, um mein Steuerdiagramm vor dem Verpacken zu aktualisieren:

yq w -i values.yaml version $(Build.BuildNumber)

In unserem CI erstellen wir das App-/Docker-Image und das Diagramm in derselben Pipeline (um sicherzustellen, dass sich App und Diagramm zusammen mit derselben Versionierung weiterentwickeln). Die Standardwerte für das Diagramm hängen von der zuvor erstellten Image-Version ab.

Der yq-Workaround kann leicht in eine Pipeline integriert werden, aber das scheint seltsam, dass dieser Anwendungsfall nicht korrekt von helm abgedeckt wird!

Sie sind also keine integrierte Möglichkeit mit helm, image.tag während/vor der Paketphase festzulegen?

Bearbeiten : In meinem Fall habe ich diese Lösung gefunden, wir müssen die Chart.AppVersion für das Image-Tag verwenden, da wir das Diagramm mit derselben Versionierung verpacken.

Bearbeiten 2 : Chart.AppVersion / funktioniert nicht mit gemeinsam genutztem Diagramm (exp ein Spring-Boot-Diagramm, das in mehreren Umbrella-Diagrammen verwendet wird)

mein Fazit : image.tag muss wirklich während der Paketphase gesetzt werden

Irgendwelche Neuigkeiten zu dieser Funktion?