Helm: القيم "الخالية" المتداخلة لا تزيل المفاتيح كما هو متوقع

@ scottrigby ، هل تريد بأي فرصة أن تتفوق على هذا؟

وضع علامة على السؤال / الدعم حتى يتم التأكد من أن هذا خطأ بالفعل وفقًا للمؤلف الأصلي.

أرى هذا أيضًا في 2.12.3. أرى أثناء محاولة تعيين القيمة على خالية عبر كل من -f و - set. في كلتا الحالتين ، تقوم فقط بتعيينها على "فارغة" كسلسلة (بدون علامات الاقتباس) بدلاً من إزالة القيمة الافتراضية.
حالتي:

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

حالة الاستخدام هي إعادة تعيين هذه القيم لاستخدام الإعدادات الافتراضية من القالب بدلاً من القيم الافتراضية التي أصبحت عالقة الآن في الدفة.

مستقرة / filebeat

مع null أو nil أرى نفس الشيء ... لم تتم إزالة المفتاح ... تمت الكتابة فوقه كـ null/nil ولكن لم تتم إزالته وعندما تقوم بالاستبدال مع مفتاح مختلف يسبب مشكلة:

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

"يامل
- تجاوزاتي
الإخراج.
المضيفون:
- " http: // localhost : 9200"
الإخراج. الملف: فارغة

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

أو

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

أخطاء البود كالتالي:

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

أواجه أيضًا هذه المشكلة بالضبط مع مخطط Filebeat.

cdenneen يمكنك config.output.file.enabled=false .

أواجه مشكلة حيث أريد استخدام المفتاح inputs لـ filebeat ولكن لا يمكنني إزالة المفتاح prospectors .

القيم الموجودة:

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

تجاوزي: --set config.filebeat.prospectors=null

النتيجة: (يتم استخدام التكوين لتعيين قيمة سرية)

filebeat:
  prospectors: null

لقد واجهت أيضًا هذه المشكلة مع stable/kibana و stable/filebeat ستتحول المفاتيح افتراضيًا إلى قيم المخطط حتى عند تحديد !!null .

aeijdenberg اعتقد أن العلاقات العامة الخاصة بك تتطلب فقط تحديث الملصقات

مرحبًا @ bacongobbler آسف لقد فاتني سؤالك في https://github.com/helm/helm/issues/5184#issuecomment -456138448. يمكنني التحقق من أنه خطأ. في # 2648 كان يجب أن أضيف اختبارًا يطابق المثال الموثق. كنت قد قصدت العودة إلى هذا ولكن يبدو أن # 5185 واعد! 👏 سوف تستجيب هناك

مرحبًا @ scottrigby . هل لي أن أعرف أي إصدار سيتضمن إصلاح # 5185؟ لقد واجهت هذه المشكلة للتو عند محاولة إزالة تعريفات الموارد على مخطط istio.

من المفترض أن يكون هذا في 2.14.2 - لكن لا يمكنني تشغيله.

أنا أتبع مثالًا مشابهًا جدًا لذلك في الجزء العلوي من المشكلة - والفرق الوحيد الذي يمكنني رؤيته هو أنني أحاول حذف قيمة معينة في مخطط فرعي (في حالتي ، logstash).

لقد حاولت:

• تعيين logstash.livenessProbe.http انتقل إلى null و ~ و {} في قيم المخطط الرئيسي.yaml أو في سطر الأوامر. في كلتا الحالتين ، يوضح "نموذج helm" أن القيمة الأصلية لا تزال موجودة (أي ما زلت أحصل على httpGet set) - وهذا يتوافق مع ما أراه في "تثبيت الدفة"
• إعداد logstash.livenessProbe.http احصل على "لا شيء" - في هذه الحالة يتم الكتابة فوق القيمة ، ولكن إلى السلسلة "لا شيء" التي ليست قيمة صالحة لاستخدامها هنا ، لذلك يرفض kubernetes القالب.

هل أسأت الفهم وهذا لم يصل إلى 2.14.2 - أم لا تزال هناك مشكلة؟

(رسم بياني يوضح هذا: demo.zip )

