demande associée : #2566

J'ai commencé à travailler là-dessus.
Considérant les commentaires sur #2566, cherchons-nous --values ​​ou --set (ou les deux ?)

Un joli cas d'utilisation est décrit dans le problème que j'ai ouvert ( #3198 ), dans lequel j'aimerais pouvoir faire :

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

De cette façon, la version du graphique et la version de l'image Docker sont identiques.

Je viens de terminer la première ébauche et j'ai posté un PR pour cela.

@ngeor , @sslavic le PR que j'ai soumis ajoute à la fois les options --set et --values, pourriez-vous s'il vous plaît jeter un coup d'œil?

Salut @adshmh , ça a l'air bien ; malheureusement, je ne connais pas Go mais je vois que vous l'avez couvert avec les cas de test et tout, donc il fait probablement ce qu'il dit :) Merci !

Quand cette fonctionnalité sera-t-elle disponible ? En 2.9.0 ?

3471 ont raté la date limite pour 2.9 donc ce sera en 2.10.

Rouvrir ceci, car # 3471 doit être retiré.

Qu'est-ce que cela fait aux commentaires/etc dans le package d'archives ? par exemple, sont-ils dépouillés ou laissés seuls ou ??

Actuellement, j'essaie de faire la même chose avec yq mais cela ne fait que vider les valeurs finales après le traitement. c'est-à-dire que tous les commentaires, les lignes vides pour l'organisation, etc. ont disparu.

3471 a supprimé tous les commentaires, c'est pourquoi nous devions annuler ce PR. Voir https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783 pour plus d'informations

Retour à partir de 2.10 "feat: ajouter les options --set et --values ​​au 'paquet helm'" https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

Des news à ce sujet ?
Merci

Comme ci-dessus; personne n'a travaillé sur un suivi pour corriger les bogues dans # 3471, donc cela n'a pas été implémenté. Vous êtes plus que bienvenu pour bifurquer Helm et compiler avec # 3471 si vous êtes d'accord avec la suppression des commentaires du fichier de valeurs.

Est-ce fait ? J'ai essayé les versions 2.11.0 et 2.12.0 aucune d'entre elles ne semble avoir helm package --set...

+1. cela nous aidera vraiment dans CI pour arrêter de passer et de mettre à jour des yamls de valeurs avant de les emballer.

+1

--set-string peut également être utile, pourquoi ne pas autoriser toutes les options de remplacement qui existent dans install/upgrade.
Exécutez simplement le même code utilisé pour remplacer les valeurs de la commande package, il est logique que le package ait les valeurs de remplacement - ces drapeaux doivent être partagés comme avec install/upgrade.

2.13.1 n'a pas non plus une telle fonctionnalité, y a-t-il un calendrier pour cela ?

Comme mentionné précédemment, personne ne travaille actuellement sur ce problème et il n'y a pas de calendrier pour savoir quand un correctif sera disponible. N'hésitez pas à prendre celui-ci. Jetez un œil au #3471 pour des idées.

implémenté dans Helm 3 . Fermeture!

En regardant le code, il semble que #3471 se soit accidentellement introduit dans Helm 3, mais n'a jamais été retiré comme nous l'avons fait pour Helm 2 à cause de ce commentaire : https://github.com/helm/helm/pull/3471#issuecomment -381779783

Je rouvre cette demande de fonctionnalité car nous supprimons les indicateurs --set et --values ​​dans Helm 3 avec https://github.com/helm/helm/pull/7201. De toute façon, ils n'ont jamais fonctionné ... Tout ce qui est défini via --set ou --values n'a jamais été injecté dans le package, et il a introduit des régressions fatales avec helm package , à savoir le fait qu'il a supprimé sur les commentaires de values.yaml, que plusieurs membres de la communauté utilisent comme documentation.

Peut-être que je comprends mal, mais j'ai heureusement utilisé --set avec package pour définir des valeurs et cela a très bien fonctionné de 3.0.0 à 3.0.2, certainement pas un "no-op" comme décrit dans # 7201 .

Mes pipelines sont cassés depuis la 3.0.3. Cela fonctionnait en 3.0.2. Pourquoi n'est-ce pas considéré comme utile, si nous avons --version et --app-version. Comment sommes-nous censés modifier l'image et la balise pour qu'elles correspondent à --app-version ? Baiser ?

En regardant à nouveau le code, vous avez raison @lukaslarson et @maxhillaert. Cependant, il s'agissait toujours d'une fonctionnalité qui devait être annulée car elle supprimait tous les commentaires du fichier de valeurs du package. Il a été supprimé dans Helm 2, mais s'est accidentellement retrouvé dans Helm 3. Il n'a jamais été destiné à être expédié.

Si quelqu'un veut travailler sur la réimplémentation du #3471 qui conserve les commentaires, nous serions heureux d'examiner les relations publiques.

@bacongobbler Cela nous a cassé des trucs. Je serais intéressé à travailler sur un PR, mais cela semble non trivial, donc j'aimerais vérifier l'approche.

Il semble que gopkg.in/yaml.v3 prend en charge la conservation des commentaires lors d'un aller-retour. Ma proposition serait de faire Values un yaml Node . Ensuite, lors de la fusion des valeurs, parcourez l'arborescence de la sortie analysée plutôt que les cartes imbriquées. C'est certes moins ergonomique mais c'est le meilleur moyen de préserver les commentaires.

C'est un peu un problème car nous utilisons partout sigs.k8s.io/yaml qui est épinglé à v2 de la bibliothèque sous-jacente. Au minimum, cela nécessiterait de l'introduire en tant que dépendance distincte, ce qui est un peu beurk. Je ne sais pas quelle est la meilleure approche ici pour éviter de toucher à tout ce qui concerne yaml.

La meilleure option semble être la migration vers yaml.v3, il semble donc que vous soyez sur la bonne voie.

Si vous souhaitez commencer à travailler sur un PoC/fork de Helm qui utilise yaml.v3 au lieu de sig.k8s.io/yaml, ce serait une bonne voie à suivre. De cette façon, nous pouvons commencer à évaluer sa fonctionnalité par rapport à ce qu'il y a dans master .

Une fois que nous avons établi que yaml.v3 est la meilleure voie à suivre, nous pouvons déterminer comment procéder du point de vue du SDK.

Cela vous aide-t-il à vous débloquer ?

@jmcelwain Travaillez -vous activement là-dessus ? Je prendrai le relais avec plaisir si ce n'est pas le cas.

@ sreya92 J'étais occupé au travail. Voici où je me suis arrêté : passer à yaml.v3 était généralement facile, à l'exception de ce morceau ici . Je ne savais pas quelle était la meilleure approche pour gérer cela sans aller jusqu'à vendre la dépendance et la mettre à jour vers la v3.

Il semble que des travaux aient été effectués pour mettre à niveau , mais il n'y a pas d'autres informations dans les problèmes, etc., et je n'ai pas pris la peine d'ouvrir un problème. L'autre option serait simplement de conserver les deux dépendances, mais cela semble grossier.

Mon opinion personnelle serait qu'il s'agit d'un blocage pour ce problème, à moins que les mainteneurs estiment que transporter deux copies de bibliothèques similaires en vaut la peine. Je ne sais pas quelle est la LoE ici, mais nous devrions probablement travailler pour faire passer github.com/ghodss/yaml en v3 et mettre également à niveau la version vendue dans k8s. Cela rendrait tout cela beaucoup plus facile.

Ouvert https://github.com/ghodss/yaml/issues/61 pour se renseigner sur la possibilité d'un chemin de mise à niveau là-bas. Attendra d'avoir de leurs nouvelles avant de continuer quoi que ce soit d'autre - la mise à niveau des dépendances est bien préférable aux autres options de l'OMI.

@jmcelwain Il n'y a pas une grande quantité de code dans https://github.com/ghodss/yaml , il y a des demandes d'extraction non desservies à partir de 2017 : https://github.com/ghodss/yaml/pulls , et le code est MIT autorisé.

Est-ce que cette dépendance pèse vraiment lourd ? Il s'agit de quelques assistants de regroupement, mais parvient à contenir un problème qui, une fois résolu, pourrait améliorer la capacité de nombreux projets à définir dynamiquement les valeurs par défaut des packages au moment de la construction (notre cas d'utilisation est de ne pas avoir à maintenir plusieurs emplacements divergents pour stocker les balises de version quelque chose comme --set image.tag=${GIT_TAG} pour verrouiller les versions de graphique et d'image d'un projet).

