Helm: Valores `nulos` aninhados não removem as chaves conforme o esperado

@scottrigby , por acaso você quer dar uma olhada neste?

Marcando como questão / suporte até que seja confirmado que este é realmente um bug de acordo com o autor original.

Também estou vendo isso no 2.12.3. Estou vendo enquanto tento definir o valor como nulo por meio de -f e --set. De qualquer forma, ele apenas define como "nulo" como uma string (sem as aspas) em vez de remover o valor padrão.
Minha situação:

> helm get values grafana
admin:
  existingSecret: ""
chownDataImage:
  pullPolicy: null
  repository: null
  tag: null
<...>

> helm upgrade grafana stable/grafana --tls --reuse-values --set chownDataImage.pullPolicy=null
<output indicating it works>

> helm get values grafana
admin:
  existingSecret: ""
chownDataImage:
  pullPolicy: null
  repository: null
  tag: null
<...>

O caso de uso é redefinir esses valores para usar os padrões do modelo em vez dos padrões agora presos no helm.

estável / filebeat

Com null ou nil estou vendo a mesma coisa ... a chave não foi removida ... é substituída como null/nil mas não removida e quando você está substituindo com chave diferente causa problema:

---values.yml in the Chart
output.file:
  path: /var/log/foo.log

`` `yaml
--- minhas substituições
output.elasticsearch:
hosts:
- ' http: // localhost : 9200'
output.file: null

or
```yaml
---my overrides
output:
  elasticsearch:
     host:
      - 'http://localhost:9200'
  file: null

ou

---my overrides
output:
  elasticsearch:
     hosts:
      - 'http://localhost:9200'
output.file: null

