Helm: - اضبط أرقام التوزيعات فقط على أنها float64

تم إنشاؤها على ١٧ ديسمبر ٢٠١٦  ·  68تعليقات  ·  مصدر: helm/helm

لقد لاحظت للتو أن شيئًا مثل helm install --set tag=20161216 ينتهي بالتدوين العلمي في القالب وذلك لأن {{ typeOf .Value.tag }} ينتج float64 .

هذا صحيح حتى بالنسبة للأعداد الصحيحة الصغيرة مثل helm install --set tag=1 -> float64 .

هذا يحدث مع helm 2.1.0

help wanted

التعليق الأكثر فائدة

التوافق الوراء؟ من الميزات التي هي مجرد "WTF" ومن المحتمل ألا يريدها الكثيرون أو يستخدمونها؟ في أداة تخضع لتطوير كبير ولا يتم تبنيها على نطاق واسع؟ أقترح إعادة التفكير في ذلك وإصلاحه قبل فوات الأوان.

ال 68 كومينتر

هل تعمل بشكل مختلف إذا قمت بعمل --set tag=\"1\" ؟

بفضل chancez ، نعرف المشكلة بالضبط: أثناء التحويلات من وإلى JSON التي تم إجراؤها بواسطة ghodss/yaml ، يتم تحويل الأعداد الصحيحة إلى float64s لتمثيل النوع الرقمي لجافا سكريبت. هذا يتسبب في تمثيل جميع الأعداد الصحيحة فوق قيمة معينة في التدوين العلمي.

لقد تعرضت للعض من نفس المشكلة. طريقة تجاوز الحدبة (أو الحشرة) هي القيام بذلك:

--set bignumber=\\"a185576882739235744\\"

الحل الآخر الذي استخدمناه هو القيام بأشياء مثل هذه:

--set port=":1234567"

ثم في النموذج:

{{ .Values.port | replace ":" "" }}

ياك! 😷

هذا أمر مؤلم ، ولا يبدو أن حل ipedrazas يعمل بالنسبة لي ، أو أي مزيج آخر من الاقتباس / الهروب الذي جربته.

لست مستعدًا تمامًا بعد لابتلاع كبريائي ومحاولة

في الوقت الحالي ، أقوم بالتغلب على هذا من خلال توسيع برنامج النشر الخاص بي لكتابة البيانات كـ yaml إلى ملف مؤقت واستخدام ذلك كوسيطة -f .

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

في حالتي ، أرى هذا أدناه على --set image.tag=5997578 :

$ kubetctl describe po msj-treasure-map-msj-treasure-map-192172122-dnb80
...
Events:
  Type     Reason         Age               From                                    Message
  ----     ------         ----              ----                                    -------
  Normal   Scheduled      1m                default-scheduler                       Successfully assigned msj-treasure-map-msj-treasure-map-192172122-dnb80 to ip-10-253-13-113.ec2.internal
  Warning  InspectFailed  15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": invalid reference format
  Warning  InspectFailed  15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": invalid reference format
  Warning  FailedSync     15s (x9 over 1m)  kubelet, ip-10-253-13-113.ec2.internal  Error syncing pod, skipping: [failed to "StartContainer" for "msj-treasure-map-uwsgi" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": invalid reference format"
, failed to "StartContainer" for "msj-treasure-map-nginx" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": invalid reference format"
$ helm version                                                                                                                                                                             
Client: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}

كما أنني أواجه نفس المشكلة على دفة 2.6.2.

Client: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
  • 1

يؤدي تجريد YAML إلى JSON إلى إزالة الكثير من المعلومات ، ومعظمها متعلق بالنوع. يعني أنه لا يمكنك كتابة قيم التحقق قبل النشر.

أعتقد أنه يمكن حل هذا بالانتقال إلى مكتبة yaml مختلفة. ربما هذا: https://github.com/go-yaml

بينما كنت أعاني من هذه المشكلة اليوم ، اكتشفت أن الفلتر toString يمكن أن يساعد في هذا:

dockerPort: {{ .Values.dockerPort | toString }}

ثم تمكنت من تمرير المنفذ في سطر الأوامر ( --set dockerPort=2376 ) وتم تفسيره بشكل صحيح.

لقد رأينا هذا للتو في 2.7.2 ومعظم الحلول لا تعمل حقًا بالنسبة لنا باستثناء كتابة جميع خيارات --set إلى ملف محلي وتمرير ذلك عبر helm -f locals.yml .

