solicitação relacionada: #2566

Eu comecei a trabalhar nisso.
Considerando os comentários em #2566, estamos procurando por --values ​​ou --set (ou ambos?)

Um bom caso de uso é descrito na edição que abri ( #3198 ), na qual gostaria de poder fazer:

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

Dessa forma, a versão do gráfico e a versão da imagem do docker são a mesma.

Acabei de concluir o primeiro rascunho e postei um PR para isso.

@ngeor , @sslavic o PR que enviei adiciona as opções --set e --values, você poderia dar uma olhada?

Oi @adshmh , parece bom; infelizmente eu não conheço o Go, mas vejo que você cobriu com os casos de teste e tudo, então provavelmente faz o que diz :) Obrigado!

Quando esse recurso estará disponível? Em 2.9.0?

3471 perdeu o prazo para 2.9, então será em 2.10.

Reabrindo isso, pois #3471 precisa ser desfeito.

O que isso faz com os comentários/etc no pacote de arquivo? por exemplo, eles são despojados ou deixados sozinhos ou ??

Atualmente estou tentando fazer a mesma coisa com yq , mas apenas despeja os valores finais após o processamento. ou seja, todos os comentários, linhas em branco para organização, etc, desapareceram.

3471 retirou todos os comentários, e é por isso que precisávamos apoiar esse PR. Consulte https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783 para obter mais informações

Revertido de 2.10 "feat: add --set e --values ​​options para 'helm package'" https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

Alguma notícia sobre isso?
Obrigado

O mesmo que acima; ninguém trabalhou em um acompanhamento para corrigir os bugs em #3471, então isso não foi implementado. Você é mais do que bem-vindo para fazer um fork do Helm e compilar contra #3471 se estiver de acordo com os comentários sendo removidos do arquivo de valores.

Isso é feito? Eu tentei as versões 2.11.0 e 2.12.0 nenhuma delas parece ter helm package --set...

+1. isso realmente nos ajudará em CI para parar de passar e atualizar yamls de valores antes de empacotar.

+1

--set-string também pode ser útil, por que não permitir todas as opções de substituição que existem na instalação/atualização.
Basta executar o mesmo código usado para substituir os valores do comando do pacote, faz sentido que o pacote tenha os valores de substituição - esses sinalizadores devem ser compartilhados da mesma forma que na instalação/atualização.

2.13.1 também não possui esse recurso, existe algum cronograma para isso?

Como mencionado anteriormente, ninguém está trabalhando nisso no momento e não há cronograma para quando uma correção estará disponível. Sinta-se livre para assumir este. Dê uma olhada em # 3471 para idéias.

implementado no Helm 3 . Fechando!

Olhando para o código, parece que o #3471 acidentalmente entrou no Helm 3, mas nunca foi retirado como fizemos no Helm 2 devido a este comentário: https://github.com/helm/helm/pull/3471#issuecomment -381779783

Estou reabrindo esta solicitação de recurso, pois estamos removendo os sinalizadores --set e --values ​​no Helm 3 com https://github.com/helm/helm/pull/7201. Eles nunca funcionaram de qualquer maneira ... Qualquer coisa definida via --set ou --values nunca foi injetada no pacote, e introduziu algumas regressões fatais com helm package , ou seja, o fato de que ele removeu comentários de values.yaml, que vários membros da comunidade usam como documentação.

Talvez eu esteja mal-entendido, mas felizmente estou usando --set com package para definir valores e funcionou muito bem de 3.0.0 a 3.0.2, definitivamente não é um "no-op" conforme descrito em #7201 .

Meus pipelines estão quebrados desde 3.0.3. Isso estava funcionando em 3.0.2. Por que isso não é considerado útil, se temos --version e --app-version. Como devemos editar a imagem e a tag , para corresponder a --app-version? Bash?