Puis-je suggérer que nous n'attendions plus et que nous copions simplement le code nécessaire dans helm (je ne prendrais pas la peine de le vendre, juste de l'absorber et de l'adapter si nécessaire). Je pense que c'est un projet assez grand pour gérer la maintenance de ce wrapper et le marshaling YAML est une compétence de base (ne dit pas que vous devez maintenir votre propre analyseur, mais... !)

Étant donné que cela nous cause de la douleur en ce moment (et nous empêche de mettre à niveau depuis helm 3.0.2), je serais heureux de tenter ma chance.

Je préfère éviter cette situation. Il n'y a pas assez de mainteneurs pour maintenir à la fois un gestionnaire de paquets ET un analyseur YAML. Cela introduirait une charge de maintenance importante pour l'équipe.

@bacongobbler ce n'est _pas_ un analyseur yaml. Il utilise gopkg.in/yaml.v2 pour effectuer l'analyse proprement dite. Il s'agit d'environ 900 lignes de code wrapper reflect autour de cet analyseur. Le problème est qu'ils n'utilisent pas gopkg.in/yaml.v3 qui résoudrait ce problème.

Il me semble que la charge de maintenance liée à l'utilisation de cet intermédiaire mineur pour votre dépendance réelle est plus lourde que la maintenance de ce morceau de code.