لقد رأيت هذا أيضًا في 2.7.2 (وقدمت # 3246 نتيجة لذلك) ، لذا +1 في هذه المشكلة. كما هو الحال في https://github.com/kubernetes/helm/issues/3001 ، كنت أستخدم أيضًا git SHAs لعلامات صورة عامل الإرساء. الحل البديل الآن ، FWIW ، هو إضافة علامات الصورة بـ -gitsha

+1 بالنسبة لي أيضًا.

$ helm version                                                                                                                                    ⏎
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

$ git rev-parse --short HEAD
6180689

$ helm upgrade foobar \
    -i charts/foobar \
    --set image.tag=$(git rev-parse --short HEAD) \
    --reuse-values

بعد النشر ، أحصل على هذا:

Failed to apply default image tag "gcr.io/foobar/foobar:6.180689e+06": couldn't parse image reference "gcr.io/foobar/foobar:6.180689e+06": invalid reference format
Error syncing pod

أحصل أيضًا على InvalidImageName عند تشغيل kubectl get pods .

لا يبدو أن إلحاق | toString يحدث فرقًا بالنسبة لي.

هل يمكنك فقط القيام بما يلي:

{{ .Values.tag | int64 }}

لا شك أنlaverite في الرسوم البيانية ، ولكن هذا يستخدم المحلل اللغوي set. توجد هذه المشكلة فقط للمحلل اللغوي - set. القيم التي تم تمريرها عبر القيم. yaml يتم تحليلها بشكل صحيح. :)

يبدو أن هذا مرتبط بالرقم 3155

نعم ، صدق ذلك

نفس المشكلة هنا مع helm 2.8.0.

bacongobbler أو technosophos لدي إصلاح لهذه المشكلة على رقم 3599 ، هناك بالفعل موافقة واحدة ، فقط بحاجة إلى أخرى. شكرا!

تم حلها عبر # 3599

شكرا على ping @ arturo-c :)

رؤية هذا الخطأ أيضًا مع Helm 2.9.1

أتساءل لماذا لا يصطاد helm lint هذا؟ انظر # 4099

لدي فضول لماذا تم حل هذا عن طريق إضافة --set-string ، بدلاً من إصلاح ما يبدو لي أنه خطأ واضح في --set .

هل من المحتمل أن ينوي أي شخص أن يتم إجبار الأرقام على التدوين العلمي في ملفات yaml الخاصة بهم؟

كلمتين: التوافق مع الإصدارات السابقة :)

يمكننا تغيير كيفية قيام المحلل اللغوي --set بفرض القيم الصحيحة في Helm 3 ، ولكن بشكل عام اخترنا منع تغيير السلوك المتوقع للوظائف الأساسية مثل --set نظرًا لوجود العديد من المستخدمين الذين يقومون بتشغيل Helm في الانتاج. لا يمكننا أيضًا إجبار جميع القيم في --set على السلاسل لأن ذلك سيؤدي إلى كسر السلوك الحالي مثل السلوك المتوقع حول --set-string كإجراء عملي حل في الوقت الحاضر.

التوافق الوراء؟ من الميزات التي هي مجرد "WTF" ومن المحتمل ألا يريدها الكثيرون أو يستخدمونها؟ في أداة تخضع لتطوير كبير ولا يتم تبنيها على نطاق واسع؟ أقترح إعادة التفكير في ذلك وإصلاحه قبل فوات الأوان.

technosophos شكرا.
مثال:

kind: Secret
data:
  some_db_port: {{ .Values.dbInfo.db_port | replace ":" "" | b64enc }}

إنه عمل بالنسبة لي.

OndraZizka شكرًا لك على التعليقات (المتحمسة جدًا). نحن بالتأكيد نتطلع إلى معالجة بعض هذه المشكلات السلوكية المتزعزعة التي يمتلكها المحلل اللغوي --set لـ Helm 3 ، على الأرجح عن طريق استبدالها بشيء مشابه للمحلل اللغوي الجديد --set-string .

أوافق تمامًا على أن سلوك --set غريب جدًا في هذه الحالة (وحتى خاطئ تمامًا) ، لكن لا يمكننا أن نتوقع استبدال مكتبة تحليل كاملة بأخرى وأن نكون على ثقة من أنه لن يكون هناك أي إكراه آخر البق في النظام الجديد. يُعتبر تبديل مكتبات الإكراه تغييرًا غير متوافق مع الإصدارات السابقة.

