связанный запрос: # 2566

Я начал работу над этим.
Учитывая комментарии к #2566, мы ищем --values ​​или --set (или оба?)

Хороший вариант использования описан в вопросе, который я открыл ( # 3198 ), в котором я хотел бы сделать:

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

Таким образом, версия диаграммы и версия образа докера являются одним и тем же.

Я только что закончил первый черновик и разместил для него PR.

@ngeor , @sslavic PR, который я отправил, добавляет опции --set и --values, не могли бы вы взглянуть?

Привет @adshmh , хорошо выглядит; к сожалению, я не знаю Go, но я вижу, что вы рассмотрели его с тестовыми примерами и всем остальным, так что, вероятно, он делает то, что говорит :) Спасибо!

Когда эта функция будет доступна? В 2.9.0?

3471 пропустил крайний срок для 2.9, поэтому он будет в 2.10.

Повторно открываю это, так как # 3471 необходимо отменить.

Что это делает с комментариями/и т. д. в архивном пакете? например, их раздевают или оставляют в покое или ??

В настоящее время я пытаюсь сделать то же самое с yq , но он просто сбрасывает окончательные значения после обработки. т.е. все комментарии, пустые строки для организации и т.д. исчезли.

3471 удалил все комментарии, поэтому нам нужно было отменить этот PR. См. https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783 для получения дополнительной информации.

Вернулось из версии 2.10 «подвиг: добавить параметры --set и --values ​​в пакет helm» https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a .

Есть новости об этом?
Спасибо

То же, что и выше; никто не работал над дальнейшим исправлением ошибок в #3471, поэтому это не было реализовано. Вы можете разветвить Helm и скомпилировать с #3471, если вы согласны с удалением комментариев из файла значений.

Это сделано? Пробовал на версиях 2.11.0 и 2.12.0 ни в одной из них вроде нет helm package --set...

+1. это действительно поможет нам в CI для остановки и обновления значений yamls перед упаковкой.

+1

--set-string также может быть полезен, почему бы не разрешить все параметры переопределения, которые существуют в установке/обновлении.
Просто выполните тот же код, который использовался для переопределения значений для команды package. Логично, что у пакета будут значения переопределения — эти флаги должны быть общими, как и при установке/обновлении.

2.13.1 тоже не имеет такой функции, есть ли расписание для нее?

Как упоминалось ранее, в настоящее время никто не работает над этим, и нет графика, когда будет доступно исправление. Не стесняйтесь взять это на себя. Взгляните на # 3471 для идей.

реализовано в Helm 3 . Закрытие!

Глядя на код, кажется, что # 3471 случайно попал в Helm 3, но так и не был извлечен, как мы сделали для Helm 2, из-за этого комментария: https://github.com/helm/helm/pull/3471#issuecomment -381779783

Я повторно открываю этот запрос функции, поскольку мы удаляем флаги --set и --values ​​в Helm 3 с помощью https://github.com/helm/helm/pull/7201. Они все равно никогда не работали... Все, что установлено через --set или --values , никогда не вводилось в пакет, и это приводило к некоторым фатальным регрессиям с helm package , а именно тот факт, что он разделил комментарии из values.yaml, которые несколько членов сообщества используют в качестве документации.

Может быть, я неправильно понимаю, но я с удовольствием использовал --set с пакетом для установки значений, и он отлично работал с 3.0.0 до 3.0.2, определенно не «без операции», как описано в # 7201 .

Мои пайплайны не работают с версии 3.0.3. Это работало в 3.0.2. Почему это не считается полезным, если у нас есть --version и --app-version. Как мы должны отредактировать изображение и тег, чтобы они соответствовали --app-version? Баш?

Еще раз взглянув на код, вы правы, @lukaslarson и @maxhillaert. Однако это все еще была функция, которую предполагалось вернуть, поскольку она удаляла все комментарии из файла значений пакета. Он был удален в Helm 2, но случайно попал в Helm 3. Он никогда не предназначался для отправки.