Comme mentionné précédemment dans le fil, n'hésitez pas à proposer un PR en amont qui mettrait à jour ghodss/yaml vers yaml.v3. S'ils ne l'acceptent pas, n'hésitez pas à bifurquer le projet et à le maintenir si vous pensez que vous pouvez assumer le fardeau de la maintenance.

Soyons clairs cependant : nous _n'accepterons pas_ les demandes d'extraction qui forgent et ghodss/yaml du fournisseur dans Helm. Nous ne pouvons pas assumer la charge de maintenance supplémentaire d'une bibliothèque Go entière juste pour prendre en charge une fonctionnalité.

@bacongobbler s'il vous plaît jeter un oeil à mon PR ici : https://github.com/helm/helm/pull/7963

Il s'agit de 900 lignes de code avec les tests inclus et les fonctionnalités superflues supprimées.

À l'heure actuelle, vous dépendez de ce qui ressemble à une bibliothèque relativement non entretenue avec une empreinte beaucoup plus importante que ce que j'ai ajouté ici.

une bibliothèque Go entière juste pour prendre en charge une fonctionnalité

Vous utilisez une seule fonction de toute cette bibliothèque Go, et pour ce faire, vous vous êtes efforcé de créer un fork permanent qui obscurcit davantage la provenance du code.

n'hésitez pas à bifurquer le projet et à le maintenir si vous pensez que vous pouvez assumer le fardeau de la maintenance.

Je veux dire que vous exécutez déjà un fork à usage unique de ce code. Si le projet est abandonné, vous ne bénéficiez en fait d'aucune maintenance de la part de l'auteur d'origine.

Si vous le souhaitez, je peux prendre cette petite quantité de code dans mon PR et le mettre dans un référentiel et dire que je vais le maintenir (et je vais essayer de le faire), mais cela semble plutôt idiot.

Soyons clairs cependant : nous n'accepterons pas les demandes d'extraction qui forgent et ghodss/yaml du fournisseur dans Helm.

Pour mémoire, j'avais déjà poussé ce PR au moment où j'ai lu ceci, donc j'espère que vous reconsidérerez parce que je pense que vous avez une pensée en cache sur la « vendeur » et la « bibliothèque Go entière » (que je pourrais souvent être d'accord avec ) sans regarder le code impliqué. Mais discutons du code réel en question sur le PR. Je suis heureux d'être un propriétaire de code pour ce code si cela aide. Imaginons que je l'écrive en tant que contribution... C'est en quelque sorte ce que j'ai fait.

Peut-être qu'ils vont le fusionner : https://github.com/ghodss/yaml/pull/62

L'autre alternative que j'ai brièvement explorée était la possibilité de remplacer la conversion YAML en JSON via une autre dépendance ou la sérialisation via un format intermédiaire. Je ne connais pas assez l'écosystème Go pour savoir s'il s'agit d'un chemin viable - j'ai été quelque peu surpris de ne pas trouver plus de bibliothèques de type sérialisation lorsque j'ai brièvement regardé.

Toute idée sur le moment où nous pouvons avoir le --set back car nous l'utilisons pour automatiser l'empaquetage de la barre. C'était dans Helm 3.0.2 et maintenant, la mise à jour n'est plus prise en charge.

Nous sommes toujours bloqués sur la fusion de https://github.com/ghodss/yaml/pull/62 .