Olhando para o código novamente, você está correto @lukaslarson e @maxhillaert. No entanto, esse ainda era um recurso que deveria ser revertido, pois removeu todos os comentários do arquivo de valores do pacote. Ele foi removido no Helm 2, mas acidentalmente entrou no Helm 3. Ele nunca foi planejado para ser enviado.

Se alguém quiser trabalhar na reimplementação do nº 3471 que retém comentários, ficaremos felizes em analisar os PRs.

@bacongobbler Isso quebrou algumas coisas para nós. Eu estaria interessado em trabalhar em um PR, mas não parece trivial, então gostaria de verificar a abordagem.

Parece que gopkg.in/yaml.v3 suporta a retenção de comentários em viagens de ida e volta. Minha proposta seria fazer Values um yaml Node . Então, ao unir valores, percorra a árvore de saída analisada em vez de mapas aninhados. Isso é certamente menos ergonômico, mas a melhor maneira de preservar os comentários.

Isso é um pouco problemático porque estamos usando sigs.k8s.io/yaml em todos os lugares que estão fixados em v2 da lib subjacente. No mínimo, isso exigiria apresentá-lo como uma dependência separada, o que é meio chato. Não tenho certeza de qual é a melhor abordagem aqui para evitar tocar em tudo que lida com yaml.

A melhor opção parece ser migrar para yaml.v3, então parece que você está no caminho certo.

Se você quiser começar a trabalhar em um PoC/fork do Helm que usa yaml.v3 em vez de sig.k8s.io/yaml, esse seria um bom caminho a seguir. Dessa forma, podemos começar a avaliar sua funcionalidade em comparação com o que está em master .

Depois de estabelecermos que yaml.v3 é o melhor caminho a seguir, podemos descobrir como proceder do ponto de vista do SDK.

Isso ajuda a desbloquear você?

@jmcelwain Você está trabalhando ativamente nisso? Eu terei prazer em assumir isso se não.

@sreya92 Fiquei ocupado no trabalho. Aqui é onde eu parei: mudar para yaml.v3 foi mais fácil, com exceção desta parte aqui . Não tinha certeza de qual era a melhor abordagem para lidar com isso sem chegar ao ponto de vender a dependência e atualizá-la para v3 lá.

Parece que houve algum trabalho feito para atualizar , mas não há outras informações em problemas, etc., e não me preocupei em abrir um problema. A outra opção seria apenas manter as duas dependências, mas isso parece nojento.

Minha opinião pessoal seria que este é um bloqueador para este problema, a menos que os mantenedores sintam que vale a pena carregar duas cópias de libs semelhantes. Não tenho certeza de qual é o LoE aqui, mas provavelmente devemos trabalhar para obter github.com/ghodss/yaml para v3 e obter a versão vendida em k8s atualizada também. Isso tornaria tudo muito mais fácil.

Abriu https://github.com/ghodss/yaml/issues/61 para perguntar sobre a possibilidade de um caminho de atualização lá. Esperará para ouvi-los antes de continuar com qualquer outra coisa - atualizar as dependências é preferível a outras opções IMO.

@jmcelwain Não há uma grande quantidade de código em https://github.com/ghodss/yaml , há solicitações de pull não atendidas de 2017: https://github.com/ghodss/yaml/pulls , e o código é MIT licenciado.

Essa dependência está realmente puxando seu peso? São alguns auxiliares de empacotamento, mas estão conseguindo manter um problema que, quando resolvido, pode melhorar a capacidade de muitos projetos de definir padrões de pacote dinamicamente em tempo de compilação (nosso caso de uso é não ter que manter vários locais divergentes para armazenar tags de versão algo como --set image.tag=${GIT_TAG} para um gráfico de passo fixo e versões de imagem para um projeto).

Posso sugerir que não esperemos mais e apenas copie o código necessário para o leme (eu não me incomodaria em fornecê-lo, apenas absorva e adapte conforme necessário). Eu acho que é um projeto grande o suficiente para lidar com a manutenção desse wrapper e o empacotamento YAML é uma competência central (não estou dizendo que você deve manter seu próprio analisador, mas...!)

