solicitud relacionada: #2566

He comenzado a trabajar en esto.
Teniendo en cuenta los comentarios sobre el n.º 2566, ¿estamos buscando --values ​​o --set (o ambos?)

Un buen caso de uso se describe en el problema que abrí (#3198), en el que me gustaría poder hacer:

helm package --version 1.2.3 --set image.tag 1.2.3

De esta forma, la versión del gráfico y la versión de la imagen de la ventana acoplable son la misma.

Acabo de completar el primer borrador y publiqué un PR para esto.

@ngeor , @sslavic , el PR que envié agrega las opciones --set y --values, ¿podría echarle un vistazo?

Hola @adshmh , se ve bien; desafortunadamente, no sé Go, pero veo que lo cubriste con los casos de prueba y todo, así que probablemente haga lo que dice :) ¡Gracias!

¿Cuándo estará disponible esta función? En 2.9.0 ?

3471 no cumplió con la fecha límite para 2.9, por lo que será en 2.10.

Volviendo a abrir esto, ya que el #3471 debe retirarse.

¿Qué le hace esto a los comentarios/etc en el paquete de archivo? por ejemplo, ¿son despojados o dejados solos o?

Actualmente estoy tratando de hacer lo mismo con yq pero simplemente arroja los valores finales después del procesamiento. es decir, todos los comentarios, líneas en blanco para la organización, etc. se han ido.

3471 eliminó todos los comentarios, por lo que necesitábamos revertir ese PR. Consulte https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783 para obtener más información.

Revertido de 2.10 "hazaña: agregue las opciones --set y --values ​​al 'paquete de timón'" https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

¿Alguna noticia sobre esto?
Gracias

Lo mismo que arriba; nadie ha trabajado en un seguimiento para corregir los errores en el n.º 3471, por lo que no se ha implementado. Es más que bienvenido a bifurcar Helm y compilar contra #3471 si está de acuerdo con que los comentarios se eliminen del archivo de valores.

¿Esto está hecho? Probé las versiones 2.11.0 y 2.12.0 ninguna de ellas parece tener helm package --set...

+1. realmente nos ayudará en CI para dejar de pasar y actualizar yamls de valores antes de empacar.

+1

--set-string también puede ser útil, ¿por qué no permitir todas las opciones de anulación que existen en la instalación/actualización?
Simplemente ejecute el mismo código utilizado para anular los valores para el comando del paquete, tiene sentido que el paquete tenga los valores de anulación; esos indicadores deben compartirse al igual que con la instalación/actualización.

2.13.1 tampoco tiene esa característica, ¿hay algún horario para ello?

Como se mencionó anteriormente, nadie está trabajando actualmente en esto y no hay un cronograma sobre cuándo estará disponible una solución. Siéntete libre de tomar este. Eche un vistazo a #3471 para obtener ideas.

implementado en Helm 3 . ¡Clausura!

Mirando el código, parece que #3471 llegó accidentalmente a Helm 3, pero nunca se retiró como hicimos con Helm 2 debido a este comentario: https://github.com/helm/helm/pull/3471#issuecomment -381779783

Estoy reabriendo esta solicitud de función ya que estamos eliminando las marcas --set y --values ​​en Helm 3 con https://github.com/helm/helm/pull/7201. De todos modos, nunca funcionaron... Todo lo establecido a través --set o --values nunca se inyectó en el paquete, e introdujo algunas regresiones fatales con helm package , es decir, el hecho de que eliminó extraiga los comentarios de values.yaml, que varios miembros de la comunidad utilizan como documentación.

Tal vez no lo entienda bien, pero felizmente he estado usando --set con el paquete para establecer valores y funcionó muy bien de 3.0.0 a 3.0.2, definitivamente no es un "no-op" como se describe en #7201.

Mis canalizaciones están rotas desde 3.0.3. Esto estaba funcionando en 3.0.2. ¿Por qué no se considera útil si tenemos --version y --app-version. ¿Cómo se supone que debemos editar la imagen y la etiqueta para que coincida con --app-version? golpe?

