Helm: Acceder a los valores del subgráfico con un guión en el nombre

Esta es una buena pregunta. No he tenido problemas para hacer esto, pero es una inconsistencia. @technosophos ¿Deberíamos cambiar uno de estos para que coincida con el otro?

Actualmente estoy experimentando el problema al acceder a los valores de dicho subgráfico.

El siguiente bloque me da un error.

{{ if .Values.gitlab-runner.enabled }}

Error: ACTUALIZACIÓN FALLIDA: error de análisis en "gitlab / templates / deployment.yaml": plantilla: gitlab / templates / deployment. yaml: 217 : carácter incorrecto U + 002D '-'

Utilice la función de plantilla index para acceder a un valor con un '-' en el nombre: {{ index .Values "gitlab-runner" }} .

Y probablemente deberíamos cambiar la convención. Eso hace que sea un fastidio lidiar con cosas como esta. Me asigné el tema a mí mismo para ir a cambiar la convención.

gracias, funciona de esta manera.

@prydonius ¿Recuerda la razón por la que inicialmente decidimos que los gráficos deberían ser nombrados con guiones? Estaba revisando documentación anterior y este ha sido un precedente que establecimos desde el principio. Estoy pensando que tal vez no sea tan buena idea cambiarlo.

Estoy tratando de entender cómo funciona el índice.
¿Cómo puedo acceder al servicename desde:

mysub-chart:
  servicename: mysubchart-service

?
Solución encontrada: {{ index .Values "mysub-chart" "servicename" }}

¿Cómo usaría los nombres de guión en una estructura de control, como un bloque with o range ?

{{- range $key, $value := .Values.my-service-name.deployment.annotations }}

@spearsem Creo que el comentario anterior tiene la solución adecuada para ese problema. Creo que esto debería funcionar:

{{- range $key, $value := index .Values "my-service-name" "deployment" "annotations" }}

De lo contrario, creo que puede crear una instancia de una variable que apunte a las anotaciones y usarla dentro del rango o con bloques. Por ejemplo

{{ $annotations := index .Values "my-service-name" "deployment" "annotations" }}
{{- range $key, $value := $annotations }}

@bacongobbler ¿Esto también funciona para with ? No estoy familiarizado con la implementación de with para saber si puede utilizar el resultado de otra evaluación de función como "el contexto".

text / template parece decir que debería funcionar con cualquier estructura, así que supongo que sí.

Si el valor de la canalización está vacío, no se genera ninguna salida; de lo contrario, dot se establece en el valor de la canalización y se ejecuta T1.

El método variable no parece funcionar para mí. . El error ocurre una línea más tarde.

La convención de nomenclatura de puertos de Istio también requiere guiones (consulte Requisitos de especificaciones de pod ).

¿Hay alguna solución para configurar vars en cli?

helm install --set one-two.three=10 releasename ./chartname

esto es una inconsistencia real y yo también tengo el problema.
Una solución es usar un alias en requirements.yaml para que el nombre de su subchart se cambie a algo sin el -, pero esto es realmente una molestia.

Yo también tengo este problema.

Creo que sería bueno si Helm pasara valores del gráfico principal a subchart-name usando el nombre camelcase-ify en su lugar, por ejemplo, subchartName . Haría que la convención de nombres de gráficos y la convención de nombres de variables fueran compatibles entre sí, además de evitar los problemas de sintaxis anteriores.

Esto no funciona en absoluto en las plantillas, este código de ejemplo:
{{index .Values ​​"primera clave" "segunda clave"}}
funciona en NOTES.txt pero en _helpers.tpl al emitir un comando de actualización:
_ayudadores. tpl: 24 : 3: ejecutando "test.template" en

Cliente: & version.Version {SemVer: "v2.6.2", GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState: "clean"}
Servidor: & version.Version {SemVer: "v2.7.0", GitCommit: "08c1144f5eb3e3b636d9775617287cc26e53dba4", GitTreeState: "clean"}

Lo mismo con ambas versiones iguales:
Cliente: & version.Version {SemVer: "v2.6.2", GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState: "clean"}
Servidor: & version.Version {SemVer: "v2.6.2", GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState: "clean"}