En regardant à nouveau le code, vous avez raison @lukaslarson et @maxhillaert. Cependant, il s'agissait toujours d'une fonctionnalité qui devait être annulée car elle supprimait tous les commentaires du fichier de valeurs du package. Il a été supprimé dans Helm 2, mais s'est accidentellement retrouvé dans Helm 3. Il n'a jamais été destiné à être expédié.

Si quelqu'un veut travailler sur la réimplémentation du #3471 qui conserve les commentaires, nous serions heureux d'examiner les relations publiques.

Est-ce important si les commentaires sont supprimés, s'il y a une mise en garde d'utiliser --set, je ne me soucie pas des commentaires.

Nous sommes toujours bloqués sur la fusion de ghodss/yaml#62 .

Je suppose que nous sommes coincés avec l'utilisation de 3.0.2 :(

3471 commentaires supprimés, que vous utilisiez --set ou non, ce qui a cassé les utilisateurs qui n'ont jamais utilisé cette fonctionnalité. Il a brisé la rétrocompatibilité pour tout le monde. Par conséquent, il ne peut pas être réintroduit avec une mise en garde, et c'est pourquoi nous attendons un correctif approprié en amont.

c'est pourquoi nous devons nous en tenir à 3.0.2

Nous sommes toujours bloqués sur la fusion de ghodss/yaml#62 .

Mais puisqu'il semble que cette dépendance ne soit plus maintenue, peut-être serait-il préférable d'utiliser une version forkée, n'est-ce pas ?

Changer cela est une bonne idée - mais doit être reporté à Helm 4. Quelqu'un devrait déposer un problème spécial pour changer d'analyseur YAML afin que nous puissions suivre cela pour le processus Helm 4.

Soyons clairs cependant : nous n'accepterons pas les demandes d'extraction qui forgent et ghodss/yaml du fournisseur dans Helm. Nous ne pouvons pas assumer la charge de maintenance supplémentaire d'une bibliothèque Go entière juste pour prendre en charge une fonctionnalité.

Étant donné qu'il semble que https://github.com/ghodss/yaml ne soit plus maintenu et qu'il n'y ait aucun signe de vie sur https://github.com/ghodss/yaml/pull/62 , vaut-il la peine de reconsidérer cette position, et réévaluer https://github.com/helm/helm/pull/7963 ?

Nous ne sommes pas intéressés à assumer la charge de maintenance consistant à prendre en charge une bibliothèque d'analyse YAML entière pour une seule fonctionnalité.

J'exhorte la communauté à envisager de travailler avec les mainteneurs existants de ghodss/yaml pour trouver un nouvel ensemble de mainteneurs disposés à soutenir le projet, à bifurquer le projet ou à trouver une nouvelle bibliothèque capable de conserver les commentaires.

Alors qu'est-ce que ce serait ?

• trouver de nouveaux mainteneurs pour supporter ghodss/YAML !?
• trouver quelqu'un pour bifurquer ghodss/YAML et utiliser YAML.v3 (et continuer à le supporter) !!
• utiliser YAML.v3 directement
• proposer de changer les parseurs YAML pour helm 4

une bibliothèque complète d'analyse YAML

Cela dénature la portée du code impliqué ici. C'est quelques wrappers autour d'autres analyseurs.

Nous ne sommes pas intéressés à assumer la charge de maintenance consistant à prendre en charge une bibliothèque d'analyse YAML entière pour une seule fonctionnalité.

Peut-être que cette confusion explique beaucoup de choses - l'analyseur est https://github.com/go-yaml/yaml , pas ghodss/YAML. Depuis https://github.com/ghodss/yaml :

Un wrapper autour de go-yaml

La solution simple est donc : arrêtez simplement d'utiliser l'emballage.

Les "emballages" ont une profonde influence sur certains des comportements. Ayant changé d'analyseurs (et de bibliothèques d'encapsulation) à quelques reprises au début du projet, les principaux responsables de la maintenance sont parfaitement conscients des petites différences entre eux, et de la façon dont ceux-ci produisent des problèmes de compatibilité de haut niveau.

Il est possible que nous envisagions d'utiliser un fork de ghodss/yaml SI ET UNIQUEMENT SI les propriétaires de ce fork s'étaient engagés à poursuivre la maintenance.