Mirando el código nuevamente, estás en lo correcto @lukaslarson y @maxhillaert. Sin embargo, esta era todavía una característica que se pretendía revertir, ya que eliminó todos los comentarios del archivo de valores del paquete. Se eliminó en Helm 2, pero accidentalmente llegó a Helm 3. Nunca tuvo la intención de enviarse.

Si alguien quiere volver a implementar el n.º 3471 que retiene los comentarios, estaremos encantados de ver las relaciones públicas.

@bacongobbler Esto nos rompió algunas cosas. Me interesaría trabajar en relaciones públicas, sin embargo, no parece trivial, así que me gustaría verificar el enfoque.

Parece que gopkg.in/yaml.v3 admite la retención de comentarios cuando se realiza un viaje de ida y vuelta. Mi propuesta sería hacer Values un yaml Node . Luego, al fusionar valores, recorra el árbol de salida analizada en lugar de mapas anidados. Esto es ciertamente menos ergonómico pero la mejor manera de preservar los comentarios.

Esto es un pequeño problema porque estamos usando sigs.k8s.io/yaml todas partes, que está anclado a v2 de la biblioteca subyacente. Como mínimo, esto requeriría introducirlo como una dependencia separada, lo cual es un poco asqueroso. No estoy seguro de cuál es el mejor enfoque aquí para evitar tocar todo lo que tiene que ver con yaml.

La mejor opción parece ser migrar a yaml.v3, por lo que parece que estás en el camino correcto.

Si desea comenzar a trabajar en una PoC/bifurcación de Helm que use yaml.v3 en lugar de sig.k8s.io/yaml, ese sería un buen camino a seguir. De esa manera podemos comenzar a evaluar su funcionalidad en comparación con lo que hay en master .

Una vez que hayamos establecido que yaml.v3 es el mejor camino a seguir, podemos averiguar cómo proceder desde el punto de vista del SDK.

¿Te ayuda eso a desbloquearte?

@jmcelwain ¿Estás trabajando activamente en esto? Con mucho gusto me haré cargo de esto si no.

@sreya92 Estaba ocupado en el trabajo. Aquí es donde lo dejé: cambiar a yaml.v3 fue mayormente fácil, con la excepción de esta parte aquí . No estaba seguro de cuál era el mejor enfoque para manejar esto sin ir tan lejos como vender la dependencia y actualizarla a v3 allí.

Parece que se hizo algo de trabajo para actualizar , pero no hay otra información en los problemas, etc., y no me molesté en abrir un problema. La otra opción sería simplemente mantener ambas dependencias, pero eso parece asqueroso.

Mi opinión personal sería que esto es un bloqueador para este problema, a menos que los mantenedores sientan que vale la pena llevar dos copias de librerías similares. No estoy seguro de cuál es el LoE aquí, pero probablemente deberíamos trabajar para obtener github.com/ghodss/yaml a v3 y actualizar también la versión del proveedor en k8s. Eso haría todo esto mucho más fácil.

Abrió https://github.com/ghodss/yaml/issues/61 para consultar sobre la posibilidad de una ruta de actualización allí. Esperaré a saber de ellos antes de continuar con cualquier otra cosa: la actualización de las dependencias es preferible a otras opciones, en mi opinión.

@jmcelwain No hay una gran cantidad de código en https://github.com/ghodss/yaml , hay solicitudes de extracción no atendidas de 2017: https://github.com/ghodss/yaml/pulls , y el código es MIT con licencia.

¿Esta dependencia realmente está tirando de su peso? Se trata de algunos ayudantes de clasificación, pero está logrando detener un problema que, una vez resuelto, podría mejorar la capacidad de muchos proyectos para establecer dinámicamente los valores predeterminados del paquete en el momento de la compilación (nuestro caso de uso es no tener que mantener múltiples lugares divergentes para almacenar etiquetas de versión algo así como --set image.tag=${GIT_TAG} para el gráfico paso a paso y las versiones de imagen para un proyecto).