في الوقت الحالي ، تعد ميزة --set-string ميزة رائعة وأنا أوصي بها بشدة لأي شخص آخر يواجه هذا الخطأ ليرجى استخدام --set-string قدر الإمكان عندما لا تعتمد على نوع الإكراه. بهذه الطريقة ، يتم فرض القيم كسلسلة وليس كعائمة.

لسوء الحظ ، عندما يقوم Ansible بتنسيق dict إلى yaml (وهي قيمي.yaml) ، فإنه لا يضيف أي اقتباسات ، وهي مشكلة كبيرة بالنسبة لي. لا أصدق أنني مضطر لاستخدام هذا الاختراق الدموي: replace ":" ""

إذا كنت بحاجة إلى عمل حول يعمل بدون إضافة بادئة إلى العلامة بـ : وإزالتها لاحقًا ، يمكنك استخدام هذا (tl ؛ dr: عندما تكون العلامة رقمًا ، استخدم printf لطباعتها ، وإلا اطبع سلسلة لديك)

{{- $tag :=  .Values.image.tag }}
{{- $type := printf "%T" $tag }}
image: "{{ .Values.image.repository }}:{{if eq $type "float64"}}{{ printf "%.0f" $tag }}{{ else }}{{ $tag }}{{ end }}"

يحدث الخطأ أيضًا مع helm ... -f myval.yaml

لمعلوماتك ، تم إصلاح هذا في https://github.com/helm/helm/pull/6010.

bacongobbler ما زال يحدث لي مع إصدار الدفة v2.14.3

هل يمكنك فتح عدد جديد؟ شكرا.

إعادة الفتح بسبب الحاجة للعودة # 6010 في # 6749.

أي وقت مقدر للوصول عندما يكون الإصلاح متاحًا؟

انظر # 6888.

sagarkal للتأكد من أننا على نفس الصفحة: الإصلاح المذكور أعلاه يهدف فقط إلى الوصول إلى Helm v3 ، وليس v2 (أعلن هذا كمساهم عشوائي ، والقرار الفعلي متروك دائمًا للفريق). التغيير ضخم نسبيًا ولا ينبغي اعتباره آمنًا بنسبة 100٪ ليتم دمجه في فرع 2.x ، وهو التصحيح فقط الآن. في غضون ذلك ، إذا كانت لديك فرصة ، فسيكون من الرائع أن تتمكن من اختبار فرع العلاقات العامة مقابل حالة الاستخدام الخاصة بك وإعلامنا إذا كانت الأشياء تعمل كما هو متوقع. هذا سيساعد كثيرا!

استخدام --set-string image.tag=6599236 نجح معي في استخدام قالب عادي مثل هذا

  ...
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          env:
  ...

يعمل في هذا مع قيمة عددية كبيرة محددة في ملف قيم الرسم البياني. يتم تحويله ضمنيًا إلى عدد عشري مع تدوين علمي. مجرد تحويل القيمة إلى int أصلح هذا ، ويبدو أنظف بكثير من بعض الحلول الأخرى التي رأيتها:

# values.yaml

tomcat:
  maxPostSize: 2097152
# Cast to int when used

{{ .Values.tomcat.maxPostSize | int }}

تم اختبار هذا مع Helm v3.1.1.

من الجيد معرفة! هذا بالتأكيد حل سهل مقارنة بالعديد من الأشياء التي رأيتها. شكرا!

Rathgore يعتبر Casting إلى int مثاليًا عند التعامل مع ints طوال الوقت ولكن في حالتي ، يجب التعامل مع قيمة الإدخال كسلسلة ولكنها تأتي في شكل أرقام (أحيانًا). على سبيل المثال ، يكون تطبيق جيثب ذو 7 أطوال مختصرة ، وأحيانًا يكون عبارة عن سلسلة وأحيانًا يكون مجرد سلسلة من الأرقام. في هذه الحالة ، يتم تمرير القيمة باستخدام الخيار --set-string كل مرة.

@ m0rganic لم أختبر هذا ، ولكن يمكنك محاولة استخدام toString بدلاً من int أو تعيين النوع صراحةً باستخدام !!str . هذا ليس ضروريًا إذا كنت تستخدم --set-string فقط ولكننا نحتاج إلى هذا السلوك للقيم المحددة في الرسم البياني أيضًا.