Como isso está nos causando dor agora (e nos impedindo de atualizar do helm 3.0.2), eu ficaria feliz em tentar.

Prefiro evitar essa situação. Não há mantenedores suficientes para manter um gerenciador de pacotes E um analisador YAML. Isso introduziria uma carga de manutenção significativa para a equipe.

@bacongobbler _não_ é um analisador yaml. Ele usa gopkg.in/yaml.v2 para fazer a análise real. São cerca de 900 linhas de código wrapper reflect em torno desse analisador. O problema é que eles não usam gopkg.in/yaml.v3 que resolveria esse problema.

Parece-me que o fardo de manutenção de usar esse intermediário menor para sua dependência real é um fardo maior do que manter esse pedaço de código.

Como mencionado anteriormente no tópico, sinta-se à vontade para propor um upstream PR que atualize ghodss/yaml para yaml.v3. Se eles não aceitarem, sinta-se à vontade para dividir o projeto e mantê-lo se achar que pode assumir o fardo de manutenção.

Deixe-me ser claro, porém: nós _não_ aceitaremos solicitações pull que bifurcam e fornecem ghodss/yaml no Helm. Não podemos assumir a carga de manutenção adicional de uma biblioteca Go inteira apenas para oferecer suporte a um recurso.

@bacongobbler , por favor, dê uma olhada no meu PR aqui: https://github.com/helm/helm/pull/7963

São 900 linhas de código com os testes incluídos e a funcionalidade supérflua removida.

Agora você está dependendo do que parece ser uma biblioteca relativamente sem manutenção com uma pegada muito maior do que a que eu adicionei lá.

uma biblioteca Go inteira apenas para oferecer suporte a um recurso

Você usa toda uma função de toda esta biblioteca Go e, para fazer isso, você se esforçou para criar uma bifurcação permanente que obscurece ainda mais a origem do código.

sinta-se à vontade para bifurcar o projeto e mantê-lo se achar que pode assumir a carga de manutenção.

Quero dizer, você já executa um fork de propósito único deste código. Se o projeto for abandonado, você não está realmente se beneficiando de nenhuma manutenção do autor original.

Se você quiser, posso pegar essa pequena quantidade de código no meu PR e colocá-lo em um repositório e dizer que vou mantê-lo (e tentarei fazê-lo), mas parece bastante bobo.

Deixe-me ser claro, porém: não aceitaremos pull requests que fork e vendor ghodss/yaml no Helm.

Para que conste, eu já tinha empurrado esse PR quando li isso, então espero que você reconsidere, porque acho que você está tendo um pensamento em cache sobre 'vendor' e 'toda a biblioteca Go' (com o que muitas vezes posso concordar com ) sem olhar para o código envolvido. Mas vamos discutir o código real em questão no PR. Fico feliz em ser um proprietário de código para este código, se isso ajudar. Vamos imaginar que eu escrevi como uma contribuição... Eu meio que fiz.

Talvez eles mesclem: https://github.com/ghodss/yaml/pull/62

A outra alternativa que explorei brevemente foi a possibilidade de substituir a conversão de YAML para JSON por alguma outra dependência ou serialização por meio de algum formato intermediário. Não estou familiarizado o suficiente com o ecossistema Go para saber se esse é um caminho viável - fiquei um pouco surpreso por não encontrar mais bibliotecas do tipo serialização quando olhei brevemente.

Qualquer ideia de quando podemos ter o --set de volta, pois usamos isso para automatizar o empacotamento do leme. Estava no Helm 3.0.2 e agora desde que a atualização não é mais suportada.

Ainda estamos bloqueados para mesclar https://github.com/ghodss/yaml/pull/62 .

