Helm: Acessando valores do subchart com traço no nome

Essa é uma boa pergunta. Não tive problemas para fazer isso, mas é uma inconsistência. @technosophos Devemos alterar um deles para corresponder ao outro?

No momento, estou tendo problemas para acessar os valores desse subchart.

O próximo bloco me dá um erro.

{{ if .Values.gitlab-runner.enabled }}

Erro: FALHA NO UPGRADE: erro de análise em "gitlab / templates / deployment.yaml": template: gitlab / templates / deployment. yaml: 217 : mau caráter U + 002D '-'

Use a função de modelo index para acessar um valor com um '-' no nome: {{ index .Values "gitlab-runner" }} .

E provavelmente deveríamos mudar a convenção. Isso torna difícil lidar com coisas como essa. Designei o problema para mim mesmo para mudar a convenção.

obrigado, funciona assim.

@prydonius Você se lembra do motivo pelo qual decidimos inicialmente que os gráficos deveriam ser nomeados com travessões? Eu estava examinando documentação mais antiga e este tem sido um precedente que estabelecemos desde o início. Estou pensando que talvez não seja uma boa ideia mudar isso.

Estou tentando entender como funciona o índice.
Como posso acessar servicename value de:

mysub-chart:
  servicename: mysubchart-service

?
Solução encontrada: {{ index .Values "mysub-chart" "servicename" }}

Como você usaria nomes de traços em uma estrutura de controle, como um bloco with ou range ?

{{- range $key, $value := .Values.my-service-name.deployment.annotations }}

@spearsem Acho que o comentário acima tem a solução alternativa certa para esse problema. Eu acho que isso deve funcionar:

{{- range $key, $value := index .Values "my-service-name" "deployment" "annotations" }}

Caso contrário, acho que você pode instanciar uma variável que aponta para as anotações e usar isso dentro do intervalo ou com blocos. Por exemplo

{{ $annotations := index .Values "my-service-name" "deployment" "annotations" }}
{{- range $key, $value := $annotations }}

@bacongobbler Isso também funciona para with ? Não estou familiarizado com a implementação de with para saber se ele pode utilizar o resultado de outra avaliação de função como "o contexto".

text / template parece dizer que deve funcionar com qualquer estrutura, então presumo que sim.

Se o valor do pipeline estiver vazio, nenhuma saída será gerada; caso contrário, ponto é definido com o valor do pipeline e T1 é executado.

O método variável não parece funcionar para mim. . O erro só acontece uma linha depois.

A convenção de nomenclatura de porta do Istio também requer traços (consulte Requisitos de especificação de pod ).

Existe alguma solução alternativa para definir vars em cli?

helm install --set one-two.three=10 releasename ./chartname

esta é uma incoerência real e eu também tenho o problema.
Uma solução é usar um alias em requirements.yaml para que o nome de seu subchart seja alterado para algo sem o -, mas isso é realmente uma dor.

Eu também estou tendo esse problema.

Acho que seria bom se o Helm passasse os valores do gráfico pai para subchart-name usando o nome camelcase-ify, por exemplo, subchartName . Isso tornaria a convenção de nomes de gráfico e a convenção de nomes de variáveis ​​compatíveis entre si, bem como contornar os problemas de sintaxe acima.

Isso não funciona em modelos, este código de exemplo:
{{índice .Values ​​"primeira chave" "segunda chave"}}
funciona em NOTES.txt, mas em _helpers.tpl ao emitir um comando de atualização:
_helpers. tpl: 24 : 3: executando "test.template" em

Cliente: & version.Version {SemVer: "v2.6.2", GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState: "clean"}
Servidor: & version.Version {SemVer: "v2.7.0", GitCommit: "08c1144f5eb3e3b636d9775617287cc26e53dba4", GitTreeState: "clean"}

A mesma coisa com as duas versões iguais:
Cliente: & version.Version {SemVer: "v2.6.2", GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState: "clean"}
Servidor: & version.Version {SemVer: "v2.6.2", GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState: "clean"}