Если кто-то хочет поработать над повторной реализацией #3471, которая сохраняет комментарии, мы будем рады рассмотреть PR.

@bacongobbler Это сломало нам кое-что. Мне было бы интересно поработать над PR, однако это кажется нетривиальным, поэтому я хотел бы проверить подход.

Похоже, gopkg.in/yaml.v3 поддерживает сохранение комментариев при переходе туда и обратно. Мое предложение состояло бы в том, чтобы сделать Values yaml Node . Затем при объединении значений просматривайте дерево проанализированных выходных данных, а не вложенные карты. Это, конечно, менее эргономично, но лучший способ сохранить комментарии.

Это небольшая проблема, потому что мы везде используем sigs.k8s.io/yaml , которые привязаны к v2 базовой библиотеки. Как минимум, это потребует введения его в качестве отдельной зависимости, что довольно гадко. Не уверен, что здесь лучше всего не трогать все, что связано с yaml.

Лучшим вариантом выглядит переход на yaml.v3, так что, похоже, вы на правильном пути.

Если вы хотите начать работу над PoC/форком Helm, который использует yaml.v3 вместо sig.k8s.io/yaml, это будет хорошим шагом вперед. Таким образом, мы можем начать оценивать его функциональность по сравнению с тем, что есть в master .

После того, как мы установили, что yaml.v3 — лучший путь вперед, мы можем понять, как действовать с точки зрения SDK.

Это помогает разблокировать вас?

@jmcelwain Вы активно работаете над этим? Я с удовольствием возьмусь за это, если нет.

@sreya92 Занят на работе. На этом я и остановился: переход на yaml.v3 прошел в основном легко, за исключением вот этого бита . Не был уверен, как лучше всего справиться с этим, не заходя так далеко, как поставщик зависимости и обновляя ее до версии 3.

Похоже, что была проделана некоторая работа по обновлению , но другой информации в проблемах и т. д. нет, и я не удосужился открыть проблему. Другим вариантом было бы просто сохранить обе зависимости, но это кажется грубым.

Мое личное мнение состоит в том, что это блокирует эту проблему, если только сопровождающие не считают, что стоит носить с собой две копии похожих библиотек. Не уверен, что здесь LoE, но нам, вероятно, следует поработать над обновлением github.com/ghodss/yaml до версии 3, а также обновить вендорную версию в k8s. Это сделало бы все это намного проще.

Открыл https://github.com/ghodss/yaml/issues/61 , чтобы узнать о возможности пути обновления. Подожду ответа от них, прежде чем продолжать что-либо еще - обновление зависимостей намного предпочтительнее других вариантов IMO.

@jmcelwain В https://github.com/ghodss/yaml не так много кода, есть необслуживаемые запросы на вытягивание с 2017 года: https://github.com/ghodss/yaml/pulls , и код MIT лицензированный.

Действительно ли эта зависимость тянет на себя? Это несколько помощников по упорядочиванию, но им удается удерживать проблему, которая, когда она будет решена, может улучшить способность многих проектов динамически устанавливать значения пакетов по умолчанию во время сборки (наш вариант использования — не поддерживать несколько расходящихся места для хранения тегов версии что-то вроде --set image.tag=${GIT_TAG} для фиксированной версии диаграммы и изображения для проекта).

Могу ли я предложить, чтобы мы не ждали больше и просто скопировали нужный код в helm (я бы не стал его вендорить, просто впитывал и адаптировал по мере необходимости). Я думаю, что это достаточно большой проект, чтобы справиться с обслуживанием этой оболочки, и сортировка YAML является основной компетенцией (не говорю, что вы должны поддерживать свой собственный синтаксический анализатор, но...!)

Поскольку это причиняет нам боль прямо сейчас (и мешает нам обновиться с helm 3.0.2), я был бы рад попробовать.