kubectl es:
Versión del cliente: version.Info {Major: "1", Minor: "9", GitVersion: "v1.9.2", GitCommit: "5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState: "clean", BuildDate: "2018-01-18T10: 09: 24Z ", GoVersion:" go1.9.2 ", Compilador:" gc ", Plataforma:" darwin / amd64 "}
Versión del servidor: version.Info {Major: "1", Minor: "8", GitVersion: "v1.8.4", GitCommit: "9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState: "clean", BuildDate: "2017-11-20T05: 17 43Z ", GoVersion:" go1.8.3 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

@svidrascu , compruebe que tiene los valores definidos en el archivo Chart.yaml para ese subgráfico específico. Parece que el motor de plantillas no puede encontrar su variable

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida podrido
/ remove-lifecycle stale

cerrado a través de https://github.com/helm/helm/pull/4379

Para su información, se realizó una enmienda a # 4379 en # 4400.

Esto es una tontería: sin guiones, ni subrayados, sin mayúsculas. ¿Cómo se debe definir el nombre del gráfico compilado para dos (o más) componentes simulares? Cambiar un . simple a " " es simplemente horrible :(

@ksemaev , consulte el número 4400. Como se mencionó anteriormente, todavía queremos que los usuarios usen guiones en los nombres de sus paquetes, pero deben ser conscientes de las "trampas" en torno a ciertas limitaciones con el sistema de plantillas.

Ups, el botón de cerrar con dedos gordos: riendo:

¿Hay alguna solución para configurar vars en cli?

helm install --set one-two.three=10 releasename ./chartname

Si alguien se pregunta, esto parece funcionar a partir del timón y el timón v2.14.2 .

$ helm install --set one-two.three=10 --name foo stable/mariadb
$ helm get values foo
# one-two:
#  three: 10

Realmente no tiene sentido permitir guiones en los nombres de los gráficos si no permite guiones en los valores. La razón es que a veces los valores son nombres de gráficos. Por ejemplo, tengo sub-chart.value que quiero especificar en el archivo value.yaml del gráfico principal para anular los valores del niño. También quiero usar ese mismo valor en la plantilla principal.

Para otras personas, si lo necesita
{{-if and value1 value2 }} tendrías que hacer esto entonces:

{{- if .Values.loki.enabled }}
{{- if index .Values "prometheus-operator" "grafana" "enabled" }}
{{- if index .Values "prometheus-operator" "grafana" "sidecar" "datasources" "enabled" }}

Tengo una pregunta ligeramente diferente. Tomemos un ejemplo aleatorio:
{{- if index .Values ​​"prometheus-operator" "grafana" "sidecar" "fuentes de datos" "habilitado"}}

Mi pregunta es si no sabemos "/ prometheus-operator" cómo me refiero a esta clave usando index. Básicamente, me gustaría obtener la primera clave de los .Values ​​(la clave es dinámica, no es constante en mi caso y, por lo tanto, cómo referir este mapa por clave en el índice. ¿Puede alguien hacérmelo saber?

Usé / "nithin-kumar" / para este problema es un problema de "-", probé los caracteres de escape

¿Alguien tiene una solución al usar toYaml?
Falla con
<toYaml>: wrong number of args for toYaml: want 1 got 5
con ou sin el uso de la función index .

cualquier corrección para U + 002D '-'

@ mods / mantenedores

¿Hay alguna actualización sobre esto?

¿Qué tipo de actualización?

Hola, este problema se abrió hace un tiempo, pero el problema persiste.

Las pautas de Helm Chart establecen que la tabla debe nombrarse con guiones (https://helm.sh/docs/chart_best_practices/conventions/)
Pero las plantillas nos hacen pasar un mal rato si intentamos poner guiones en values.yaml para reflejar los nombres de los gráficos, si intentamos usar esos valores de guiones como este:

{{ .Values.my-chart.name }}

Al leer la publicación anterior, parece que si todavía quiero usar guiones de esta manera, necesito usar index :

{{ index .Values "my-chart" "name" }}

Además de eso, las claves en values.yaml deben ser CamelCased (https://helm.sh/docs/chart_best_practices/values/).

No creo que la denominación de claves deba afectar a las plantillas de Helm.

¿Está previsto normalizar eso?

@bacongobbler , como si va a ser "arreglado", es decir, que podremos usar guiones sin recurrir a trucos y trucos, o si se trata de un "No se arreglará, se acostumbrará, se bifurcará o buscará algo más"

Es una limitación del idioma de la plantilla Go. Si desea un cambio, debe presentarlo en el proyecto Go: https://github.com/golang/go

Si / cuando lo solucionen, obtendremos soporte para ello.

En la forma típica de Google ("los usuarios suelen estar equivocados"), a esto se le ha dado un definitivo "No se arreglará, se acostumbrará, se bifurcará o se buscará otra cosa" https://github.com/golang/go/issues/ 23710. Creo que las razones dadas (que hablan específicamente sobre el caso de uso helm ) son perfectamente válidas, pero a los autores de go realmente no les importa.

https://github.com/golang/go/issues/23710#issuecomment -363488583 menciona dos soluciones: desalentar el uso de guiones (el enfoque actual) o "reescribir las canalizaciones de la plantilla [helm] para usar la función de índice automáticamente". Si bien reconozco que podría ser una empresa importante, ¿no sería posible tener un preprocesador de plantillas que pudiera hacer exactamente esto? ¿Quizás hay un gancho o algo que podría escribirse para preprocesar solo esto? Si bien obviamente es posible solucionar esto, parece un poco infantil por parte de los autores de go y vale la pena arreglarlo por helm .

Aunque reconozco que podría ser una empresa importante

Bingo.

Quiero decir, sería genial si pudiéramos hacer algunas mejoras en la calidad de vida en esta área, pero hay algunas áreas que tienen un poco más de prioridad en nuestras mentes en este momento (el apoyo de OCI se está moviendo a estable, por ejemplo). Y escribir un preprocesador es definitivamente una empresa importante.

Si estás interesado en contribuir, ¡no dudes en echar un vistazo!

Para mí, tener claridad sobre la situación es un gran primer paso. Tenemos lo siguiente:

• Es una restricción del idioma de la plantilla go
• Los autores go (actualmente) no tienen la helm deberían acostumbrarse o implementar un preprocesador de plantilla. No lo harán.
• Los autores de helm tienen muchas prioridades más altas que esto, ya que hay una solución relativamente fácil e implementar un preprocesador de plantilla es casi con certeza una tarea importante. También solo solucionaría un pequeño problema, dada la solución relativamente fácil, por lo que es probable que no llegue a la cima de la pila en un futuro cercano, si es que alguna vez lo hace.
• Cualquiera puede echar un vistazo y, con tiempo suficiente y go experiencia, ofrecer algo a helm (aparentemente, las personas go no están interesadas), aunque obviamente debería hacerlo ser relativamente elegante por la utilidad práctica limitada que aporta y la probable complejidad añadida.

Si todos piensan que eso es bastante exacto y justo, ¡dejaré de molestar a todos! :-)

Agregaría que cualquiera que quiera ver esto debería considerar escribir un HIP; consulte https://github.com/helm/community/blob/master/hips/hip-0001.md

De lo contrario si

"reescribir las canalizaciones de la plantilla [helm] para usar la función de índice automáticamente". Si bien reconozco que podría ser una empresa importante, ¿no sería posible tener un preprocesador de plantillas que pudiera hacer exactamente esto?

No me queda claro qué significa esto en realidad, ¿solo quiere decir que Helm debería convertir las claves en mayúsculas y minúsculas en claves en camello cuando construya su mapa de valores?

@prydonius , realmente no había empezado a pensar en ello a nivel de implementación. Los guiones son válidos como claves JSON, por lo que son claves YAML válidas, por lo que la suposición desde la perspectiva del usuario es que no hay razón para que no funcionen como claves en las plantillas helm . Debido a que las plantillas son plantillas go , esta suposición no se cumple. Parece que algunos (¿muchos?) Usuarios solo encuentran plantillas go en el contexto de helm , y encuentran esto bastante arbitrario y frustrante.

Supongo que un enfoque podría ser revisar y convertir valores a camel-case, luego revisar las plantillas y hacer lo mismo. Pero estoy de acuerdo en que la infraestructura para esto probablemente sea una carga mucho mayor de lo que valdría la pena. En realidad, una explicación de la barra lateral en los documentos de introducción que dice algo como:

Debido a que helm usa el lenguaje de plantillas go , no puede usar guiones - en claves directamente en las plantillas usando el mecanismo de referencia normal {{ .Values.mybasekey.my-key }} (esto no es válido). Esta es una restricción del lenguaje de plantillas go y algo que los autores go han negado a admitir. Si realmente desea usar guiones en sus claves, puede solucionar esta restricción usando la función index , así {{ index .Values.mybasekey "my-key" ]} . Debido a que esta solución es relativamente fácil, actualmente no hay planes para admitir el uso de guiones en los nombres de las claves sin index en helm . Los nombres de los subgráficos también serán claves en las plantillas, por lo que si usa un subgráfico con un guión en el nombre y desea anular un valor, deberá proporcionar un alias para el nombre del gráfico o utilizar la solución alternativa mencionada aquí ( {{ index .Values "my-chart" "name" }} ).

probablemente sería la mejor situación. Para mí, al menos, lo que encontré frustrante fue la falta de claridad sobre exactamente por qué no funcionó, dónde estaba el problema y quién podía / debería solucionarlo. La sección actual en la sección de mejores prácticas de gráficos es un poco engañosa. No es una buena práctica como tal no usarlos, en realidad se requieren soluciones para usarlos.

Sin embargo, no estoy seguro de dónde debería ir esa explicación, si es precisa.

+1 Estoy de acuerdo en que necesitamos decir esto en la documentación en alguna parte, como mínimo.

Definitivamente es confuso, pero no veo un camino para hacerlo más fácil en Helm. Cualquier ayudante de plantilla que agreguemos actuaría como una función de la misma manera que lo hace index (por ejemplo, el conjunto de funciones toYaml , toJson de Helm). La única forma que puedo ver de proporcionar un acceso más directo sería eliminar los guiones en las claves, pero como mencionó, es YAML / JSON válido y eso probablemente sería aún más confuso. En última instancia, el analizador de plantillas Go no lo admite y no hay mucho que podamos hacer al respecto sin bifurcarlo.

Aquí hay un ejemplo práctico de toYaml :
{{- toYaml Values.jobs.update-es.resources | nindent 12 }} = error

{{- toYaml (index .Values "jobs" "update-es" "resources") | nindent 12 }}