kubectl é:
Versão do cliente: version.Info {Major: "1", Minor: "9", GitVersion: "v1.9.2", GitCommit: "5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState: "clean", BuildDate: "2018-01-18T10: 09: 24Z ", GoVersion:" go1.9.2 ", Compilador:" gc ", Plataforma:" darwin / amd64 "}
Versão do servidor: version.Info {Major: "1", Minor: "8", GitVersion: "v1.8.4", GitCommit: "9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState: "clean", BuildDate: "2017-11-20T05: 17: 43Z ", GoVersion:" go1.8.3 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

@svidrascu , verifique se você possui os valores definidos no arquivo Chart.yaml para esse subchart específico. Parece que o mecanismo de modelagem não consegue encontrar sua variável

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

Problemas obsoletos apodrecem após 30 dias de inatividade.
Marque o problema como novo com /remove-lifecycle rotten .
Problemas podres são encerrados após 30 dias adicionais de inatividade.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle podre
/ remove-lifecycle stale

fechado via https://github.com/helm/helm/pull/4379

Para sua informação, uma alteração ao # 4379 foi feita em # 4400.

Isso é uma porcaria - sem traços, sem sublinhados, sem letras maiúsculas. Como definir o nome do gráfico compicado para dois (ou mais) componentes semelhantes? Alterar um . simples para " " é simplesmente horrível :(

@ksemaev consulte # 4400. Conforme mencionado anteriormente, ainda queremos que os usuários usem travessões em seus nomes de pacotes, mas eles devem estar cientes das "pegadinhas" em torno de certas limitações com o sistema de modelos.

Opa, apertou o botão de fechar com os dedos gordos: rindo:

Existe alguma solução alternativa para definir vars em cli?

helm install --set one-two.three=10 releasename ./chartname

Se alguém está se perguntando, isso parece funcionar como leme e leme v2.14.2 .

$ helm install --set one-two.three=10 --name foo stable/mariadb
$ helm get values foo
# one-two:
#  three: 10

Realmente não faz sentido permitir travessões nos nomes dos gráficos se você não permitir travessões nos valores. O motivo é que às vezes os valores são nomes de gráficos. Por exemplo, tenho sub-chart.value que desejo especificar no arquivo de valores.yaml do gráfico pai para substituir os valores do filho. Também quero usar o mesmo valor no modelo pai.

Para outras pessoas, se você precisar
{{-if and value1 value2 }} você precisaria fazer isso então:

{{- if .Values.loki.enabled }}
{{- if index .Values "prometheus-operator" "grafana" "enabled" }}
{{- if index .Values "prometheus-operator" "grafana" "sidecar" "datasources" "enabled" }}

Eu tenho uma pergunta ligeiramente diferente. Vamos dar um exemplo aleatório -
{{- if index .Values ​​"prometheus-operator" "grafana" "sidecar" "datasources" "enabled"}}

Minha pergunta é se não sabemos "/ prometheus-operator" como faço para me referir a essa chave usando o índice. Basicamente, gostaria de obter a primeira chave dos .Values ​​(chave sendo dinâmica, não é constante no meu caso e então como referenciar este mapa por chave no índice. Alguém pode me avisar.

eu usei / "nithin-kumar" / para este problema é um problema de "-", tentei os caracteres de escape

Alguém tem uma solução ao usar o toYaml?
Falha com
<toYaml>: wrong number of args for toYaml: want 1 got 5
com ou sem o uso da função index .

qualquer correção para U + 002D '-'

@ mods / mantenedores

Existe uma atualização sobre isso?

Que tipo de atualização?

Olá, este problema foi aberto há um tempo, mas o problema ainda ocorre.

As diretrizes do Helm Chart afirmam que o gráfico deve ser nomeado com travessões (https://helm.sh/docs/chart_best_practices/conventions/)
Mas a modelagem nos torna difíceis se tentarmos colocar travessões em values.yaml para espelhar os nomes dos gráficos, se tentarmos usar esses valores de travessões como este:

{{ .Values.my-chart.name }}

Lendo a postagem acima, parece que se eu ainda quiser usar travessões desta forma, preciso usar index :

{{ index .Values "my-chart" "name" }}

Além disso, as chaves em values.yaml devem ser CamelCased (https://helm.sh/docs/chart_best_practices/values/).

Não acho que a nomenclatura das chaves deva afetar os modelos do Helm.

Está planejado normalizar isso?

@bacongobbler , como se vai ser "consertado", ou seja, poderemos usar travessões sem recorrer a hacks e truques, ou se este é um definitivo "Não consertar, se acostumar, fork ou find algo mais"

É uma limitação da linguagem do modelo Go. Se desejar uma alteração, você deve arquivá-la no projeto Go: https://github.com/golang/go

Se / quando eles consertarem, nós obteremos suporte para isso.

No estilo típico do Google ("os usuários geralmente estão errados"), foi dado um definitivo "Não vou consertar, se acostumar, bifurcar ou encontrar outra coisa" https://github.com/golang/go/issues/ 23710. Eu acho que as razões dadas (que falam especificamente sobre o helm usecase) são perfeitamente válidas, mas os autores de go realmente não se importam.

https://github.com/golang/go/issues/23710#issuecomment -363488583 menciona duas soluções - desencorajar o uso de travessões (a abordagem atual) ou "reescrever os pipelines de modelo [helm] para usar a função de índice automaticamente". Embora eu reconheça que pode ser um grande empreendimento, não seria possível ter um pré-processador de modelo que pudesse fazer exatamente isso? Talvez haja um gancho ou algo que possa ser escrito para pré-processar apenas isso? Embora seja obviamente possível contornar isso, parece um pouco infantil dos go autores e vale a pena consertar helm .

Embora eu admita que pode ser uma grande empresa

Bingo.

Quer dizer, seria ótimo se pudéssemos fazer algumas melhorias na qualidade de vida nesta área, mas existem algumas áreas que têm uma prioridade um pouco maior em nossas mentes agora (suporte OCI mudando para estável, por exemplo). E escrever um pré-processador é definitivamente uma tarefa importante.

Se você estiver interessado em contribuir, fique à vontade para dar uma olhada!

Para mim, ter clareza sobre a situação é um grande primeiro passo. Temos o seguinte:

• É uma restrição da linguagem de modelo go
• Os autores de go (atualmente) não têm helm irritados devem se acostumar com isso ou implementar um pré-processador de modelo. Eles não vão.
• Os autores de helm têm muitas prioridades mais altas do que isso, pois há uma solução relativamente fácil e implementar um pré-processador de modelo é quase certamente uma tarefa importante. Também resolveria um pequeno problema, dada a relativamente fácil solução, então provavelmente não chegará ao topo da pilha em um futuro próximo, se é que isso acontecerá.
• Qualquer um pode dar uma olhada e, com tempo suficiente e go expertise, oferecer algo para helm (as go pessoas aparentemente não estão interessadas), embora obviamente precisariam ser relativamente elegante para a utilidade prática limitada trazida e a provável complexidade adicionada.

Se todos acharem que isso é muito preciso e justo, pararei de incomodar a todos! :-)

Eu acrescentaria que qualquer pessoa que quiser dar uma olhada nisso deve considerar escrever um HIP - consulte https://github.com/helm/community/blob/master/hips/hip-0001.md

Senão sim

"reescrevendo os pipelines de modelo [helm] para usar a função de índice automaticamente". Embora eu reconheça que pode ser um grande empreendimento, não seria possível ter um pré-processador de modelo que pudesse fazer exatamente isso?

Não está claro para mim o que isso realmente significa, você apenas quer dizer que o Helm deve converter as teclas com caixa de traço em teclas com caixa de camelo ao construir seu mapa de valores?

@prydonius , eu realmente não tinha começado a pensar sobre isso em um nível de implementação. Traços são válidos como chaves JSON, assim como chaves YAML válidas, então, a suposição da perspectiva do usuário é que não há razão para eles não funcionarem como chaves em modelos helm . Como os modelos são go modelos, essa suposição não é válida. Parece que alguns (muitos?) Usuários encontram apenas go modelos no contexto de helm , e acham isso bastante arbitrário e frustrante.

Acho que uma abordagem poderia ser analisar e converter os valores em caixa de camelo e, em seguida, examinar os modelos e fazer o mesmo. Mas concordo que a infraestrutura para isso é provavelmente um fardo muito maior do que valeria a pena. Na verdade, uma explicação na barra lateral nos documentos de introdução dizendo algo como:

Porque helm usa a linguagem de modelos go , você não pode usar travessões - em chaves diretamente nos modelos usando o mecanismo de referência normal {{ .Values.mybasekey.my-key }} (isto não é válido). Esta é uma restrição da linguagem de modelagem go e algo que go autores se recusaram a apoiar. Se você realmente deseja usar travessões em suas chaves, pode contornar essa restrição usando a função index , como {{ index .Values.mybasekey "my-key" ]} . Como essa solução alternativa é relativamente fácil, atualmente não há planos para oferecer suporte ao uso de travessões em nomes de chave sem index em helm . Nomes de subcharts também serão chaves em modelos, então se você usar um subchart com um traço no nome e quiser substituir um valor, você precisará fornecer um alias para o nome do gráfico ou usar a solução alternativa mencionada aqui ( {{ index .Values "my-chart" "name" }} ).

provavelmente seria a melhor situação. Para mim, pelo menos, o que achei frustrante foi a falta de clareza sobre exatamente por que não funcionou, onde estava o problema e quem poderia / deveria corrigi-lo. A seção atual na seção de práticas recomendadas do

Não tenho certeza de onde tal explicação, se correta, deve ir embora.

1 Concordo que precisamos dizer isso na documentação em algum lugar, pelo menos.

É definitivamente confuso, mas não vejo um caminho para tornar isso mais fácil no Helm. Qualquer template helper que adicionarmos agirá como uma função da mesma maneira que index (por exemplo, toYaml , toJson conjunto de funções do Helm). A única maneira que vejo de fornecer acesso mais direto seria removendo travessões nas chaves, mas, como você mencionou, é YAML / JSON válido e isso provavelmente seria ainda mais confuso. Em última análise, o analisador de modelo Go não suporta isso e não há muito que possamos fazer sobre isso sem bifurcá-lo.

Aqui está um exemplo prático de toYaml :
{{- toYaml Values.jobs.update-es.resources | nindent 12 }} = erro

{{- toYaml (index .Values "jobs" "update-es" "resources") | nindent 12 }}