Я бы предпочел избежать такой ситуации. Недостаточно сопровождающих для поддержки как менеджера пакетов, так и синтаксического анализатора YAML. Это создало бы значительную нагрузку на команду.

@bacongobbler это _не_ парсер yaml. Он использует gopkg.in/yaml.v2 для фактического синтаксического анализа. Около 900 строк кода-оболочки reflect вокруг этого синтаксического анализатора. Проблема в том, что они не используют gopkg.in/yaml.v3 , которые могли бы решить эту проблему.

Мне кажется, что бремя обслуживания, связанное с использованием этого незначительного промежуточного звена к вашей фактической зависимости, является большим бременем, чем поддержка этого фрагмента кода.

Как упоминалось ранее в этой ветке, пожалуйста, не стесняйтесь предлагать PR вверх по течению, который обновит ghodss/yaml до yaml.v3. Если они не примут это, не стесняйтесь разветвлять проект и поддерживать его, если вы чувствуете, что можете взять на себя бремя обслуживания.

Однако позвольте мне прояснить: мы _не будем_ принимать пулл-реквесты, которые разветвляются и вендоры ghodss/yaml входят в Helm. Мы не можем взять на себя дополнительное бремя обслуживания всей библиотеки Go только для поддержки одной функции.

@bacongobbler, пожалуйста, взгляните на мой PR здесь: https://github.com/helm/helm/pull/7963

Это 900 строк кода с включенными тестами и удаленным лишним функционалом.

Прямо сейчас вы зависите от того, что выглядит как относительно неподдерживаемая библиотека с гораздо большей площадью, чем то, что я туда добавил.

вся библиотека Go только для поддержки одной функции

Вы используете всю одну функцию из всей библиотеки Go, и для этого вы приложили усилия для создания постоянной вилки, которая еще больше скрывает, откуда берется код.

не стесняйтесь разветвлять проект и поддерживать его, если вы чувствуете, что можете взять на себя бремя обслуживания.

Я имею в виду, что вы уже запустили одноцелевой форк этого кода. Если проект заброшен, вы фактически не получаете никакой поддержки от первоначального автора.

Если вы хотите, я могу взять это небольшое количество кода в своем PR и поместить его в репозиторий и сказать, что буду поддерживать его (и я попытаюсь это сделать), но это выглядит довольно глупо.

Однако позвольте мне прояснить: мы не будем принимать пул-реквесты, которые форкают и вендора ghodss/yaml в Helm.

Для протокола: я уже протолкнул этот PR к тому времени, когда я прочитал это, поэтому я надеюсь, что вы пересмотрите свое мнение, потому что я думаю, что у вас есть кешированные мысли о «поставщике» и «всей библиотеке Go» (с чем я мог бы часто соглашаться ), не глядя на задействованный код. Но давайте обсудим фактически рассматриваемый код на PR. Я счастлив быть владельцем кода для этого кода, если это поможет. Давайте представим, что я написал это как вклад... Вроде так и сделал.

Возможно сольют: https://github.com/ghodss/yaml/pull/62

Другой альтернативой, которую я кратко рассмотрел, была возможность замены преобразования YAML в JSON с помощью какой-либо другой зависимости или сериализации через какой-либо промежуточный формат. Я недостаточно знаком с экосистемой Go, чтобы знать, является ли это жизнеспособным путем - я был несколько удивлен, что не смог найти больше библиотек типа сериализации, когда я бегло посмотрел.

Любая идея о том, когда мы можем вернуть --set обратно, поскольку мы используем его для автоматизации упаковки helm. Это было в Helm 3.0.2 и теперь, так как обновление больше не поддерживается.

Мы по-прежнему заблокированы при слиянии https://github.com/ghodss/yaml/pull/62 .

Еще раз взглянув на код, вы правы, @lukaslarson и @maxhillaert. Однако это все еще была функция, которую предполагалось вернуть, поскольку она удаляла все комментарии из файла значений пакета. Он был удален в Helm 2, но случайно попал в Helm 3. Он никогда не предназначался для отправки.

