Accept Data Values as a plain YAML file

[pivotaljohn]

Per ytt-002 Data Values as Plain YAML proposal.

This feature serves two primary classes of users:

As an Integrator
I want to be able to present my users with a simple YAML-based configuration interface, devoid of any ytt adornments (e.g. annotations, Starlark code, etC)
So that my users need not know I've integrated with ytt nor learn any of its syntax
And I don't have to do anything special to make that integration "just work" (e.g. prepending a file with @data/values or scan/filter for code when I don't want to provide the option for it, etc)

As a Configuration Consumer
I want to pick up and use someone's ytt library, including providing my own configuration values (apparently called "Data Values") in a simple YAML format
So that I don't have to learn ytt syntax or learn advanced ytt features

In short:

Add a flag to ytt — --data-values-file that accepts only plain YAML (i.e. with no ytt directives).

Stories:

• Accept DVs in a single plain YAML file/document as the only source of Data Values #376
• Accept DVs in multiple *congruent* plain YAML files/documents that merge into the only source of Data Values #377
• Accept DVs from a plain YAML file in a root library containing Data Values Overlays #378
• Accept DVs from a plain YAML file targeting a private library #379
• Reject Data Values Overlays when supplied as a Data Values File #380
• Accept DVs in multiple *incongruent* plain YAML files/documents that merge into the only source of Data Values #387

[pivotaljohn]

@cppforlife please review the connected stories for acceptance criteria around documentation.

[james-pollard-leapyear]

Hey y'all,

I'm trying to track what came in with the latest release and I'm having trouble following how #398 implements this proposal, while there are still the 6 unclosed referenced in the description for this issue.

Some clarification would be greatly appreciated!

[pivotaljohn]

The feature is implemented and included as a "pre-release" in v0.34.0. However, these stories have unmet acceptance criteria around updating documentation. Once that work is done, we can consider the feature released.

We didn't make that clear in the release notes. Sorry for the ambiguity.

The ytt fanatic will note that there's scope identified in the proposal required to push this more user-friendly approach to supplying Data Values to the fore-front. That scope is about properly adjusting documentation and supporting this new flag as the primary way to supply Data Values (e.g. Playground doesn't support setting flags).

In the meantime, this feature is, in fact, ready for use.

[james-pollard-leapyear]

The feature is implemented and included as a "pre-release" in v0.34.0. However, these stories have unmet acceptance criteria around updating documentation. Once that work is done, we can consider the feature released.

We didn't make that clear in the release notes. Sorry for the ambiguity.

The ytt fanatic will note that there's scope identified in the proposal required to push this more user-friendly approach to supplying Data Values to the fore-front. That scope is about properly adjusting documentation and supporting this new flag as the primary way to supply Data Values (e.g. Playground doesn't support setting flags).

In the meantime, this feature is, in fact, ready for use.

Gotcha - thanks for the wonderful explanation, as always 😁 👋🏽

[jessehu]

Hi @pivotaljohn does it mean -f only accepts a yaml with #@data/values , and --data-values-file only accepts a plain yaml without #@data/values? Is it possible --data-values-file also support #@data/values by removing #@data/values when reading the data values yaml file? I'm wondering if there could be any breaking changes when upgrading/migrating from the old way -f to new way --data-values-file.

[pivotaljohn]

Hey @jessehu. It might help to think of this less as "the new way" and more as "another way" at this point.

ytt will continue to support accepting Data Values Overlays (i.e. documents annotated with @data/values). It's just that it now also has an API for supplying raw YAML for Data Values.

With this context, there will be no breaking change. Just another option.

That said, the hope is to make this more straightforward approach the default choice. But there's work to do to get there: https://github.com/vmware-tanzu/carvel-community/tree/develop/proposals/ytt/002-raw-data-values#consideration-implies-a-significant-effort-to-implement

Does that address your concern?