Olhando para o código novamente, você está correto @lukaslarson e @maxhillaert. No entanto, esse ainda era um recurso que deveria ser revertido, pois removeu todos os comentários do arquivo de valores do pacote. Ele foi removido no Helm 2, mas acidentalmente entrou no Helm 3. Ele nunca foi planejado para ser enviado.

Se alguém quiser trabalhar na reimplementação do nº 3471 que retém comentários, ficaremos felizes em analisar os PRs.

Importa se os comentários forem removidos, se houver uma ressalva de usar --set, não me importo com comentários.

Ainda estamos bloqueados para mesclar ghodss/yaml#62 .

Acho que estamos presos ao uso do 3.0.2 :(

3471 removeu comentários, independentemente de você ter usado --set ou não, por isso quebrou os usuários que nunca usaram esse recurso. Ele quebrou a compatibilidade com versões anteriores para todos. Portanto, ele não pode ser reintroduzido com uma ressalva, e é por isso que estamos aguardando uma correção adequada upstream.

é por isso que temos que ficar no 3.0.2

Ainda estamos bloqueados para mesclar ghodss/yaml#62 .

Mas como parece que essa dependência não é mais mantida, talvez fosse melhor usar uma versão bifurcada, não é?

Alternar isso é uma boa ideia -- mas deve ser adiado para o Helm 4. Alguém deve registrar um problema especial para alternar analisadores YAML para que possamos rastrear isso para o processo do Helm 4.

Deixe-me ser claro, porém: não aceitaremos pull requests que fork e vendor ghodss/yaml no Helm. Não podemos assumir a carga de manutenção adicional de uma biblioteca Go inteira apenas para oferecer suporte a um recurso.

Dado que parece que https://github.com/ghodss/yaml não é mais mantido e não há sinal de vida em https://github.com/ghodss/yaml/pull/62 , vale a pena reconsiderar essa posição e reavaliando https://github.com/helm/helm/pull/7963 ?

Não estamos interessados ​​em assumir a carga de manutenção de oferecer suporte a uma biblioteca de análise YAML inteira apenas para um recurso.

Eu gostaria que a comunidade considerasse trabalhar com os mantenedores existentes do ghodss/yaml para encontrar um novo conjunto de mantenedores dispostos a apoiar o projeto, bifurcar o projeto ou encontrar uma nova biblioteca que possa preservar comentários.

Então o que seria?

• encontrar novos mantenedores para suportar ghodss/YAML!?
• encontre alguém para fazer o fork do ghodss/YAML e use o YAML.v3 (e continue a apoiá-lo) !!
• use YAML.v3 diretamente
• propor a troca de analisadores YAML para o leme 4

uma biblioteca inteira de análise YAML

Isso deturpa o escopo do código envolvido aqui. São alguns wrappers em torno de outros analisadores.

Não estamos interessados ​​em assumir a carga de manutenção de oferecer suporte a uma biblioteca de análise YAML inteira apenas para um recurso.

Talvez essa confusão explique muito - o analisador é https://github.com/go-yaml/yaml , não ghodss/YAML. De https://github.com/ghodss/yaml :

Um wrapper em torno de go-yaml

Portanto, a solução simples é: basta parar de usar o wrapper.

Os "wrappers" têm uma profunda influência em alguns dos comportamentos. Tendo trocado analisadores (e bibliotecas de wrapper) algumas vezes no início do projeto, os mantenedores do núcleo estão bem cientes das pequenas discrepâncias entre eles, e como eles produzem problemas de compatibilidade de alto nível.

Existe a possibilidade de considerarmos o uso de um fork de ghodss/yaml SE E SOMENTE SE os proprietários desse fork estivessem comprometidos com a manutenção contínua.

Talvez eu possa ser mais preciso - pare de usar a biblioteca de wrapper abandonada e faça o comportamento de encapsulamento equivalente/idêntico no helm, que é o que https://github.com/helm/helm/pull/7963 faz em cerca de 250 LOC mais testes.

Sim, idealmente, alguém consertaria em ghodss/yaml, mas não é mais mantido. Certamente a alternativa não está esperando até o Helm 4?

Acho que bifurcar é provavelmente a melhor opção, IMO; O @ghodss não parece ter tido nenhuma atividade no GH desde o início de 2019, e o último compromisso com o repo foi há um ano e meio (por @bradfitz). A última (única) versão foi em 2017. Se houver algum problema de segurança latente no código, eles não serão corrigidos no main.

Eu defendo fortemente a adoção de um fork se alguém estiver disposto a se comprometer a mantê-lo; Não vejo nenhuma desvantagem em relação a continuar usando um pacote moribundo e abandonado. Concordo que mudar para um wrapper diferente faz mais sentido como uma grande mudança (parece um levantamento pesado o suficiente para que possa ser facilmente uma coisa do Helm 4, mas não vou especular mais), mas acho que isso pode ser resolvido com uma linha replace em go.mod .

Estou disposto a me comprometer a ajudar a manter um fork se outra pessoa também estiver; Não tenho largura de banda suficiente para fazer isso sozinho agora, mas tenho o suficiente para contribuir.

É certo que estou mais interessado nisso para poder me livrar da minha pilha de scripts sed para empacotar meus gráficos do Helm, mas se for preciso, que assim seja.

Olá
Acabei de criar um plugin que permite definir valores ao empacotar. no momento ele apenas suporta o sinalizador set (porque eu precisava disso :sweat_smile: ) mas pretendo adicionar outros sinalizadores. não hesite em enviar PRs se quiser ou adicionar comentários para melhorá-lo.
Obrigado

Caso alguém não esteja acompanhando, houve algum progresso em ghodss/yaml#62 contatando um mantenedor, então esperamos ouvir boas notícias em breve!

Este problema foi marcado como obsoleto porque está aberto há 90 dias sem atividade. Este tópico será encerrado automaticamente em 30 dias se nenhuma outra atividade ocorrer.

Definitivamente não é obsoleto. Estou tentando encontrar tempo para acompanhar https://github.com/ghodss/yaml/pull/62 e ver se podemos ajudar a mesclar para desbloquear o progresso desse problema. Como minha organização aumentou nossa dependência do Helm, continuamos a querer poder inserir valores em um gráfico empacotado de compilação por CI.

Excluí todos os comentários que solicitaram uma atualização de status, pois eles não adicionam nada à conversa em questão. @jmcelwain forneceu uma atualização de status há menos de 5 dias (obrigado, btw) e é tão bom quanto qualquer outro. Como mencionado anteriormente, a solução para esse problema é complicada e envolve a atualização ou bifurcação de várias dependências, portanto, é necessária alguma diligência.

Quando tivermos mais informações para compartilhar, atualizaremos o tópico.

Como solução alternativa, usei https://github.com/mikefarah/yq para atualizar meu gráfico de leme antes do empacotamento:

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

Em nosso CI, criamos a imagem do aplicativo/docker e o gráfico no mesmo pipeline (para garantir que o aplicativo e o gráfico evoluam juntos com o mesmo controle de versão). Os valores padrão para o gráfico dependem da versão da imagem criada anteriormente.

A solução alternativa do yq pode ser facilmente integrada em um pipeline, mas parece estranho que esse caso de uso não seja coberto corretamente pelo helm !

Então, eles não são uma maneira integrada com o leme para definir image.tag durante/antes da fase do pacote?

edit : encontrei esta solução no meu caso, precisamos usar o Chart.AppVersion para a tag de imagem porque empacotamos o gráfico com o mesmo versionamento.

edit 2 : Chart.AppVersion / não funciona com gráfico compartilhado (exp um gráfico de inicialização de mola usado em vários gráficos guarda-chuva)

minha conclusão : Realmente precisa definir image.tag durante a fase de pacote

Alguma novidade sobre esse recurso?