Peut-être que je peux être plus précis - arrêtez d'utiliser la bibliothèque de wrapper abandonnée et faites le comportement d'emballage équivalent/identique dans helm, ce que https://github.com/helm/helm/pull/7963 fait dans environ 250 LOC plus essais.

Oui, idéalement, quelqu'un réparerait dans ghodss/yaml, mais ce n'est plus maintenu. L'alternative n'attend sûrement pas Helm 4 ?

Je pense que la bifurcation est probablement la meilleure option, IMO ; @ghodss ne semble pas avoir eu d'activité sur GH depuis début 2019, et le dernier commit sur le repo remonte à il y a un an et demi (par @bradfitz). La dernière (seule) version date de 2017. S'il y a des problèmes de sécurité latents dans le code, ils ne seront pas corrigés sur main.

Je recommanderais fortement d'adopter un fork si quelqu'un est prêt à s'engager à le maintenir; Je ne vois aucun inconvénient à continuer à utiliser un package moribond et abandonné. Je suis d'accord que le passage à un emballage différent a plus de sens en tant que changement majeur (cela semble être un ascenseur suffisamment lourd pour que cela puisse facilement être une chose Helm 4, mais je ne vais pas spéculer davantage), mais je pense que cela pourrait être résolu avec une ligne replace dans go.mod .

Je suis prêt à m'engager à aider à co-maintenir un fork si quelqu'un d'autre l'est également ; Je n'ai pas assez de bande passante pour le faire moi-même en ce moment, mais j'en ai assez pour contribuer.

Certes, je suis surtout intéressé par cela afin que je puisse me débarrasser de ma pile de scripts sed pour emballer mes graphiques Helm, mais si c'est ce qu'il faut, tant pis.

Bonjour
Je viens de créer un plugin qui permet de définir des valeurs lors du packaging. pour le moment, il ne supporte que le drapeau set (parce que j'en avais besoin :sweat_smile: ) mais j'ai l'intention d'ajouter d'autres drapeaux. n'hésitez pas à pousser les PR si vous aimez ou ajouter des remarques afin de l'améliorer.
Merci

Juste au cas où quelqu'un n'aurait pas suivi, il y a eu des progrès dans ghodss/yaml#62 pour contacter un responsable, alors j'espère que nous aurons bientôt de bonnes nouvelles !

Ce problème a été marqué comme obsolète, car il est resté ouvert pendant 90 jours sans aucune activité. Ce fil sera automatiquement fermé dans 30 jours si aucune autre activité ne se produit.

Certainement pas obsolète. J'ai essayé de trouver le temps de suivre avec https://github.com/ghodss/yaml/pull/62 et de voir si nous pouvons aider à le fusionner pour débloquer les progrès sur ce problème. Comme mon organisation a augmenté notre dépendance vis-à-vis de Helm, nous continuons à vouloir pouvoir intégrer des valeurs dans un graphique packagé par build par CI.

J'ai supprimé tous les commentaires qui demandaient une mise à jour du statut car ils n'ajoutent rien à la conversation en cours. @jmcelwain a fourni une mise à jour de statut il y a pas moins de 5 jours (merci, btw) et est aussi bonne que n'importe quelle autre. Comme mentionné précédemment, la solution à ce problème est délicate et implique la mise à jour ou le fork de plusieurs dépendances, il y a donc une diligence raisonnable requise.

Lorsque nous aurons plus d'informations à partager, nous mettrons à jour le fil.

Comme solution de contournement, j'ai utilisé https://github.com/mikefarah/yq pour mettre à jour mon tableau de barre avant l'emballage :

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

Dans notre CI, nous construisons l'image app / docker et le graphique dans le même pipeline (pour garantir que l'application et le graphique évoluent avec le même versioning). Les valeurs par défaut du graphique dépendent de la version de l'image créée précédemment.

La solution de contournement yq peut être facilement intégrée dans un pipeline, mais il semble étrange que ce cas d'utilisation ne soit pas correctement couvert par helm !

Il n'y a donc aucun moyen intégré avec helm de définir image.tag pendant/avant la phase de package ?

edit : trouvé cette solution dans mon cas, nous devons utiliser Chart.AppVersion pour la balise d'image car nous emballons le graphique avec le même versioning.

edit 2 : Chart.AppVersion / ne fonctionne pas avec le graphique partagé (exp un graphique de démarrage à ressort utilisé dans plusieurs graphiques parapluie)

ma conclusion : Vraiment besoin de définir image.tag pendant la phase de package

Des news sur cette fonctionnalité ?