@ m0rganic لم أختبر هذا ، ولكن يمكنك محاولة استخدام toString بدلاً من int أو تعيين النوع صراحةً باستخدام !!str . هذا ليس ضروريًا إذا كنت تستخدم --set-string فقط ولكننا نحتاج إلى هذا السلوك للقيم المحددة في الرسم البياني أيضًا.

toString لا يعمل ، وفي بعض الحالات ، لا يمكنني استخدام !!str .

هل هناك خطة لإصلاح هذا السلوك؟ ظلت هذه القضية مفتوحة منذ فترة طويلة ...

انظر # 6888. بخلاف ذلك لا. لقد وثقنا العديد من الأنماط لاستخدامها. لكننا لم نعثر على حل يحل مشكلات أكثر مما تسببه. لا تتردد في تجربة يدك في العلاقات العامة.

شكرا على الاستجابة السريعة! لست متأكدًا من أن أيًا من الحلول المقترحة يحل حالة الاستخدام الخاصة بي ، لكنني سأحاول مرة أخرى.

هل تعمل بشكل مختلف إذا قمت بعمل --set tag=\"1\" ؟

في حالتي ، استخدمت "" في قيم int و float و bool وقد نجحت ، شكرًا

بناءً على هذا التعليق ، قد يبدو أن هذه لم تعد مشكلة بالنسبة إلى Helm 3 ، فقط لـ Helm 2. أحب أن أسمع من لا يزال يواجه هذه المشكلة وكيف وما هي إصدارات Helm.

بالنسبة لمستخدمي Helm 2 ، نحن نقبل فقط تصحيحات الأمان في هذه المرحلة ، لذلك لن نتطلع إلى إصلاح هذا الخطأ لـ Helm 2. ومع ذلك ، إذا كان هذا لا يزال مناسبًا لـ Helm 3 ، فسأكون ممتنًا لمزيد من المعلومات من المجتمع حول هذا الخطأ بالذات.

بالنسبة إلى helm 2 ، يمكنك الإرسال إلى ما تريد بين () كمثال أدناه

{{- range $i := until (int .Values.deployment.numberofracks) }}
  - name: rack{{$i}}
{{- end}}

سأفترض أن هذا قد تم إصلاحه لـ Helm 3 ، حيث مرت 3 أسابيع منذ آخر مرة نشرت فيها أنه يبدو أنه قد تم إصلاحه. إذا كان لا يزال هناك آخرون يواجهون هذه المشكلة مع Helm 3 ، فلا تتردد في مناقشة هذا الأمر ويمكننا إعادة فتح هذه المشكلة. شكرا!

وما زالت هذه المسألة؛ أنا على 3.3.0 وما زلت أعاني من ذلك.

هل يمكنك تقديم مظاهرة من فضلك؟

سعيد بذلك ، لكنني لست متأكدًا تمامًا من كيفية القيام بذلك ؛ لدي مخطط في values.yaml حقل يبدو كالتالي:

customEnv:
  SOME_ENV_VAR: 10000000

ثم في templates/deployment.yaml ، لدي هذا:

    ...
    containers:
      - name: someContainer
        env:
           {{- range $key, $value := .Values.customEnv }}
            - name: {{ $key | quote }}
              value: {{ $value | quote }}
          {{- end }}
    ...

عندما أقوم بتشغيل helm template ، أحصل على هذه القيمة في الإخراج المعروض:

    ...
    containers:
      - name: someContainer
        env:
            - name: "SOME_ENV"
              value: "1e+07"
   ...

ثم يفشل تطبيقي الذي تم نشره عندما يحاول تحليل قيمة SOME_ENV كرقم.

تمام. تمكنت من إعادة إنتاج نفس المشكلة باتباع تعليماتك مع Helm 3.3.1. شكرا لك. إعادة الفتح.

أواجه نفس المشكلة لزاوية مختلفة قليلاً. appVersion هو 8482e77 ، إذا أشرت إلى appVersion أي مكان يتم عرضه كـ +Inf . هذا هو متعة لتصحيح راجع للشغل.

يحرر:
تغيير appVersion من appVersion: 8482e77 إلى appVersion: "8482e77" إصلاح مشكلتي

هذا متوقع. غير مقتبس ، يوزع YAML هذه القيمة كتدوين علمي (مثل 8482e77 يعني “8482 * 10 ^ 77”). إذا كنت تريد معاملة قيمة كسلسلة ، فلفها بين علامتي اقتباس.

