@ kfox1111 в этом случае будет достаточно просто использовать существующие значения диаграммы библиотеки с «родительским» ключом, который объединяется?

это тоже могло бы сработать, если бы не существовало диаграмм с «родительским» ключом. Не знаю, существуют ли такие.

Как насчет добавления ключевого слова --parent-values, которое может быть списком файлов yaml для объединения перед использованием собственных значений диаграммы. yaml.
В этом случае мы можем указать произвольное расположение файлов родительских значений, и эта последовательность будет также порядком приоритета. 1-й упомянутый файл будет переопределен вторым и т. д. Мысли?

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

Но идея со списком интересная. Если вы хотите быть явным, мы могли бы добавить его как флаг в требованиях?

Или иметь файл child_values.yaml в родительском элементе, в котором указано, какие дочерние значения следует извлекать?

Хотя может быть больше проблем, чем оно того стоит. Точно сказать не могу. мысли?

@ kfox1111 Я не вижу проблемы, когда используется переменная с этим списком, как мы делаем для common_vars, тогда пользователю просто нужно один раз тщательно настроить ее, а затем ссылаться на нее во всех последующих командах.

@sbezverk На мой взгляд, этот флаг был бы дополнительным дополнением к решению родительского ключа/parent_values, но я хотел бы, чтобы эта работа работала без параметров CLI, если это возможно. Мне подход с родительским ключом кажется наименее инвазивным, если он удовлетворит наши потребности и не разрушит существующие диаграммы.

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

@sbezverk Хорошо, это меня смутило, мы говорим об объединении дочерних значений с родительскими, что позволяет загружать диаграмму дочерней библиотеки с ее значениями и использовать родителем. О каком сценарии мы говорим?

@ jascott1 хорошо, я думал о другом направлении, используя родительские значения в дочерней диаграмме, а сценарий запускал дочернюю диаграмму. Я думаю, это другая тема тогда.. извиняюсь..

Для меня это то же самое, что сказать, что нам не нужен файл requirements.yaml и команда helm deps up, как вы могли бы:
cp -a ../../микросервис/foo диаграммы/; cp -a ../../микросервис/гистограммы;
пакет руля.

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

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

Другая возможность:

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

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

Итак, что насчет этого:
поддиаграмма получает каталог с именем parent_values/
С отдельными файлами, такими как: foo.yaml, bar.yaml.

Затем родительская диаграмма имеет список имен файлов дочерних диаграмм/значений, которые нужно включить?

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

• фу
• бар

если они используют оба. Эти перечисленные файлы загружаются по тому же алгоритму, описанному выше, вместо файла parent_values.yaml.

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

Идея заключалась бы в том, что диаграмма верхнего уровня могла бы в основном сказать «дополнить мой values.yaml значениями в /charts/foo, которые соответствуют шаблону foo.parent.* ».

Я очень не хочу позволять поддиаграммам изменять родительские диаграммы без «явного согласия» из-за возможности коллизий и непреднамеренных побочных эффектов. Итак, я пытаюсь придумать способ, с помощью которого родительская диаграмма благословила бы расширение области действия для определенных значений поддиаграммы.

@technosophos да, я думаю, что комментарий прямо над вашим может идти именно в этом направлении. Родительская диаграмма в своих зависимостях перечисляет, какие фрагменты дочерних значений она хочет включить.

Я не думал о подстановочных знаках, но это тоже может сработать.
Я думал что-то вроде:
родительский файл requirements.yaml:

dependencies:
  - name: kolla-common
    repository: http://localhost:10191
    version: 0.4.0-1
    include-values:  #<--- new section describing which chunks to pull in
      - common
      - svc

и kolla-common может иметь значения.yaml, например:

parent: # <--- new section where chunks named chunks are pulled out of.
  common:
     a: 1
     other:
        sometree: true
     b: 1
  svc:
     b: 2
  other:
     c: 3

поэтому результирующие значения в родительском элементе будут:

value_from_parent: 1
a: 1
other:
    sometree: true
b: 2

Что вы думаете об этой идее?

Мне не нравится идея подстановочных знаков, так как 1 это как бы заставляет называть 2, если по ошибке кто-то использует часть имени, которая находится в подстановочных знаках, некоторые значения могут случайно просочиться в диаграммы. Использование имени раздела включенных значений звучит как более надежный вариант.

В этой идее «фрагменты для извлечения» всегда являются корневыми ключами или нам нужны произвольные пути?

Я думаю, что одного уровня группировки, вероятно, достаточно, а пути, возможно, излишни?

Итак, родитель -> группа -> материал

где пользователь указывает группы для включения.