تم اختيار التصحيح بالكرز في 2.14.2 وفقًا لملاحظات الإصدار لذا يجب أن يكون متاحًا.

في هذه الحالة ، لست متأكدًا من إصلاح هذا الخطأ - هل يجب إعادة فتحه أم إنشاء مشكلة جديدة؟ هل يمكن لشخص آخر إلقاء نظرة على الرسم البياني الذي أرفقته بما ورد أعلاه ومعرفة ما إذا كان يرى اختلافًا؟

@ cc-stjm @ bacongobbler - أنا قادر على إعادة إنتاج المشكلة ، وأعتقد أن هذا الاختبار

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

المشكلة ، بقدر ما أستطيع أن أقول ، هي أن CoalesceValues() ينتج أكثر من استدعاء للوظيفة الأساسية التي تقوم بفحص القيم:
https://github.com/helm/helm/blob/e04fa72f6f211cae68c362f9b7c62f06dc51493e/pkg/chartutil/values.go#L164 -L180

على سبيل المثال ، يتم استدعاء السطر 173 أعلاه مع تعيين httpGet على null ، لكن القيمة التي يتم إرجاعها قد حذفت هذا المفتاح من الخريطة (كما هو مقصود). ولكن بعد ذلك يتم تمرير هذا الإخراج للمرة الثانية كمدخل إلى المجموعة الثانية من الاندماج (السطر 179) ، وبعد ذلك بما أن المفتاح لم يعد موجودًا ، فإنه يتم تعيينه افتراضيًا على القيمة الموجودة في المخطط.

لسوء الحظ ، من غير المحتمل أن يتوفر لي الوقت في المستقبل القريب للمضي قدمًا - لقد غيرت الأدوار ولا أستخدم Helm حاليًا ، والإجابة عن كيفية الحل ليست واضحة بالنسبة لي. نأمل أن يكون ما ورد أعلاه مفيدًا في الحل.

في الواقع ، لقد قمت للتو بترقية 2.14.0 => 2.14.2. لا يقتصر الأمر على استمرار وجود المفتاح null ed ، ولكنه يحتوي أيضًا على القيمة السابقة. السلوك السابق جعلها لاغية ، لذلك أعتقد أن هذا قد تراجعت بالفعل.

aeijdenberg هل يمكنك رجاء النظر في استفسارsgillespie ؟ إذا كان هناك تراجع ، فمن المحتمل أن يكون دعم العلاقات العامة أكثر أمانًا ما لم تتمكن من تحديد الإصلاح. إذا لم تكن قادرًا على المساعدة ، فمن المحتمل أن يكون من الأكثر أمانًا التراجع عن الالتزام والعودة إلى المربع 1. اسمح لي أن أعرف كيف تريد المتابعة.

bacongobbler ، بينما لم أختبر 2.14.0 صراحة ، ما sgillespie يطابق السلوك الذي أشرت إليه في https://github.com/helm/helm/issues/5184#issuecomment-517059748 . للأسف ، أعتقد أنها حالة اجتياز اختبارات الوحدة ، ولكن الفشل من النهاية إلى النهاية - حيث يتم استخدام المكونات الفردية في سلسلة ، مما يجعل إزالة مفتاح في مرحلة سابقة لا يكون له أي تأثير في المراحل اللاحقة (ولهذا السبب القيم الأصلية تأتي من خلال).

أوافق على أنه تراجع ، على الرغم من أن دعمه يعد أيضًا تراجعًا لأي شخص يعتمد على السلوك الجديد.

لقد قمت بعمل سريع في تصحيح بسيط نسبيًا والذي أعتقد أنه سيقلل من التأثير (ويصلح الاختبار الذي أضفته أعلاه) في # 6146 - أنا آسف لأننا أخطأنا في المحاولة الأخيرة.

ربما تم إصلاح هذا في https://github.com/helm/helm/pull/6080. تعمل العلاقات العامة على إصلاح الحالة التي يتم فيها استدعاء coalesceDeps مرتين. هل يمكن لأحد أن يؤكد مع السيد؟