¿Puedo sugerir que no esperemos más y simplemente copiemos el código necesario en helm (no me molestaría en venderlo, solo absorberlo y adaptarlo según sea necesario). Creo que es un proyecto lo suficientemente grande como para manejar el mantenimiento de este envoltorio y la ordenación de YAML es una competencia central (no digo que debas mantener tu propio analizador, ¡pero...!)

Dado que esto nos está causando dolor en este momento (y nos impide actualizar desde Helm 3.0.2), me encantaría intentarlo.

Preferiría evitar esa situación. No hay suficientes mantenedores para mantener un administrador de paquetes Y un analizador YAML. Eso introduciría una carga de mantenimiento significativa para el equipo.

@bacongobbler _no_ es un analizador yaml. Utiliza gopkg.in/yaml.v2 para realizar el análisis real. Se trata de 900 líneas de código contenedor reflect alrededor de ese analizador. El problema es que no usan gopkg.in/yaml.v3 que resolverían este problema.

Me parece que la carga de mantenimiento de usar este intermediario menor para su dependencia real es una carga mayor que mantener este fragmento de código.

Como se mencionó anteriormente en el hilo, no dude en proponer un PR aguas arriba que actualice ghodss/yaml a yaml.v3. Si no lo aceptan, siéntase libre de bifurcar el proyecto y mantenerlo si cree que puede asumir la carga de mantenimiento.

Sin embargo, permítanme ser claro: _no_ aceptaremos solicitudes de extracción que fork y ghodss/yaml del proveedor en Helm. No podemos asumir la carga de mantenimiento adicional de una biblioteca Go completa solo para admitir una función.

@bacongobbler , echa un vistazo a mi PR aquí: https://github.com/helm/helm/pull/7963

Son 900 líneas de código con las pruebas incluidas y la funcionalidad superflua eliminada.

En este momento, depende de lo que parece una biblioteca relativamente sin mantenimiento con una huella mucho más grande que la que he agregado allí.

una biblioteca completa de Go solo para admitir una característica

Utiliza una sola función de toda esta biblioteca de Go y, para hacerlo, se ha esforzado por crear una bifurcación permanente que oscurece aún más de dónde proviene el código.

siéntase libre de bifurcar el proyecto y mantenerlo si cree que puede asumir la carga de mantenimiento.

Quiero decir que ya ejecutas una bifurcación de un solo propósito de este código. Si el proyecto se abandona, en realidad no se está beneficiando de ningún mantenimiento del autor original.

Si lo desea, puedo tomar esa pequeña cantidad de código en mi PR y ponerlo en un repositorio y decir que lo mantendré (e intentaré hacerlo), pero parece bastante tonto.

Sin embargo, permítanme ser claro: no aceptaremos solicitudes de extracción que fork y ghodss/yaml del proveedor en Helm.

Para que conste, ya había impulsado las relaciones públicas cuando leí esto, así que espero que lo reconsidere porque creo que tiene un pensamiento en caché sobre 'vendedor' y 'toda la biblioteca de Go' (con lo que a menudo podría estar de acuerdo ) sin mirar el código involucrado. Pero analicemos el código real en cuestión en el PR. Estoy feliz de ser propietario de un código para este código si eso ayuda. Imaginemos que lo escribí como una contribución... Más o menos lo hice.

Tal vez lo fusionen: https://github.com/ghodss/yaml/pull/62

La otra alternativa que exploré brevemente fue la posibilidad de reemplazar la conversión de YAML a JSON a través de alguna otra dependencia o serializar a través de algún formato intermedio. No estoy lo suficientemente familiarizado con el ecosistema Go para saber si este es un camino viable. Me sorprendió un poco no poder encontrar más librerías de tipo serialización cuando miré brevemente.

Alguna idea de cuándo podemos tener el --set retrocedido mientras lo usamos para automatizar el empaquetado del timón. Estaba en Helm 3.0.2 y ahora ya no se admite la actualización.

Todavía estamos bloqueados para fusionar https://github.com/ghodss/yaml/pull/62 .