» k get secret filebeat -o jsonpath="{.data.filebeat\.yml}" | base64 -D
    filebeat.config:
      modules:
        path: ${path.config}/modules.d/*.yml
        reload.enabled: false
      prospectors:
        path: ${path.config}/prospectors.d/*.yml
        reload.enabled: false
    filebeat.prospectors:
    - enabled: true
      fields:
        apenv: dev
        app: kubernetes
        log_category: kubernetes
      fields_under_root: true
      paths:
      - /var/log/*.log
      - /var/log/messages
      - /var/log/syslog
      type: log
    - containers.ids:
      - '*'
      fields:
        apenv: dev
        app: kubernetes
        log_category: kubernetes
      fields_under_root: true
      processors:
      - add_kubernetes_metadata:
          in_cluster: true
      - drop_event:
          when:
            equals:
              kubernetes.container.name: filebeat
      type: docker
    http.enabled: true
    http.port: 5066
    output:
      elasticsearch:
        hosts:
        - http://localhost9200
    output.file: null
    processors:
    - add_cloud_metadata: null

erros de pod como:

Exiting: error unpacking config data: more than one namespace configured accessing 'output' (source:'filebeat.yml')

Também estou encontrando esse mesmo problema com o gráfico de filebeat.

@cdenneen Você pode contornar a saída de arquivo especificamente com config.output.file.enabled=false .

Estou encontrando um problema em que desejo usar a nova chave inputs para filebeat, mas não consigo remover a chave prospectors .

Valores existentes:

config:
  filebeat.prospectors:
    - type: log
      enabled: true
      paths:
        - /var/log/*.log
        - /var/log/messages
        - /var/log/syslog

Minha substituição: --set config.filebeat.prospectors=null

Resultado: (config é usado para definir um valor secreto)

filebeat:
  prospectors: null

Eu também encontrei este problema com stable/kibana e stable/filebeat as chaves serão padronizadas para os valores do gráfico mesmo quando !!null for especificado.

@aeijdenberg acredita que seu PR apenas exige que as etiquetas atualizadas sejam revisadas

Ei @bacongobbler, desculpe, perdi sua pergunta em https://github.com/helm/helm/issues/5184#issuecomment -456138448. Posso verificar se é um bug. Em # 2648, eu realmente deveria ter adicionado um teste que correspondesse ao exemplo documentado. Eu pretendia voltar a isso, mas # 5185 parece promissor! 👏 vai responder ali

Olá @scottrigby . Posso saber qual versão incluirá a correção do # 5185? Acabei de encontrar esse problema ao tentar remover as definições de recursos no gráfico istio.

Isso deveria estar na versão 2.14.2 - mas não consigo fazer funcionar.

Estou seguindo um exemplo muito semelhante ao que está no topo da questão - a única diferença que posso ver é que estou tentando excluir um valor definido em um subchart (no meu caso, logstash).

Eu tentei:

• definindo logstash.livenessProbe.httpGet to null , ~ e {} em values.yaml do gráfico principal ou na linha de comando. Em ambos os casos, "modelo do helm" mostra que o valor original ainda está lá (ou seja, ainda estou obtendo o conjunto httpGet) - e isso é consistente com o que vejo para "instalação do helm"
• configurando logstash.livenessProbe.httpGet para "nil" - neste caso, o valor é sobrescrito, mas para a string "nil", que não é um valor válido para usar aqui, então o kubernetes rejeita o modelo.

Eu entendi mal e isso não foi incluído no 2.14.2 - ou ainda há um problema?

(Gráfico demonstrando isso: demo.zip )

O patch foi escolhido a dedo no 2.14.2 de acordo com as notas de lançamento, então ele deve estar disponível.

Nesse caso, não tenho certeza se esse bug foi corrigido - ele deve ser reaberto ou um novo problema criado? Alguém pode dar uma olhada no gráfico que anexei acima e ver se eles vêem diferente?

@ cc-stjm @bacongobbler - Consigo reproduzir o problema e acho que este teste o demonstra:

func TestSubchartCoaleseWithNullValue(t *testing.T) {
    v, err := CoalesceValues(&chart.Chart{
        Metadata: &chart.Metadata{Name: "demo"},
        Dependencies: []*chart.Chart{
            {
                Metadata: &chart.Metadata{Name: "logstash"},
                Values: &chart.Config{
                    Raw: `livenessProbe: {httpGet: {path: "/", port: monitor}}`,
                },
            },
        },
        Values: &chart.Config{
            Raw: `logstash: {livenessProbe: {httpGet: null, exec: "/bin/true"}}`,
        },
    }, &chart.Config{})
    if err != nil {
        t.Errorf("Failed with %s", err)
    }
    result := v.AsMap()
    expected := map[string]interface{}{
        "logstash": map[string]interface{}{
            "global": map[string]interface{}{},
            "livenessProbe": map[string]interface{}{
                "exec": "/bin/true",
            },
        },
    }
    if !reflect.DeepEqual(result, expected) {
        t.Errorf("got %+v, expected %+v", result, expected)
    }
}

O problema, pelo que eu posso dizer, é que CoalesceValues() resulta em mais de uma chamada para a função subjacente que une os valores:
https://github.com/helm/helm/blob/e04fa72f6f211cae68c362f9b7c62f06dc51493e/pkg/chartutil/values.go#L164 -L180

ou seja, a linha 173 acima é chamada com httpGet definido como null , mas o valor que ela retorna excluiu essa chave do mapa (como pretendido). Mas então essa saída é passada uma segunda vez como entrada para o segundo conjunto de coalescência (linha 179) e, como a chave não existe mais, o padrão é o valor no gráfico.

Infelizmente, é improvável que terei tempo disponível no futuro próximo para ir mais longe - mudei de função e não estou usando o Helm no momento, e a resposta sobre como resolver não é óbvia para mim. Esperançosamente, o acima exposto é útil para resolver.

Na verdade, acabei de atualizar 2.14.0 => 2.14.2. Não apenas a chave null ed ainda existe, mas também contém o valor anterior. O comportamento anterior apenas o tornou nulo, então acredito que isso realmente regrediu.

@aeijdenberg, você pode dar uma olhada na pergunta de @sgillespie ? Se houver uma regressão, então provavelmente é mais seguro voltar atrás, a menos que você possa determinar uma correção. Se você não puder ajudar, então provavelmente é mais seguro reverter seu commit e voltar à estaca zero. Deixe-me saber como você gostaria de proceder.

@bacongobbler , embora eu não tenha testado explicitamente o 2.14.0 , mencionei em https://github.com/helm/helm/issues/5184#issuecomment-517059748 . Infelizmente, acho que é um caso de aprovação dos testes de unidade, mas falha de ponta a ponta - como os componentes individuais estão sendo usados ​​em série, o que faz com que a remoção de uma chave em um estágio anterior não tenha efeito nos estágios posteriores (e é por isso que os valores originais estão chegando).

Concordo que é uma regressão, embora retroceder também seja uma regressão para qualquer um que confie no novo comportamento.

Eu fiz uma rápida tentativa em um patch relativamente pequeno que eu acho que vai reduzir o impacto (e corrige o teste que adicionei acima) em # 6146 - Lamento que erramos na última tentativa.

Isso pode ter sido corrigido em https://github.com/helm/helm/pull/6080. Esse PR corrige o caso em que coalesceDeps é chamado duas vezes. Alguém pode confirmar com o mestre?

Em caso afirmativo, o # 6146 pode ser fechado ou está tentando corrigir um problema separado? Estou tentando entender o espaço do problema aqui, mas não está claro o que esses PRs estão tentando resolver. Desculpa.

Isso realmente parece resolver o problema. Um teste rápido e ingênuo:

Valores do subchart:

prop:
  nested:
    val: true

Valores do gráfico pai:

sub:
  prop:
    nested: null

O resultado esperado é {}

Oi,

Estou usando o leme 2.15.0 e ainda encontrei esse problema.

Dado um subchart com valores:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Onde os valores são usados ​​com toYaml

E em valores de um gráfico pai:

sub:
  securityContext:
  runAsUser: null

Então, a saída real é:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Embora deveria ter sido:

securityContext:
  fsGroup: 65534

Não estou tentando chover no seu desfile, mas ainda estou vendo isso com o helm v3.0.1

version.BuildInfo {Versão: "v3.0.1", GitCommit: "7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState: "clean", GoVersion: "go1.13.4"}

Ao tentar instalar o stable / ignite, tenho que remover um valor, mas o helm parece apenas definir o valor como nulo / nulo, fazendo com que o k8s pare na etapa de validação.

Para reproduzir, salve como bug5184-ignite.yaml (para substituir os valores dos padrões do gráfico: https://github.com/helm/charts/blob/master/stable/ignite/values.yaml):

persistence:
  enabled: true   # <-- without this, the keys in question are ignored
  persistenceVolume:
    provisionerParameters:
      type: null  # <-- I want to unset this key
  walVolume:
    provisionerParameters:
      type: null  # <-- I want to unset this key

Em seguida, use-o como arquivo de valores para uma instalação ignite:

helm install runtimedb stable/ignite --version 1.0.1 --values bug5184-ignite.yaml --debug --dry-run | less

O resultado que estou obtendo é esta mensagem de erro, mostrando que o valor que eu queria cancelar foi definido como nil :

install.go:148: [debug] Original chart version: ""
install.go:165: [debug] CHART PATH: /home/creinig/.cache/helm/repository/ignite-1.0.1.tgz

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: unknown object type "nil" in StorageClass.parameters.type
helm.go:76: [debug] error validating "": error validating data: unknown object type "nil" in StorageClass.parameters.type
helm.sh/helm/v3/pkg/kube.scrubValidationError
        /home/circleci/helm.sh/helm/pkg/kube/client.go:520
helm.sh/helm/v3/pkg/kube.(*Client).Build
        /home/circleci/helm.sh/helm/pkg/kube/client.go:135
helm.sh/helm/v3/pkg/action.(*Install).Run
        /home/circleci/helm.sh/helm/pkg/action/install.go:229
[...]

O que eu também tentei:

• Definir o valor para algo diferente / não substituí-lo de forma alguma
  
  
  
  • => O PersistentVolumeClaim está preso em "Pendente" porque há uma opção "tipo" extra que não é suportada pelo provedor
  
  
  • => é definitivamente esse valor que está causando os problemas
  
  
• Definindo o (s) valor (es) para null por meio de --set
  
  
  
  • Mesmo comportamento ao configurá-lo no arquivo
  
  

Ao definir apenas um único valor para null por meio da linha de comando, ao mesmo tempo mantendo a persistência de ignição desabilitada (para que o modelo storageclass não seja gerado e o parâmetro em questão seja ignorado) ...

helm install myignite stable/ignite --version 1.0.1 --set persistence.persistenceVolume.provisionerParameters.type=null --debug --dry-run | less

... há uma saída de depuração adequada em vez de um erro, mas mostra que o valor está apenas definido como null (comentários adicionados por mim):

NAME: myignite
LAST DEPLOYED: Tue Dec 10 09:43:40 2019
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:
persistence:
  persistenceVolume:
    provisionerParameters:
      type: null   # <-- Set via the command line

COMPUTED VALUES:
affinity: {}
dataStorage:
  config: ""
env:
  IGNITE_QUIET: "false"
  JVM_OPTS: -Djava.net.preferIPv4Stack=true
  OPTION_LIBS: ignite-kubernetes,ignite-rest-http
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: apacheignite/ignite
  tag: 2.7.6
nameOverride: ""
nodeSelector: {}
peerClassLoadingEnabled: false
persistence:
  enabled: false
  persistenceVolume:
    provisioner: kubernetes.io/aws-ebs
    provisionerParameters:
      fsType: ext4
      type: null  # <-- Set to null instead of removed
    size: 8Gi
  walVolume:
    provisioner: kubernetes.io/aws-ebs
    provisionerParameters:
      fsType: ext4
      type: gp2  # <-- This is what the default looks like
    size: 8Gi
rbac:
  create: true
replicaCount: 2
resources: {}
serviceAccount:
  create: true
  name: null
tolerations: []

Encontrei exatamente o mesmo problema ao usar 3.0.1 . Seria bom reabrir esse problema?

Depois de passar do leme v2.16.1 para v3.0.2. Eu tive esse problema com a desconfiguração das annoations e os limites da CPU.

Acabei de encontrar esse problema em 2.14.1 e 3.0.2 . alguma atualização disso?

Nos casos em que sei que o gráfico do leme está simplesmente usando e verdadeiro / falso se teste, substituo o valor por um valor fora da tabela como 0. Recebo muitos avisos como Overwriting table item 'x', with non table value: 0 , mas pelo menos consigo uma solução alternativa nos casos em que não quero que uma estrofe seja incluída. Minha preferência seria que null funcionasse, mas esta é uma solução alternativa feia.

Eu defini valores como nulos (e os deixei nulos em meus arquivos de valores) e ignoro a longa lista de avisos de tabela que está OK por agora, mas eu realmente gostaria de fazer uma limpeza única dos antigos valores incorretos armazenados em kubernetes. Até que esse bug de exclusão de valor seja corrigido, há uma maneira manual de editar os valores em uma implantação existente sem tempo de inatividade?

Encontrando o mesmo problema com as sondas liveness e readiness .
Excluir a chave padrão do guia de modelo não funciona.

Experimente # 7743. Parece que os commits feitos para o Helm 2 não foram transferidos para o Helm 3, e é por isso que muitos usuários veriam esse comportamento lá.

Ainda estou vendo esse problema com o helm 2.16.3, mas apenas quando há um requirements.yaml listando o subchart como dependência.

boo é o subchart e foo é o gráfico pai:

vibu@item-ax35755:~/work$ cat boo/values.yaml 
object:
  fromSubchart:
    hello: from boo
vibu@item-ax35755:~/work$ cat foo/values.yaml 
boo:
  object:
    fromParent:
      hello: from foo
    fromSubchart: null
vibu@item-ax35755:~/work$ cat boo/templates/test.yaml 
{{ toYaml .Values.object }}
vibu@item-ax35755:~/work$ cat foo/requirements.yaml 
dependencies:
- name: boo
  repository: file://../boo
  version: 0.1.0

vibu@item-ax35755:~/work/foo$ helm version -c
Client: &version.Version{SemVer:"v2.16.3", GitCommit:"1ee0254c86d4ed6887327dabed7aa7da29d7eb0d", GitTreeState:"clean"}
vibu@item-ax35755:~/work/foo$ helm dep up
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "incubator" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.
Saving 1 charts
Deleting outdated charts

vibu@item-ax35755:~/work/foo$ helm template .
---
# Source: foo/charts/boo/templates/test.yaml
fromParent:
  hello: from foo
fromSubchart:
  hello: from boo


vibu@item-ax35755:~/work/foo$ mv requirements.yaml{,.bak}
vibu@item-ax35755:~/work/foo$ helm template .
---
# Source: foo/charts/boo/templates/test.yaml
fromParent:
  hello: from foo

Ambos os gráficos aqui:

helm_5184.zip

@bacongobbler existe alguma intenção de abordar ainda mais isso no 2.x?

Também encontramos esse problema (semelhante ao descrito por @vbuciuc) em não funcionar "nulo" para a substituição de valores quando o subchart é listado como uma dependência em requirements.yaml com 3.2.x. As versões anteriores (3.1.x) funcionam conforme o esperado.

@bacongobbler @technosophos Também estou tendo esse problema com Helm 3.3.4 , você pode reabrir;

Posso confirmar que funcionou em 3.1.2 e parou de funcionar depois de 3.2.x como @paleg menciona. Por enquanto, parece que a solução alternativa de @ tuzla0autopilot4 de configurá-lo para um valor não-map como false produzirá o comportamento pretendido, mas dará avisos de saída quando isso for feito.

@ Chili-Man, acabei de tentar com 3.1.3 e não parece funcionar. Ele será aplicado com null mas recebo um aviso e ele não faz nada. Com qualquer outra coisa ( false , 0 , [] ) recusa com (por exemplo,)

`` `coalesce.go: 196: aviso: não é possível sobrescrever tabela com não tabela para recursos (map [requisições: map [cpu: 250m memory: 256Mi]])
Erro: FALHA NO UPGRADE: os valores não atendem às especificações do (s) esquema (s) do (s) gráfico (s) a seguir:
postgresql:

• recursos: tipo inválido. Esperado: objeto, fornecido: booleano
  `` (or what the type that I try that is not a dict/hash). With 3.3.4 I get just silence and it does nothing with null` e da mesma forma todo o resto se recusa a se aplicar. Muito chato ...

Ainda estou tendo esse problema no 3.4.2.

O problema ainda está presente em 3.4.2, mas apenas em determinadas situações.
Eu tenho um gráfico com vários subgráficos.
Ao colocar o padrão nos valores do subgráfico, null override não funciona. Se você mover os mesmos valores para os valores do gráfico pai, ele funcionará conforme o esperado.
Isso é reproduzível apenas com subgráficos. Quando você o coloca em um único gráfico (plano), tudo funciona bem.

Estou tendo o mesmo problema com 3.4.2 ao usar subcharts (conforme descrito por @BohdanKalytka acima).
No meu caso, quero sobrescrever o securityContext ao usar o gráfico do helm ElasticSearch em um cluster OpenShift.
Este problema será reaberto ou devemos criar um novo?

Raised # 9136