Если кто-то хочет поработать над повторной реализацией #3471, которая сохраняет комментарии, мы будем рады рассмотреть PR.

Имеет ли значение, удаляются ли комментарии? Если есть оговорка относительно использования --set, меня не интересуют комментарии.

Мы по-прежнему заблокированы при слиянии ghodss/yaml#62 .

Я думаю, мы застряли с использованием 3.0.2 :(

3471 удалял комментарии независимо от того, использовали вы --set или нет, так что это сломало пользователей, которые никогда не использовали эту функцию. Это нарушило обратную совместимость для всех. Поэтому он не может быть повторно представлен с оговоркой, и именно поэтому мы ждем надлежащего исправления выше по течению.

вот почему мы должны придерживаться 3.0.2

Мы по-прежнему заблокированы при слиянии ghodss/yaml#62 .

Но поскольку кажется, что эта зависимость больше не поддерживается, может быть, было бы лучше использовать разветвленную версию, не так ли?

Переключение это хорошая идея, но ее нужно отложить до Helm 4. Кто-то должен создать специальную проблему для переключения парсеров YAML, чтобы мы могли отследить это для процесса Helm 4.

Однако позвольте мне прояснить: мы не будем принимать пул-реквесты, которые форкают и вендора ghodss/yaml в Helm. Мы не можем взять на себя дополнительное бремя обслуживания всей библиотеки Go только для поддержки одной функции.

Учитывая, что https://github.com/ghodss/yaml больше не поддерживается, а на https://github.com/ghodss/yaml/pull/62 нет признаков жизни, стоит ли пересмотреть эту позицию, и переоценка https://github.com/helm/helm/pull/7963 ?

Мы не заинтересованы в том, чтобы брать на себя бремя поддержки всей библиотеки синтаксического анализа YAML только для одной функции.

Я бы призвал сообщество подумать о сотрудничестве с существующими сопровождающими ghodss/yaml, чтобы найти новый набор сопровождающих, желающих поддержать проект, разветвить проект или найти новую библиотеку, которая может сохранять комментарии.

Так что бы это было?

• найти новых сопровождающих для поддержки ghodss/YAML !?
• найдите кого-нибудь, кто разветвит ghodss/YAML и будет использовать YAML.v3 (и продолжать его поддерживать)!!
• использовать YAML.v3 напрямую
• предложить переключить парсеры YAML для helm 4

вся библиотека синтаксического анализа YAML

Это искажает объем используемого здесь кода. Это несколько оберток вокруг других парсеров.

Мы не заинтересованы в том, чтобы брать на себя бремя поддержки всей библиотеки синтаксического анализа YAML только для одной функции.

Возможно, эта путаница многое объясняет — парсер стоит https://github.com/go-yaml/yaml , а не ghodss/YAML. Из https://github.com/ghodss/yaml :

Обертка вокруг go-yaml

Итак, простое решение: просто перестаньте использовать обертку.

«Обертки» оказывают глубокое влияние на некоторые виды поведения. Несколько раз меняя синтаксические анализаторы (и библиотеки-оболочки) в начале проекта, основные сопровождающие хорошо осведомлены о небольших расхождениях между ними и о том, как они вызывают проблемы совместимости высокого уровня.

Существует вероятность того, что мы могли бы рассмотреть возможность использования форка ghodss/yaml ТОЛЬКО ЕСЛИ И ТОЛЬКО ЕСЛИ владельцы этого форка будут продолжать обслуживание.

Возможно, я могу быть более точным - прекратить использовать заброшенную библиотеку-обертку и выполнить эквивалентное/идентичное поведение обертки в helm, что делает https://github.com/helm/helm/pull/7963 примерно за ~ 250 LOC плюс. тесты.

Да, в идеале кто-нибудь поправил бы в ghodss/yaml, но он больше не поддерживается. Конечно, альтернатива не ждет до Helm 4?

Я думаю, что разветвление, вероятно, лучший вариант, ИМО; @ghodss , похоже, не проявлял никакой активности в GH с начала 2019 года, а последняя фиксация в репозитории была полтора года назад (автор @bradfitz). Последний (единственный) выпуск был в 2017 году. Если в коде есть какие-либо скрытые проблемы безопасности, они не будут исправлены на main.

Я бы настоятельно рекомендовал принять форк, если кто-то готов взять на себя обязательство поддерживать его; Я не вижу никаких недостатков в продолжении использования умирающего и заброшенного пакета. Я согласен с тем, что переход на другую оболочку имеет больше смысла в качестве серьезного изменения (кажется достаточно тяжелым, чтобы это могло легко быть вещью Helm 4, но я не собираюсь дальше строить догадки), но я думаю, что это можно решить со строкой replace в go.mod .

Я готов принять участие в поддержке форка, если это сделает кто-то другой; У меня недостаточно пропускной способности, чтобы сделать это самому прямо сейчас, но у меня есть достаточно, чтобы внести свой вклад.

По общему признанию, меня больше всего это интересует, чтобы я мог избавиться от своей кучи скриптов sed для упаковки моих диаграмм Helm, но если это то, что нужно, пусть будет так.

Привет
Я только что создал плагин , который позволяет устанавливать значения при упаковке. на данный момент он просто поддерживает флаг set (потому что мне это было нужно :sweat_smile: ), но я намерен добавить другие флаги. не стесняйтесь нажимать PR, если вам нравится, или добавлять замечания, чтобы улучшить его.
Спасибо

На всякий случай, если кто-то не следил за нами, ghodss/yaml#62 связался с сопровождающим, так что, надеюсь, скоро мы услышим хорошие новости!

Эта проблема была помечена как устаревшая, поскольку она была открыта в течение 90 дней без каких-либо действий. Эта тема будет автоматически закрыта через 30 дней, если в ней больше не будет активности.

Однозначно не просроченный. Я пытался найти время, чтобы связаться с https://github.com/ghodss/yaml/pull/62 и посмотреть, сможем ли мы помочь объединить его, чтобы разблокировать прогресс по этой проблеме. Поскольку моя организация увеличила нашу зависимость от Helm, мы по-прежнему хотим иметь возможность запекать значения в упакованную диаграмму сборки для каждого CI.

Я удалил все комментарии, которые просили обновить статус, поскольку они ничего не добавляют к текущему разговору. @jmcelwain предоставил обновление статуса не менее 5 дней назад (спасибо, кстати) и так же хорош, как и все. Как упоминалось ранее, решение этой проблемы сложное и включает в себя обновление или разветвление нескольких зависимостей, поэтому требуется определенная осмотрительность.

Когда у нас будет больше информации для обмена, мы обновим ветку.

В качестве обходного пути я использовал https://github.com/mikefarah/yq , чтобы обновить свою диаграмму руля перед упаковкой:

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

В нашем CI мы создаем образ приложения/докера и диаграмму в одном и том же конвейере (чтобы приложение и диаграмма развивались вместе с одной и той же версией). Значения по умолчанию для диаграммы зависят от ранее созданной версии образа.

Обходной путь yq можно легко интегрировать в конвейер, но кажется странным, что этот вариант использования не охватывается helm должным образом!

Таким образом, они не являются интегрированным способом установки image.tag с помощью helm во время или перед фазой пакета?

редактировать : нашел это решение в моем случае, нам нужно использовать Chart.AppVersion для тега изображения, потому что мы упаковываем диаграмму с той же версией.

изменить 2 : Chart.AppVersion / не работать с общей диаграммой (например, диаграмма весенней загрузки, используемая в нескольких зонтичных диаграммах)

мой вывод : действительно нужно установить image.tag на этапе пакета

Есть новости об этой функции?