Должен ли ребенок явно разрешать экспорт, используя parent: в своих собственных значениях? Почему родитель не может использовать include-values: в файле requirements.yaml для выбора любого ключа у ребенка? Родитель может импортировать что-либо из дочернего без необходимости изменять дочерний элемент.

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

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

Далее возразил бы, что ребенок не всегда знает, что интересует родителя. Самое главное (imo) требование parent: означает, что для того, чтобы получить это из коробки, все сопровождающие диаграммы должны проделать работу, чтобы разрешить такое поведение. В конце концов, диаграмма локальна, и разработчик может изменять ее, но сопровождающий не имеет никакого контроля в этот момент, так зачем ограничивать и создавать больше работы вокруг? Кроме того, значения, вероятно, будут дублироваться, если мы не изменим значение на более exports: и не назовем ключи для экспорта.

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

Итак, вы думаете, что ребенку не нужны никакие изменения. все переменные просто указаны как обычно,
затем в родительском элементе вы выполняете импорт значений: со списком путей для включения, укорененных в пути?

так, как значения в дочернем:

foo:
  thing:
    bar: baz
    wark: tros
    things:
      - 1
      - 2
      - 3
other:
  stuff: 1

с отцом родителей:

include-values:
   - foo.thing

становится:

bar: baz
wark: tros
things:
  - 1
  - 2
  - 3

в родительском?

да. Я также подозреваю, что нам понадобится путь, как в вашем примере.

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

````

требования.yaml

значения импорта:
foo.thing: глобальная.foosystem

родительские значения

Глобальный:
фусистема:
бар: баз
Варк: Трос
вещи:
- 1
- 2
- 3

Последнее предложение имеет один недостаток, который я вижу.

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

руль показать значения некоторые диаграммы

#stuff include-value included from the child chart.
foo:
  bar: 1
#child charts settable values
childchartname:
  foo:
     bar: 1
  baz: #stuff provided by the lib chart but never used in the parent.
      wark: 2

Когда это делается с явной маркировкой с помощью глобальных переменных, это может вернуть что-то вроде:

#just values included from child
foo:
   bar: 1

Если дочерняя диаграмма не имеет определенных значений, кроме родительского раздела, она может полностью пропустить раздел «childchartname». или просто включите значения, которые не связаны с родителем.

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

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

Ничто не мешает кому-то/проекту следовать соглашению parent: . Я просто не думаю, что стоит этого требовать. Однако в моем последнем примере я не думаю, что у вас может быть . в ключе yaml?

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

Хотя я думаю, что это можно было бы добавить позже, не меняя API, так как один может быть списком строк, а другой - диктофоном. Таким образом, мы могли бы реализовать одно перед другим, если бы хотели поддерживать простую и расширенную версии.

Правда, я тоже думал об использовании обоих и был бы рад реализовать :)

да, я не думаю, что это может быть '.'

Это может быть решено, как это делает k8s,

import-values:
  - key: foo.thing
    value: global.foosystem

тогда ключ может быть '.' или ''

Может быть, уточните, что есть что?

````
значения импорта:

• ребенок: foo.thing
  родитель: global.foosystem
  ````
  или

````
значения импорта:

• источник: foo.thing
  место назначения: global.foosystem
  ````

и Т. Д.

@technosophos Как вы думаете, мы на правильном пути?

Хм, да. это выглядит лучше.

ребенок/родитель яснее, я думаю.

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

нет, мы просто интерпретируем простой список

````

• foo.thing
  ````

в виде

-child: foo.thing parent: foo.thing
правильно?

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

Самым чистым значением по умолчанию, о котором я могу думать, было бы:

include-values:
  - foo.thing 

по умолчанию может быть:

``ямл

• ребенок: global.foo.thing
  родитель: .

так . является корнем родителя?

Ага.

...
«По умолчанию значения импорта будут искать каждый путь YAML в списке и добавлять его содержимое в корень родительских значений»

Работает на меня.

В порядке. Ошибки. Если пути импорта не найдены, что делать? Я на заборе в данный момент.

вы имеете в виду болтающиеся значения импорта?

import-values:

или пустой список?

import-values: []

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

Точно. Если пользователь хочет импортировать значение, а оно не существует. Похоже на ошибку или предупреждение?

ах. Я мог пойти в любом случае.

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

Возможно, я установил соглашение в прошлом PR :) или, по крайней мере, следовал ему неосознанно. Но в тегах и условиях он должен был быть минимально инвазивным, поэтому он предупреждает только тогда, когда чего-то нет. У нас есть наш вариант использования, что бы вы хотели увидеть, если бы общая библиотека не загружалась правильно?

Просто мысль, но всегда можно ввести еще одно измерение с

-required-child:

Я предполагаю, что предупреждение, вероятно, хорошо. Может быть, мы пока просто остановимся на этом, а во время проверки кода другие смогут поэкспериментировать с этим. Не должно быть сложно переключиться, если люди чувствуют себя лучше по-другому.

