Helm: Verschachtelte Nullwerte entfernen Schlüssel nicht wie erwartet

@scottrigby , werfen ?

Als Frage / Unterstützung markieren, bis bestätigt wurde, dass dies tatsächlich ein Fehler ist, so der ursprüngliche Autor.

Ich sehe das auch in 2.12.3. Ich sehe, während ich versuche, den Wert über -f und --set auf null zu setzen. In beiden Fällen wird es nur als Zeichenfolge (ohne Anführungszeichen) auf "null" gesetzt, anstatt den Standardwert zu entfernen.
Meine 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
<...>

Der Anwendungsfall besteht darin, diese Werte zurückzusetzen, um die Standardeinstellungen aus der Vorlage anstelle der Standardeinstellungen zu verwenden, die jetzt im Ruder stecken.

Stable / Filebeat

Mit null oder nil sehe ich dasselbe ... der Schlüssel wird nicht entfernt ... er wird als null/nil überschrieben, aber nicht entfernt und wenn Sie ihn ersetzen es mit einem anderen Schlüssel verursacht es Problem:

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

`` `yaml
--- meine Überschreibungen
output.elasticsearch:
Gastgeber:
- ' http: // localhost : 9200'
output.file: null

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

oder

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

Pod-Fehler als:

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

Ich stoße auch genau auf dieses Problem mit dem Filebeat-Diagramm.

@cdenneen Mit config.output.file.enabled=false können Sie die Dateiausgabe speziell umgehen .

Ich habe ein Problem, bei dem ich den neuen Schlüssel inputs für Filebeat verwenden möchte, den Schlüssel prospectors jedoch nicht entfernen kann.

Bestehende Werte:

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

Mein Override: --set config.filebeat.prospectors=null

Ergebnis: (config wird verwendet, um einen geheimen Wert festzulegen)

filebeat:
  prospectors: null

Ich bin auch auf dieses Problem mit stable/kibana und stable/filebeat gestoßen. Die Schlüssel verwenden standardmäßig die Diagrammwerte, selbst wenn !!null angegeben ist.

@aeijdenberg glauben, dass Ihre PR nur die Überprüfung von aktualisierten Labels erfordert

Hey @bacongobbler Entschuldigung, ich habe Ihre Frage in https://github.com/helm/helm/issues/5184#issuecomment -456138448 verpasst. Ich kann überprüfen, ob es sich um einen Fehler handelt. In # 2648 hätte ich wirklich einen Test hinzufügen sollen, der dem dokumentierten Beispiel entspricht. Ich wollte darauf zurückkommen, aber # 5185 sieht vielversprechend aus! 👏 wird dort antworten

Hallo @scottrigby . Darf ich wissen, welche Version das Update von # 5185 enthalten wird? Ich bin gerade auf dieses Problem gestoßen, als ich versucht habe, Ressourcendefinitionen in istio chart zu entfernen.

Dies soll in 2.14.2 sein - aber ich kann es nicht zum Laufen bringen.

Ich folge einem sehr ähnlichen Beispiel wie oben im Problem. Der einzige Unterschied besteht darin, dass ich versuche, einen in einem Unterdiagramm festgelegten Wert zu löschen (in meinem Fall logstash).

Ich habe versucht:

• Setzen von logstash.livenessProbe.httpGet auf null , ~ und {} in der Datei values.yaml des Hauptdiagramms oder in der Befehlszeile. In beiden Fällen zeigt "helm template" an, dass der ursprüngliche Wert noch vorhanden ist (dh ich bekomme immer noch httpGet gesetzt) ​​- und dies stimmt mit dem überein, was ich für "helm install" sehe.
• Setzen von logstash.livenessProbe.httpGet auf "nil" - in diesem Fall wird der Wert zwar überschrieben, aber auf die Zeichenfolge "nil", die hier kein gültiger Wert ist, sodass kubernetes die Vorlage ablehnt.

Habe ich falsch verstanden und das hat es nicht in 2.14.2 geschafft - oder gibt es immer noch ein Problem?

(Diagramm, das dies demonstriert: demo.zip )

Der Patch wurde gemäß den Versionshinweisen in 2.14.2 ausgewählt, sodass er verfügbar sein sollte.

In diesem Fall bin ich mir nicht sicher, ob dieser Fehler behoben ist. Sollte er erneut geöffnet oder ein neues Problem erstellt werden? Kann jemand anderes einen Blick auf die Tabelle werfen, die ich oben angehängt habe, und sehen, ob er anders aussieht?

@ cc-stjm @bacongobbler - Ich kann das Problem reproduzieren, und ich denke, dieser Test zeigt es:

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

Das Problem ist, soweit ich das beurteilen kann, dass CoalesceValues() zu mehr als einem Aufruf der zugrunde liegenden Funktion führt, die die Werte kohlensäurehaltig macht:
https://github.com/helm/helm/blob/e04fa72f6f211cae68c362f9b7c62f06dc51493e/pkg/chartutil/values.go#L164 -L180

Das heißt, Zeile 173 oben wird aufgerufen, wobei httpGet auf null , aber der zurückgegebene Wert hat diesen Schlüssel (wie beabsichtigt) aus der Karte gelöscht. Diese Ausgabe wird dann jedoch ein zweites Mal als Eingabe für den zweiten Satz der Verschmelzung (Zeile 179) übergeben. Da der Schlüssel nicht mehr vorhanden ist, wird standardmäßig der Wert im Diagramm verwendet.

Leider ist es unwahrscheinlich, dass mir in naher Zukunft Zeit zur Verfügung steht, um weiter zu gehen. Ich habe die Rollen gewechselt und verwende derzeit keinen Helm. Die Antwort auf die Lösung ist mir nicht klar. Hoffentlich ist das oben Genannte bei der Lösung hilfreich.

Tatsächlich habe ich gerade 2.14.0 => 2.14.2 aktualisiert. Der Schlüssel null ed ist nicht nur noch vorhanden, sondern enthält auch den vorherigen Wert. Das vorherige Verhalten hat es gerade null gemacht, also glaube ich, dass dies tatsächlich zurückgegangen ist.

@aeijdenberg Kannst du bitte die Anfrage von @sgillespie prüfen ? Wenn es eine Regression gibt, ist es wahrscheinlich sicherer, diese PR zurückzusetzen, es sei denn, Sie können eine Lösung ermitteln. Wenn Sie nicht helfen können, ist es wahrscheinlich sicherer, Ihr Commit zurückzusetzen und zu Feld 1 zurückzukehren. Lassen Sie mich wissen, wie Sie fortfahren möchten.

@bacongobbler , obwohl ich 2.14.0 nicht explizit getestet habe, entspricht @sgillespie dem Verhalten, auf das ich in https://github.com/helm/helm/issues/5184#issuecomment-517059748 verwiesen habe. Leider denke ich, dass die Komponententests bestanden werden, aber das Ende-zu-Ende fehlschlägt - da die einzelnen Komponenten in Serie verwendet werden, hat das Entfernen eines Schlüssels in einem früheren Stadium keine Auswirkungen auf spätere Stadien (und deshalb) die ursprünglichen Werte kommen durch).

Ich bin damit einverstanden, dass es sich um eine Regression handelt, obwohl das Zurücksetzen auch eine Regression für alle ist, die sich auf das neue Verhalten verlassen.

Ich habe einen relativ kleinen Patch ausprobiert, von dem ich denke, dass er die Auswirkungen (und den oben hinzugefügten Test) in # 6146 verringert - es tut mir leid, dass wir dies beim letzten Versuch falsch verstanden haben.

Dies wurde möglicherweise in https://github.com/helm/helm/pull/6080 behoben

Wenn ja, kann # 6146 geschlossen werden oder wird versucht, ein separates Problem zu beheben? Ich versuche, meinen Kopf um den Problembereich zu fassen, aber es ist unklar, was diese PRs zu lösen versuchen. Es tut uns leid.

Dies scheint das Problem tatsächlich zu beheben. Ein kurzer naiver Test:

Subchart-Werte:

prop:
  nested:
    val: true

Übergeordnete Diagrammwerte:

sub:
  prop:
    nested: null

Die erwartete Ausgabe beträgt {}

Hallo,

Ich benutze das Ruder 2.15.0 und habe dieses Problem immer noch festgestellt.

Gegeben ein Unterdiagramm mit Werten:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Wo die Werte mit toYaml

Und in einem übergeordneten Diagramm Werte:

sub:
  securityContext:
  runAsUser: null

Dann ist die tatsächliche Ausgabe:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

Während es hätte sein sollen:

securityContext:
  fsGroup: 65534

Ich versuche nicht, auf deiner Parade zu regnen, aber ich sehe das immer noch mit Helm v3.0.1

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

Wenn ich versuche, Stable / Ignite zu installieren, muss ich einen Wert deaktivieren, aber helm scheint den Wert nur auf null / nil zu setzen, was dazu führt, dass k8s im Validierungsschritt blockiert.

Speichern Sie dies zum Reproduzieren als bug5184-ignite.yaml (um Werte aus den Standardeinstellungen des Diagramms zu überschreiben: 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

Verwenden Sie es dann als Wertedatei für eine Ignite-Installation:

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

Das Ergebnis, das ich erhalte, ist diese Fehlermeldung, die zeigt, dass der Wert, den ich deaktivieren wollte, auf 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
[...]

Was ich auch versucht habe:

• Setzen Sie den Wert auf etwas anderes / überschreiben Sie ihn überhaupt nicht
  
  
  
  • => Der PersistentVolumeClaim steckt in "Ausstehend" fest, da es eine zusätzliche "Typ" -Option gibt, die vom Anbieter nicht unterstützt wird
  
  
  • => Es ist definitiv dieser Wert, der die Probleme verursacht
  
  
• Setzen Sie die Werte über --set auf null --set
  
  
  
  • Gleiches Verhalten wie beim Festlegen in der Datei
  
  

Wenn nur ein einzelner Wert über die Befehlszeile auf null wird, während gleichzeitig die Zündpersistenz deaktiviert bleibt (damit die Speicherklassenvorlage nicht generiert wird und der betreffende Parameter ignoriert wird) ...

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

... es gibt eine korrekte Debug-Ausgabe anstelle eines Fehlers, aber es zeigt, dass der Wert nur auf null (von mir hinzugefügte Kommentare):

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

Ich bin mit 3.0.1 genau dasselbe Problem gestoßen.

Nach dem Wechsel von Helm v2.16.1 zu v3.0.2. Ich hatte dieses Problem mit nicht eingestellten Anmerkungen und CPU-Grenzwerten.

Ich stoße nur auf dieses Problem in 2.14.1 und 3.0.2 . Gibt es hierzu Neuigkeiten?

In Fällen, in denen ich weiß, dass das Helmdiagramm einfach verwendet wird und true / false, wenn test, überschreibe ich den Wert mit einem Nicht-Tabellenwert wie 0. Ich erhalte viele Warnungen wie Overwriting table item 'x', with non table value: 0 , aber ich bekomme zumindest Eine Problemumgehung in Fällen, in denen keine Zeilengruppe enthalten sein soll. Ich würde es vorziehen, wenn null funktioniert, aber dies ist eine hässliche Problemumgehung.

Ich habe Werte auf null gesetzt (und sie in meinen Wertedateien auf null belassen) und die lange Liste von Tabellenwarnungen ignoriert, die vorerst in Ordnung ist, aber ich möchte wirklich nur eine einmalige Bereinigung der alten falschen Werte durchführen, die in gespeichert sind kubernetes. Gibt es eine manuelle Möglichkeit, die Werte in einer vorhandenen Bereitstellung ohne Ausfallzeiten zu bearbeiten, bis dieser Fehler beim Löschen von Werten behoben ist?

Das gleiche Problem tritt mit den Sonden liveness und readiness .
Das Löschen des Standardschlüssels aus dem Vorlagenhandbuch funktioniert nicht.

Bitte versuchen Sie es mit # 7743. Es sieht so aus, als ob die für Helm 2 vorgenommenen Commits nicht auf Helm 3 portiert wurden, weshalb viele Benutzer dieses Verhalten dort sehen würden.

Dieses Problem mit Helm 2.16.3 wird immer noch angezeigt, jedoch nur, wenn eine Anforderung vorhanden ist. Yaml

boo ist das Unterdiagramm und foo ist das übergeordnete Diagramm:

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

Beide Diagramme hier:

helm_5184.zip

@bacongobbler Gibt es eine Absicht, dies in 2.x weiter

Wir haben auch dieses Problem (ähnlich dem von @vbuciuc beschriebenen) festgestellt, bei dem "Null" für das Überschreiben von Werten nicht funktioniert, wenn das Unterdiagramm als Abhängigkeit in "require.yaml" mit 3.2.x aufgeführt ist. Frühere Versionen (3.1.x) funktionieren wie erwartet.

@bacongobbler @technosophos Ich 3.3.4 Können Sie es bitte erneut öffnen

Ich kann bestätigen, dass es in 3.1.2 funktioniert hat und nach 3.2.x funktioniert , wie Derzeit scheint es, dass die false das beabsichtigte Verhalten hervorruft, in diesem Fall jedoch Ausgabewarnungen ausgibt.

@ Chili-Man, ich habe es gerade mit 3.1.3 versucht und es scheint nicht zu funktionieren. Es wird mit null aber ich bekomme eine Warnung und es macht nichts. Bei allem anderen ( false , 0 , [] ) lehnt es ab mit (z. B.)

`` `coalesce.go: 196: Warnung: Tabelle kann nicht mit Nicht-Tabelle für Ressourcen überschrieben werden (map [Anfragen: map [CPU: 250m Speicher: 256Mi]])
Fehler: UPGRADE FAILED: Werte entsprechen nicht den Spezifikationen der Schemas in den folgenden Diagrammen:
postgresql:

• Ressourcen: Ungültiger Typ. Erwartet: Objekt, gegeben: Boolescher Wert
  `` (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` und ebenso weigert sich alles andere, sich zu bewerben. Am nervigsten ...

Ich habe immer noch dieses Problem in 3.4.2.

Das Problem ist in 3.4.2 immer noch vorhanden, jedoch nur in bestimmten Situationen.
Ich habe ein Diagramm mit mehreren Unterdiagrammen.
Wenn Sie Standardwerte in Unterdiagrammwerte einfügen, funktioniert null override nicht. Wenn Sie dieselben Werte in übergeordnete Diagrammwerte verschieben, funktioniert dies wie erwartet.
Dies ist nur mit Unterdiagrammen reproduzierbar. Wenn Sie es in ein einzelnes (flaches) Diagramm einfügen, funktioniert alles einwandfrei.

Ich habe das gleiche Problem mit 3.4.2 bei der Verwendung von Unterdiagrammen (wie oben von
In meinem Fall möchte ich den securityContext überschreiben, wenn ich das ElasticSearch- Helmdiagramm in einem OpenShift-Cluster verwende.
Wird dieses Problem erneut geöffnet oder sollten wir ein neues erstellen?

Erhöht # 9136