Mirando el código nuevamente, estás en lo correcto @lukaslarson y @maxhillaert. Sin embargo, esta era todavía una característica que se pretendía revertir, ya que eliminó todos los comentarios del archivo de valores del paquete. Se eliminó en Helm 2, pero accidentalmente llegó a Helm 3. Nunca tuvo la intención de enviarse.

Si alguien quiere volver a implementar el n.º 3471 que retiene los comentarios, estaremos encantados de ver las relaciones públicas.

¿Importa si se eliminan los comentarios? Si hay una advertencia de usar --set, no me importan los comentarios.

Todavía estamos bloqueados para fusionar ghodss/yaml#62 .

Supongo que estamos atascados con el uso de 3.0.2 :(

3471 eliminó los comentarios independientemente de si usó --set o no, por lo que rompió a los usuarios que nunca usaron esta función. Rompió la compatibilidad con versiones anteriores para todos. Por lo tanto, no se puede volver a introducir con una advertencia, y es por eso que estamos esperando una solución adecuada aguas arriba.

por eso tenemos que apegarnos a 3.0.2

Todavía estamos bloqueados para fusionar ghodss/yaml#62 .

Pero como parece que esta dependencia ya no se mantiene, tal vez sería mejor usar una versión bifurcada, ¿no?

Cambiar eso es una buena idea, pero debe posponerse a Helm 4. Alguien debería presentar un problema especial para cambiar los analizadores YAML para que podamos rastrear eso para el proceso de Helm 4.

Sin embargo, permítanme ser claro: no aceptaremos solicitudes de extracción que fork y ghodss/yaml del proveedor en Helm. No podemos asumir la carga de mantenimiento adicional de una biblioteca Go completa solo para admitir una función.

Dado que parece que https://github.com/ghodss/yaml ya no se mantiene, y no hay señales de vida en https://github.com/ghodss/yaml/pull/62 , ¿vale la pena reconsiderar esta posición? reevaluando https://github.com/helm/helm/pull/7963 ?

No estamos interesados ​​en asumir la carga de mantenimiento de admitir una biblioteca de análisis YAML completa solo para una función.

Insto a la comunidad a que considere trabajar con los mantenedores existentes de ghodss/yaml para encontrar un nuevo conjunto de mantenedores dispuestos a respaldar el proyecto, bifurcarlo o encontrar una nueva biblioteca que pueda conservar los comentarios.

Entonces, ¿qué sería?

• encontrar nuevos mantenedores para soportar ghodss/YAML!?
• ¡Encuentra a alguien que bifurque ghodss/YAML y use YAML.v3 (y continúe apoyándolo)!
• usar YAML.v3 directamente
• propone cambiar los analizadores YAML para helm 4

una biblioteca de análisis YAML completa

Esto tergiversa el alcance del código involucrado aquí. Son algunos envoltorios alrededor de otros analizadores.

No estamos interesados ​​en asumir la carga de mantenimiento de admitir una biblioteca de análisis YAML completa solo para una función.

Quizás esta confusión explique muchas cosas: el analizador es https://github.com/go-yaml/yaml , no ghodss/YAML. Desde https://github.com/ghodss/yaml :

Un envoltorio alrededor de go-yaml

Entonces, la solución simple es: simplemente deja de usar el envoltorio.

Los "envoltorios" tienen una profunda influencia en algunos de los comportamientos. Habiendo cambiado los analizadores (y las bibliotecas contenedoras) varias veces al principio del proyecto, los mantenedores principales son muy conscientes de las pequeñas discrepancias entre ellos y de cómo producen problemas de compatibilidad de alto nivel.

Existe la posibilidad de que consideremos usar una bifurcación de ghodss/yaml SI Y SÓLO SI los propietarios de esa bifurcación se comprometieron a continuar con el mantenimiento.

Tal vez pueda ser más preciso: deje de usar la biblioteca contenedora abandonada y realice el comportamiento de envoltura equivalente/idéntico en helm, que es lo que hace https://github.com/helm/helm/pull/7963 en aproximadamente ~ 250 LOC más pruebas

Sí, lo ideal sería que alguien lo arreglara en ghodss/yaml, pero ya no se mantiene. ¿Seguramente la alternativa no está esperando hasta Helm 4?

Creo que bifurcar es probablemente la mejor opción, en mi opinión; @ghodss no parece haber tenido ninguna actividad en GH desde principios de 2019, y el último compromiso con el repositorio fue hace un año y medio (por @bradfitz). La última (única) versión fue en 2017. Si hay problemas de seguridad latentes en el código, no se solucionarán en main.

Recomendaría encarecidamente adoptar una bifurcación si alguien está dispuesto a comprometerse a mantenerla; No veo ninguna desventaja en relación con continuar usando un paquete moribundo y abandonado. Estoy de acuerdo en que cambiar a un envoltorio diferente tiene más sentido como un cambio importante (parece un levantamiento lo suficientemente pesado como para que fácilmente sea algo de Helm 4, pero no voy a especular más), pero creo que esto podría resolverse. con una línea replace en go.mod .

Estoy dispuesto a comprometerme a ayudar a mantener un tenedor si alguien más también lo está; No tengo suficiente ancho de banda para hacerlo yo mismo en este momento, pero tengo suficiente para contribuir.

Es cierto que estoy más interesado en esto para poder deshacerme de mi montón de scripts de sed para empaquetar mis gráficos de Helm, pero si eso es lo que se necesita, que así sea.

Hola
Acabo de crear un complemento que permite establecer valores al empaquetar. por el momento solo soporta la bandera set (porque la necesitaba :sweat_smile: ) pero pretendo agregar otras banderas. no dude en impulsar las relaciones públicas si lo desea o agregar comentarios para mejorarlo.
Gracias

En caso de que alguien no haya estado siguiendo, ha habido algunos avances en ghodss/yaml#62 contactando a un mantenedor, ¡así que esperamos escuchar buenas noticias pronto!

Este problema se ha marcado como obsoleto porque ha estado abierto durante 90 días sin actividad. Este hilo se cerrará automáticamente en 30 días si no se produce más actividad.

Definitivamente no está rancio. He estado tratando de encontrar tiempo para hacer un seguimiento con https://github.com/ghodss/yaml/pull/62 y ver si podemos ayudar a fusionarlo para desbloquear el progreso en este problema. Dado que mi organización ha aumentado nuestra dependencia de Helm, seguimos queriendo poder generar valores en un gráfico empaquetado por compilación de CI.

Eliminé todos los comentarios que solicitaron una actualización de estado, ya que no agregan nada a la conversación en cuestión. @jmcelwain proporcionó una actualización de estado hace no menos de 5 días (gracias, por cierto) y es tan buena como cualquier otra. Como se mencionó anteriormente, la solución a este problema es complicada e implica actualizar o bifurcar varias dependencias, por lo que se requiere cierta diligencia debida.

Cuando tengamos más información para compartir, actualizaremos el hilo.

Como solución alternativa, he usado https://github.com/mikefarah/yq para actualizar mi gráfico de timón antes de empaquetar:

yq w -i values.yaml version $(Build.BuildNumber)

En nuestro CI creamos la imagen de la aplicación/docker y el gráfico en la misma canalización (para garantizar que la aplicación y el gráfico evolucionen juntos con el mismo control de versiones). Los valores predeterminados para el gráfico dependen de la versión de la imagen creada previamente.

La solución alternativa de yq se puede integrar fácilmente en una canalización, ¡pero parece extraño que este caso de uso no esté cubierto correctamente por helm!

Entonces, ¿no hay una forma integrada con helm para configurar image.tag durante/antes de la fase del paquete?

editar : encontré esta solución en mi caso, necesitamos usar Chart.AppVersion para la etiqueta de imagen porque empaquetamos el gráfico con el mismo control de versiones.

edición 2 : Chart.AppVersion / no funciona con gráfico compartido (exp un gráfico de arranque de resorte utilizado en múltiples gráficos paraguas)

mi conclusión : realmente necesito configurar image.tag durante la fase del paquete

¿Alguna noticia sobre esta función?