إذا كان الأمر كذلك ، فهل يمكن إغلاق # 6146 أم أنها تحاول إصلاح مشكلة منفصلة؟ أحاول أن أفهم رأسي حول مساحة المشكلة هنا ولكن من غير الواضح ما الذي يحاول هؤلاء العلاقات العامة حله. آسف.

يبدو أن هذا بالفعل يصلح المشكلة. اختبار سريع ساذج:

قيم المخطط الفرعي:

prop:
  nested:
    val: true

قيم المخطط الأصلي:

sub:
  prop:
    nested: null

الإخراج كما هو متوقع هو {}

مرحبا،

أنا أستخدم helm 2.15.0 وما زلت أواجه هذه المشكلة.

إعطاء مخطط فرعي مع القيم:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

حيث يتم استخدام القيم مع toYaml

وفي قيم الرسم البياني الأصل:

sub:
  securityContext:
  runAsUser: null

ثم الناتج الفعلي هو:

securityContext:
  runAsUser: 65534
  fsGroup: 65534

بينما كان يجب أن يكون:

securityContext:
  fsGroup: 65534

لا أحاول أن تمطر على موكبك ، لكنني ما زلت أرى هذا مع helm v3.0.1

version.BuildInfo {الإصدار: "v3.0.1" ، GitCommit: "7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa" ، GitTreeState: "نظيف" ، GoVersion: "go1.13.4"}

عند محاولة تثبيت مستقر / إشعال ، لا بد لي من إلغاء تعيين قيمة ، ولكن يبدو أن helm قد عيّن القيمة على null / nil ، مما تسبب في توقف k8s في خطوة التحقق من الصحة.