لدي هذه المشكلة مع علامة الصورة contianer. تمت معالجة المشكلة بإنشاء المساعد أدناه:

+{{/* Generate Image Name */}}
+{{- define "helpers.image" }}
+{{- $tag := printf "%f" .Values.app.image.tag -}} 
+{{- if regexMatch "^[0-9]+\\.[0-9]+$" $tag }}
+{{ .Values.image.repository }}:{{ .Values.image.tag | int }}
+{{- else }}
+{{ .Values.image.repository }}:{{ .Values.image.tag }}
+{{- end }}
+{{- end }}

وبعد ذلك ، في بيان النشر:

   containers:
       - name: {{ template "helpers.fullname" . }}
         image: {{ template "helpers.image" . }}

هل تم حل هذه المشكلة؟ إذا لم يكن كذلك ، فأنا أود إصلاح هذا.

رقم انظر أعلاه . يرجى التأكد من قراءة الموضوع واختباره بنفسك. :)

تم وضع علامة على هذه المشكلة على أنها قديمة لأنها كانت مفتوحة لمدة 90 يومًا بدون أي نشاط. سيتم إغلاق هذا الموضوع تلقائيًا في غضون 30 يومًا إذا لم يحدث أي نشاط آخر.

نتوء ، لا تزال مشكلة

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

{{- define "numericSafe" -}}
{{- if . | toString | contains "e+" -}}
{{ . | toString | replace "." "" | regexFind "^\\d+" }}
{{- else -}}
{{ . }}
{{- end -}}
{{- end -}}

ثم استخدم مع

{{ include "numericSafe" .Values.git.commitID }}

إنه يحل المشكلات إذا لم تحتوي سلسلتك الأصلية مطلقًا على نقطة و e+ ، على الرغم من أنني لا أعرف ما إذا كانت سلسلة رقمية طويلة جدًا سيتم حذف أي شيء.

urakagi للأسف ، هذا لا يعمل إذا كانت 1800000

هل هناك إصلاح مخطط لهذه المشكلة؟

أي تحديثات؟

bacongobbler ، فإن repro من edobry هي في الواقع مشكلة مختلفة. كان هذا في الأصل حول القيم التي يتم تمريرها باستخدام --set ، والذي تم إصلاحه الآن وتمت إضافة الخيار --set-string .

إن repro عبارة عن رقم داخل القيم ، يتم تغيير yaml إلى تدوين علمي. يمكن إصلاح repro باقتباس الرقم في values.yaml ، إذا كان يجب معاملته كسلسلة. إذا تم استخدامه كرقم ، فلا ينبغي أن تكون الرموز مشكلة.

نظرت في الكود وأعتقد أنني سأكون قادرًا على تغيير السلوك لإخراج الأرقام في التدوين القياسي بدلاً من 20 رقمًا عشريًا. بعد ذلك يبدو أن هناك حدًا معينًا للتنفيذ في المحلل اللغوي yaml الأساسي الذي يقوم بتقريب أعداد كبيرة جدًا و / أو تحويلها إلى تدوين علمي.

لقد حاولت أيضًا العثور على مشكلة أخرى من شأنها التعامل مع المشكلة كما هو موضح في reproedobry ووجدت # 9162 حيث يبدو أن الحل هو أن هذا هو المقصود حيث يقوم المحلل اللغوي بتحليل القيم كما يراها مناسبة وداخل حدود مواصفات yaml.

لذلك عندما يستخدم شخص ما ، على سبيل المثال ، علامات رقمية ، والتي لا تحتوي على أي قيم عددية (لم يتم تحديد أي حساب عليها) ، يجب أن يتم اقتباسها في values.yaml ليتم التعامل معها كسلاسل ويجب أن يؤدي ذلك إلى حل المشكلة:

# values.yaml
foo: "10000000"
# template
foo: {{ .Values.foo | quote }}



md5-aba98a385ca8fe457cb1f98967ed3bf1



# Source: foo/templates/x.yaml
foo: "10000000"



md5-265ed31678f08bdbd76c259b974f5398



# Source: foo/templates/x.yaml
foo: "1e+07"



md5-3df6a1bc5fe8f474ded5c2033aaf11a3



# Source: foo/templates/x.yaml
foo: "10000000"

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات