Helm: Les valeurs `null` imbriquées ne suppriment pas les clés comme prévu

Créé le 18 janv. 2019  ·  36Commentaires  ·  Source: helm/helm

https://github.com/helm/helm/pull/2648 permet de supprimer des clés en définissant des valeurs null dans un fichier values.yaml . Cependant, cela ne fonctionne pas pour les valeurs imbriquées, par exemple:

web:
  livenessProbe:
    httpGet: null
    exec:
      command:
      - curl
      - -f
      - http://localhost:8080/api/v1/info

Ne supprimera pas web.livenessProbe.httpGet des valeurs d'origine, mais remplace simplement la valeur par null et affiche l'avertissement:

2019/01/18 11:30:07 Warning: Merging destination map for chart 'concourse'. Cannot overwrite table item 'httpGet', with non table value: map[path:/api/v1/info port:atc]

Ironiquement, ci-dessus est une petite variante de l'exemple donné dans la documentation, qui, j'en suis sûr, ne fait pas vraiment ce qu'il prétend: https://docs.helm.sh/chart_template_guide/#deleting-a-default-key

Je soupçonne que, puisque le rendu du modèle ne semble pas faire la différence entre une valeur nulle et une valeur non spécifiée, ces avertissements sont ignorés et n'ont pas beaucoup d'effet.

Sortie de helm version :

Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}

Sortie de kubectl version :

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.5-eks-6bad6d", GitCommit:"6bad6d9c768dc0864dab48a11653aa53b5a47043", GitTreeState:"clean", BuildDate:"2018-12-06T23:13:14Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

Fournisseur / plate-forme de cloud (AKS, GKE, Minikube, etc.):

EKS

bug

Commentaire le plus utile

Nous avons également rencontré ce problème (similaire à celui décrit par @vbuciuc) avec le non fonctionnement de "null" pour le remplacement des valeurs lorsque le sous-diagramme est répertorié comme une dépendance dans requirements.yaml avec 3.2.x. Les versions précédentes (3.1.x) fonctionnent comme prévu.

Tous les 36 commentaires

@scottrigby , voulez-vous par hasard jeter un coup d'œil à celui-ci?

Marquage comme question / support jusqu'à ce qu'il soit confirmé qu'il s'agit bien d'un bogue selon l'auteur original.

Je vois cela aussi sur 2.12.3. Je vois en essayant de définir la valeur sur null via -f et --set. Dans tous les cas, il le définit simplement sur "null" sous forme de chaîne (sans les guillemets) plutôt que de supprimer la valeur par défaut.
Ma situation:

> 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
<...>

Le cas d'utilisation consiste à réinitialiser ces valeurs pour utiliser les valeurs par défaut du modèle au lieu des valeurs par défaut maintenant bloquées dans la barre.

stable / filebeat

Avec null ou nil je vois la même chose ... la clé n'est pas supprimée ... elle est remplacée par null/nil mais pas supprimée et lorsque vous remplacez avec une clé différente, cela pose problème:

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

`` yaml
--- mes remplacements
output.elasticsearch:
hôtes:
- « 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

erreurs de pod comme:

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

Je rencontre également ce problème exact avec le graphique filebeat.

@cdenneen Vous pouvez contourner la sortie de fichier spécifiquement avec config.output.file.enabled=false .

Je rencontre un problème où je souhaite utiliser la nouvelle clé inputs pour filebeat mais je ne peux pas supprimer la clé prospectors .

Valeurs existantes:

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

Mon remplacement: --set config.filebeat.prospectors=null

Résultat: (config est utilisé pour définir une valeur secrète)

filebeat:
  prospectors: null

J'ai également rencontré ce problème avec stable/kibana et stable/filebeat les clés prendront par défaut les valeurs du graphique même lorsque !!null est spécifié.

@aeijdenberg pense que votre RP nécessite simplement la mise à jour des étiquettes pour être examinées

Hey @bacongobbler désolé, j'ai manqué votre question sur https://github.com/helm/helm/issues/5184#issuecomment -456138448. Je peux vérifier qu'il s'agit d'un bogue. Dans # 2648, j'aurais vraiment dû ajouter un test correspondant à l'exemple documenté. J'avais l'intention d'y revenir, mais # 5185 semble prometteur! 👏 répondra là-bas

Salut @scottrigby . Puis-je savoir quelle version comprendra le correctif de # 5185? Je viens de rencontrer ce problème en essayant de supprimer les définitions de ressources sur le graphique istio.

Ceci est censé être dans 2.14.2 - mais je ne peux pas le faire fonctionner.

Je suis un exemple très similaire à celui en haut du problème - la seule différence que je peux voir est que j'essaie de supprimer un ensemble de valeurs dans un sous-graphique (dans mon cas, logstash).

J'ai essayé:

  • en définissant logstash.livenessProbe.httpGet à null , ~ et {} dans values.yaml du graphique principal, ou sur la ligne de commande. Dans les deux cas, «modèle de barre» montre que la valeur d'origine est toujours là (c'est-à-dire que je suis toujours en train de configurer httpGet) - et c'est cohérent avec ce que je vois pour «l'installation de la barre»
  • paramétrer logstash.livenessProbe.httpGet à "nil" - dans ce cas, la valeur est écrasée, mais à la chaîne "nil" qui n'est pas une valeur valide à utiliser ici, donc kubernetes rejette le modèle.

Ai-je mal compris et cela ne s'est pas transformé en 2.14.2 - ou y a-t-il toujours un problème?

(Graphique illustrant ceci:

Le correctif a été sélectionné dans la version 2.14.2 selon les notes de publication, il devrait donc être disponible.

Dans ce cas, je ne suis pas sûr que ce bogue soit corrigé - doit-il être rouvert ou créer un nouveau problème? Est-ce que quelqu'un d'autre peut jeter un œil au tableau que j'ai joint à ce qui précède et voir s'il voit différent?

@ cc-stjm @bacongobbler - Je suis capable de reproduire le problème et je pense que ce test le démontre:

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)
    }
}

Le problème, pour autant que je sache, est que CoalesceValues() entraîne plus d'un appel à la fonction sous-jacente qui utilise les valeurs:
https://github.com/helm/helm/blob/e04fa72f6f211cae68c362f9b7c62f06dc51493e/pkg/chartutil/values.go#L164 -L180

c'est-à-dire que la ligne 173 ci-dessus est appelée avec le httpGet mis à null , mais la valeur qu'elle renvoie a supprimé cette clé de la carte (comme prévu). Mais ensuite, cette sortie est transmise une deuxième fois en tant qu'entrée au deuxième ensemble de coalescence (ligne 179), puis, comme la clé n'existe plus, elle prend par défaut la valeur du graphique.

Malheureusement, il est peu probable que je dispose de temps disponible dans un proche avenir pour aller plus loin - j'ai changé de rôle et je n'utilise pas actuellement Helm, et la réponse sur la façon de résoudre n'est pas évidente pour moi. Espérons que ce qui précède est utile pour résoudre.

En fait, je viens de mettre à jour 2.14.0 => 2.14.2. Non seulement la clé null ed existe toujours, mais elle contient également la valeur précédente. Le comportement précédent l'a rendu nul, donc je pense que cela a en fait régressé.

@aeijdenberg pouvez-vous consulter la demande de

@bacongobbler , bien que je n'ai pas testé explicitement 2.14.0, ce que @sgillespie correspond au comportement auquel j'ai fait référence dans https://github.com/helm/helm/issues/5184#issuecomment-517059748 . Malheureusement, je pense que c'est un cas de réussite des tests unitaires, mais l'échec de bout en bout - comme les composants individuels sont utilisés en série, ce qui fait que la suppression d'une clé à un stade antérieur ne produit aucun effet dans les étapes ultérieures (et c'est pourquoi les valeurs d'origine arrivent).

Je suis d'accord que c'est une régression, bien que l'annuler soit aussi une régression pour quiconque se fie au nouveau comportement.