لإعادة الإنتاج ، احفظ هذا كـ bug5184-ignite.yaml (لتجاوز القيم من الإعدادات الافتراضية للمخطط: 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

ثم استخدمه كملف قيم لتثبيت الإشعال:

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

النتيجة التي أحصل عليها هي رسالة الخطأ هذه ، والتي توضح أن القيمة التي أردت إلغاء تعيينها قد تم تعيينها على 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
[...]

ما جربته أيضًا:

• تحديد القيمة لشيء مختلف / عدم تجاوزها على الإطلاق
  
  
  
  • => إن PersistentVolumeClaim عالق في "Pending" لأن هناك خيار "type" إضافي لا يدعمه الموفر
  
  
  • => إنها بالتأكيد تلك القيمة التي تسبب المشاكل
  
  
• تعيين القيمة (القيم) على null عبر --set
  
  
  
  • نفس السلوك عند وضعه في الملف
  
  

عند تعيين قيمة واحدة فقط إلى null عبر سطر الأوامر ، بينما يتم تعطيل استمرار الإشعال في نفس الوقت (بحيث لا يتم إنشاء قالب فئة storageclass وتجاهل المعلمة المعنية) ...

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

... هناك إخراج تصحيح أخطاء مناسب بدلاً من الخطأ ، لكنه يوضح أنه تم تعيين القيمة للتو على null (التعليقات التي أضفتها):

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

لقد واجهت نفس المشكلة بالضبط باستخدام 3.0.1 ، قد يكون من الجيد إعادة فتح هذه المشكلة؟

بعد الانتقال من helm v2.16.1 إلى v3.0.2. لقد واجهت هذه المشكلة مع قيود التعليقات التوضيحية وحدود وحدة المعالجة المركزية.

لقد واجهت للتو هذه المشكلة في 2.14.1 و 3.0.2 . أي تحديث على هذا؟

في الحالات التي أعرف فيها أن مخطط الدفة يستخدم ببساطة وصواب / خطأ إذا كان الاختبار ، فأنا أتخطى القيمة بقيمة غير جدولية مثل 0. أحصل على الكثير من التحذيرات مثل Overwriting table item 'x', with non table value: 0 ، لكنني على الأقل أحصل عليها حل بديل في الحالات التي لا أريد فيها تضمين مقطع موسيقي. أفضّل أن يعمل null ، لكن هذا حل بديل قبيح.

لقد قمت بتعيين القيم على خالية (وتركتها خالية في ملفات القيم الخاصة بي) وتجاهلت القائمة الطويلة لتحذيرات الجدول التي لا بأس بها في الوقت الحالي ، لكنني أود فعلاً إجراء تنظيف لمرة واحدة للقيم القديمة غير الصحيحة المخزنة في kubernetes. حتى يتم إصلاح خطأ حذف القيمة هذا ، هل هناك طريقة يدوية لتحرير القيم في عملية نشر موجودة بدون وقت تعطل؟

واجهت نفس المشكلة مع مجسات liveness و readiness .
لا يعمل حذف المفتاح الافتراضي من دليل النموذج.

الرجاء المحاولة # 7743. يبدو أن الالتزامات التي تم إجراؤها على Helm 2 لم يتم تحويلها إلى Helm 3 ، ولهذا السبب قد يرى العديد من المستخدمين هذا السلوك هناك.

ما زلت ترى هذه المشكلة مع helm 2.16.3 ولكن فقط عندما تكون هناك متطلبات. yaml يسرد المخطط الفرعي على أنه تبعية.

boo هو المخطط الفرعي و foo هو الرسم البياني الرئيسي:

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

كلا المخططين هنا:

helm_5184.zip

bacongobbler هل هناك أي نية لمزيد من معالجة هذا في 2.x؟

لقد واجهنا هذه المشكلة أيضًا (على غرار تلك التي وصفهاvbuciuc) مع عدم عمل "فارغ" لتجاوز القيم عند إدراج المخطط الفرعي باعتباره تبعية في المتطلبات. yaml مع 3.2.x. الإصدارات السابقة (3.1.x) تعمل كما هو متوقع.

bacongobblertechnosophos أواجه هذه المشكلة أيضًا مع Helm 3.3.4 ، هل يمكنك إعادة فتحها ؛

أستطيع أن أؤكد أنها عملت في 3.1.2 وتوقفت عن العمل بعد 3.2.x كما ذكر paleg . في الوقت الحالي ، يبدو أن حل @ tuzla0autopilot4 لتعيينه إلى قيمة غير خريطة مثل false سينتج السلوك المقصود ولكنه يعطي تحذيرات الإخراج عند الانتهاء من ذلك.

@ Chili-Man ، لقد حاولت للتو استخدام 3.1.3 ولا يبدو أنه يعمل. سيتم تطبيقه null لكني أتلقى تحذيرًا ولا يفعل شيئًا. مع أي شيء آخر ( false ، 0 ، [] ) يرفض مع (على سبيل المثال ،)

"` coalesce.go: 196: تحذير: لا يمكن الكتابة فوق الجدول بدون جدول للموارد (الخريطة [الطلبات: الخريطة [cpu: 250m memory: 256Mi]])
خطأ: فشل الترقية: القيم لا تفي بمواصفات المخطط (المخططات) في المخطط (المخططات) التالية:
postgresql:

• الموارد: نوع غير صالح. متوقع: كائن ، معطى: منطقي
  `` (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` وبالمثل كل شيء آخر يرفض التقديم. أكثر مزعج...

ما زلت أواجه هذه المشكلة في 3.4.2.

لا تزال المشكلة موجودة في 3.4.2 ، ولكن فقط في مواقف معينة.
لدي مخطط به عدة مخططات فرعية.
عند وضع القيم الافتراضية في المخطط الفرعي ، لا يعمل التخطي null . إذا قمت بنقل نفس القيم إلى قيم الرسم البياني الأصل ، فستعمل كما هو متوقع.
هذا قابل للتكرار فقط مع المخططات الفرعية. عندما تضعه في مخطط واحد (مسطح) ، كل شيء يعمل بشكل جيد.

أواجه نفس المشكلة مع 3.4.2 عند استخدام المخططات الفرعية (كما هو موضح في BohdanKalytka أعلاه).
في حالتي ، أريد الكتابة فوق securityContext عند استخدام مخطط رأس ElasticSearch في مجموعة OpenShift.
هل سيتم إعادة فتح هذه المشكلة ، أم يجب علينا إنشاء واحدة جديدة؟

أثار # 9136