Ребята, вы сегодня в ударе.

FWIW, вы можете включать точки в имена YAML, если цитируете имя:

"foo.bar": true

О, мы были так близки, подумал я :) Если это единственные обязательные ключевые кавычки в системе, получим ли мы электронное письмо с ненавистью?

вы можете включать точки в ключ, но я не думаю, что вы можете иметь только точку?

".": "foo"

@ jascott1 Я думаю, что мы иногда используем их для создания аннотаций, которые часто имеют расширение . в ключе. Но @kfox1111 может быть прав только насчет «.».

Есть ли случаи, когда мы хотели бы работать с ними, используя --set? Потому что в этом случае --set foo.\"bar.baz\"=zed вещи могут раздражать.

Я не уверен, что здесь будет использоваться много --set , кроме установки окончательных значений в родителях (а не дочерних/родительских путей из требований). Похоже, нам нужно идти с дочерними/родительскими ключами в списке.
Вот обновленный пример, основанный на нашем обсуждении:

Пример с простым списком
````

родительские значения

мифы: да

дочерние значения

фу:
вещь:
бар: правда
баз: ложь
разное:
- 1
- 2
- 3
````

````

требования.yaml (простой список)

...
значения импорта:

• foo.thing

````

````

родительские значения результата

мифы: да
бар: правда
баз: ложь
разное:
- 1
- 2
- 3
````

Пример с дочерним/родительским ключом

````

Требования (ребенок/родитель)

...
значения импорта:

• ребенок: foo.thing
  родитель: новый.ключ
  ````

````

значения результата

мифы: да
новый:
ключ:
бар: правда
баз: ложь
разное:
- 1
- 2
- 3
````

+1 дочерний/родительский ключевой подход, поскольку он обеспечивает лучшую видимость импортированных значений в родительских значениях.

@sbezverk мы обсуждаем поддержку как простого списка, так и дочернего/родительского. Вы против включения простого списка?

Да, точка в именах ключей будет использоваться только в файле зависимостей. Это не повлияет на --set или файлы пользовательских значений.

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

простой список - это просто «вот, просто возьмите все вещи». Я думаю, что это будет общий вариант использования, который мы найдем.

со всеми общими вещами в kolla-common, я бы предпочел:

import-values:
  - common
  - api-python-deployment
  - pv

или что-то в этом роде:

import-values:
  - child: parent.common
    parent: .
  - child: parent.api-python-deployment
    parent: .
  - child: parent.pv
    parent: .

Мы получим много вопросов типа "что делать" и почему родитель указан в дочернем.... :/

Я хотел бы отметить, что мы по-прежнему будем поддерживать

````
ребенок: parent.api-python-развертывание
родитель: .
`````
так что все еще будут эти вопросы :) но, по крайней мере, мы можем скрыть это, если захотим.

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

Прохладный. А что касается ошибок, то мы обходили предупреждение, когда путь импорта не существует в дочернем. Есть ли у кого-нибудь сильные чувства по поводу Warn vs Fail? Помимо этого, я думаю, если мы получим благословение, я смогу создать официальное предложение, а затем реализовать его.

@sbezverk с сокращением, мы можем просто взять все специфичные для пакета вещи из kolla-kubernetes all_values, а остальное взять и поместить в kolla-common/values.yaml под ключом 'parent'.

Затем в каждой диаграмме микросервисов мы вводим

include-values:
  - common
  - <list of other values that get included today with prebuild_microservices>

Затем должна быть возможность полностью избавиться от всей логики значений из предварительной сборки и заставить ее просто выполнять отсылки localpath, а затем она станет такой же, как сценарии сборки services/computekit.

Поскольку они оба являются списками, я думаю, что мы можем разрешить смешивание простых и дочерних/родительских форматов. Мысли?

@ kfox1111 это было бы здорово, еще один шаг к большему родному способу руля ..

@ jascott1 да, я думаю, это правда. микширование будет работать как строка, а другие - как слова.

Более того, если путь уже существует в родительском, кто выиграет слияние?

в порядке приоритета:
первая запись во включенных значениях получает самый низкий приоритет
вторая запись в include-values ​​получает следующий приоритет
.....
значения из родительской диаграммы получают следующий приоритет
значения, указанные пользователем, получают наивысший приоритет.

побеждает наивысший приоритет.

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

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

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

OK сводил все это к новому предложению по удобочитаемости https://github.com/kubernetes/helm/issues/1995.

@thomastaylor312 Я считаю, что мы можем закрыть это, поскольку предложение оформлено в # 1995 и уже реализовано.

Хорошо, спасибо, что указали на это, @jascott1!