J'ai essayé rapidement un correctif relativement mineur qui, je pense, réduira l'impact (et corrige le test que j'ai ajouté ci-dessus) dans # 6146 - Je suis désolé que nous nous soyons trompés lors de la dernière tentative.

Cela a peut-être été corrigé dans https://github.com/helm/helm/pull/6080. Ce PR corrige le cas où coalesceDeps est appelé deux fois. Quelqu'un peut-il confirmer avec le maître?

Si tel est le cas, le # 6146 peut-il être fermé ou tente-t-il de résoudre un problème distinct? J'essaie de saisir ma tête autour de l'espace des problèmes ici, mais on ne sait pas ce que ces PR tentent de résoudre. Pardon.

Cela semble en effet résoudre le problème. Un test naïf rapide:

Valeurs du sous-diagramme:

prop:
  nested:
    val: true

Valeurs du graphique parent:

sub:
  prop:
    nested: null

La sortie comme prévu est {}

Salut,

J'utilise helm 2.15.0 et j'ai toujours rencontré ce problème.

Étant donné un sous-diagramme avec des valeurs:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Où les valeurs sont utilisées avec toYaml

Et dans les valeurs d'un graphique parent:

sub:
  securityContext:
  runAsUser: null

Ensuite, la sortie réelle est:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Alors que cela aurait dû être:

securityContext:
  fsGroup: 65534

Ne pas essayer de pleuvoir sur votre défilé, mais je vois toujours cela avec la barre v3.0.1

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

Lorsque j'essaie d'installer stable / ignite, je dois annuler une valeur, mais helm semble simplement définir la valeur sur null / nil, ce qui fait hésiter k8 à l'étape de validation.

Pour reproduire, enregistrez-le sous bug5184-ignite.yaml (pour remplacer les valeurs par défaut du graphique: 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

Ensuite, utilisez-le comme fichier de valeurs pour une installation ignite:

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

Le résultat que j'obtiens est ce message d'erreur, montrant que la valeur que je voulais annuler a été définie sur 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
[...]

Ce que j'ai également essayé:

  • Définir la valeur sur quelque chose de différent / ne pas la remplacer du tout

    • => Le PersistentVolumeClaim est bloqué dans "Pending" car il y a une option "type" supplémentaire qui n'est pas prise en charge par le fournisseur

    • => c'est définitivement cette valeur qui pose les problèmes

  • Définition de la ou des valeurs sur null via --set

    • Même comportement que lors de sa mise en place dans le fichier

Lors de la définition d'une seule valeur à null via la ligne de commande, tout en gardant la persistance ignite désactivée (afin que le modèle de classe de stockage ne soit pas généré et que le paramètre en question soit ignoré) ...

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

... il y a une sortie de débogage appropriée au lieu d'une erreur, mais cela montre que la valeur est juste définie sur null (commentaires ajoutés par moi):

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: []

J'ai rencontré exactement le même problème en utilisant 3.0.1 , il serait peut-être bon de rouvrir ce problème?

Après être passé de la barre v2.16.1 à la v3.0.2. J'ai eu ce problème avec l'annulation des annoations et les limites du processeur.

Je viens de rencontrer ce problème dans 2.14.1 et 3.0.2 . Une mise à jour pour ceci?

Dans les cas où je sais que le graphique de barre utilise simplement et vrai / faux si test, je remplace la valeur par une valeur non-table comme 0. Je reçois beaucoup d'avertissements comme Overwriting table item 'x', with non table value: 0 , mais j'obtiens au moins une solution de contournement dans les cas où je ne veux pas d'inclure une strophe. Ma préférence serait que null fonctionne, mais c'est une solution de contournement laide.

J'ai défini les valeurs sur null (et les ai laissées nulles dans mes fichiers de valeurs) et ignorer la longue liste d'avertissements de table, ce qui est OK pour le moment, mais j'aimerais vraiment faire un nettoyage unique des anciennes valeurs incorrectes stockées dans kubernetes. Jusqu'à ce que ce bogue de suppression de valeur soit corrigé, existe-t-il un moyen manuel de modifier les valeurs sur un déploiement existant sans temps d'arrêt?

Vous rencontrez le même problème avec les sondes liveness et readiness .
La suppression de la clé par défaut du guide des modèles ne fonctionne pas.

Veuillez essayer # 7743. Il semble que les commits effectués sur Helm 2 n'aient pas été portés sur Helm 3, c'est pourquoi de nombreux utilisateurs verraient ce comportement là-bas.

Toujours voir ce problème avec helm 2.16.3 mais seulement quand il y a un requirements.yaml listant le sous-diagramme comme dépendance.

boo est le sous-diagramme et foo est le diagramme parent:

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

Les deux graphiques ici:

helm_5184.zip

@bacongobbler a -t-il l'intention de traiter davantage ce problème dans 2.x?

Nous avons également rencontré ce problème (similaire à celui décrit par @vbuciuc) avec le non fonctionnement de "null" pour le remplacement des valeurs lorsque le sous-diagramme est répertorié comme une dépendance dans requirements.yaml avec 3.2.x. Les versions précédentes (3.1.x) fonctionnent comme prévu.

@bacongobbler @technosophos Je rencontre également ce problème avec Helm 3.3.4 , pouvez-vous rouvrir s'il vous plaît;

Je peux confirmer que cela a fonctionné dans 3.1.2 et qu'il a cessé de fonctionner après 3.2.x comme le mentionne @paleg . Pour l'instant, il semble que la solution de contournement de @ tuzla0autopilot4 consistant à le définir sur une valeur non false produira le comportement prévu mais donnera des avertissements de sortie lorsque cela sera fait.

@ Chili-Man, je viens d'essayer avec 3.1.3 et cela ne semble pas fonctionner. Cela s'appliquera avec null mais je reçois un avertissement et cela ne fait rien. Avec n'importe quoi d'autre ( false , 0 , [] ) il refuse avec (par exemple,)

`` `` coalesce.go: 196: avertissement: impossible d'écraser la table avec une table non pour les ressources (map [requests: map [cpu: 250m memory: 256Mi]])
Erreur: ECHEC DE LA MISE À NIVEAU: les valeurs ne répondent pas aux spécifications du ou des schémas dans le (s) graphique (s) suivant (s):
postgresql:

  • resources: type non valide. Attendu: objet, donné: booléen
    `` (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` et de même tout le reste refuse de s'appliquer. Le plus ennuyeux...

Je rencontre toujours ce problème dans 3.4.2.

Le problème est toujours présent dans 3.4.2, mais seulement dans certaines situations.
J'ai un graphique avec plusieurs sous-graphiques.
Lors de la mise par défaut dans les valeurs null sous-graphique
Ceci n'est reproductible qu'avec des sous-graphiques. Lorsque vous le mettez dans un seul graphique (plat), tout fonctionne correctement.

Je rencontre le même problème avec 3.4.2 lors de l'utilisation de sous-graphiques (comme décrit par @BohdanKalytka ci-dessus).
Dans mon cas, je souhaite remplacer le securityContext lors de l'utilisation du graphique de barre ElasticSearch dans un cluster OpenShift.
Ce numéro va-t-il être rouvert ou devrions-nous en créer un nouveau?

Levé # 9136

Cette page vous a été utile?
0 / 5 - 0 notes