ZEP-0023: Zarf Named Configs #24
Conversation
Racer159
commented
Apr 1, 2025
Racer159
commented
- One-line PR description: Allow Zarf deploy-time configuration to be stored and referenced in a registry (i.e. is named / versioned)
- Issue link: Zarf Named Configs #23
- Other comments:
Signed-off-by: Wayne Starr <me@racer159.com>
Racer159
force-pushed
the
23-zarf-named-configs
branch
from
a3ca308 to
ee488b3
Compare
Signed-off-by: Wayne Starr <me@racer159.com>
Signed-off-by: Wayne Starr <me@racer159.com>
Signed-off-by: Wayne Starr <me@racer159.com>
Signed-off-by: Wayne Starr <me@racer159.com>
Signed-off-by: Wayne Starr <me@racer159.com>
|
|
||
| ### Non-Goals | ||
|
|
||
| - Provide configuration outside of the deployment of the package (i.e. geared towards the Ashton persona) |
There was a problem hiding this comment.
I've been using these names in proposals though not sure if there is an easy way for folks to get context on them in the project.
Ashton - Zarf Deployer
Jacquline - Zarf SRE
Ezra - Zarf Creator
Should these be removed or exist somewhere they can be discovered easily?
There was a problem hiding this comment.
Like @soltysh expressed elsewhere, I agree that we'll make the project more accessible to contributors by talking about users by what they want to achieve with the product rather than with project-specific jargon. "As a Zarf user, I want to do X with Y feature, so I can Z" remains user-focused without being opaque to someone without project-specific context.
There was a problem hiding this comment.
I'm all for switching to explicit role, rather than a name. For someone reading not being familiar with those personas it's hard to understand what they mean. Being explicit lowers the entry bar for contributors.
|
|
||
| ## Summary | ||
|
|
||
| This ZEP proposes to allow configuration specific to a Zarf package deployment to be named, versioned and published to a registry so that it can simplify the deployment experience for end users. |
|
|
||
| This ZEP proposes to allow configuration specific to a Zarf package deployment to be named, versioned and published to a registry so that it can simplify the deployment experience for end users. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
Clear and user-focused. Nice work
|
|
||
| ### Non-Goals | ||
|
|
||
| - Provide configuration outside of the deployment of the package (i.e. geared towards the Ashton persona) |
There was a problem hiding this comment.
Like @soltysh expressed elsewhere, I agree that we'll make the project more accessible to contributors by talking about users by what they want to achieve with the product rather than with project-specific jargon. "As a Zarf user, I want to do X with Y feature, so I can Z" remains user-focused without being opaque to someone without project-specific context.
| ### Non-Goals | ||
|
|
||
| - Provide configuration outside of the deployment of the package (i.e. geared towards the Ashton persona) | ||
| - Include security relevant deployment configuration in the registry (i.e. package signing keys) |
|
|
||
| #### Story 1 | ||
|
|
||
| **As** Jacquline **I want** to be able to pre-bake package configuration **so that** I can provide a more declarative package to Ashton. |
There was a problem hiding this comment.
Recommend making the user personae more generic per above. Focus on the specific workflow that user would want to achieve.
| zep-number: 0023 | ||
| authors: | ||
| - "@racer159" | ||
| status: implementable |
There was a problem hiding this comment.
Let's nudge this back to provisional until we converge on a few more implementation details. Ideally we can prove this out with an experimental branch first, but that's not necessary in all cases.
| **And When** I deploy that package | ||
| **Then** the chart will be in the `new-namespace` namespace. | ||
|
|
||
| To allow multiple configured packages to be created from one base package. This has the potential though to introduce Zarf package sprawl and could clog a registry with references to Zarf packages that are mostly the same. |
There was a problem hiding this comment.
Good callout and considerations for cache + disk storage and deduplication.
|
|
||
| ##### Unit tests | ||
|
|
||
| Unit tests would need to be added to ensure that the config was passed into the package deploy library interface correctly. |
There was a problem hiding this comment.
What kinds of validation can we run to ensure that the Named Configuration passed in is correct and complete?
| ## Design Details | ||
|
|
||
| <!-- This is negotiable and would like to hear others' thoughts on a local format for named configs vs having them be OCI-only --> | ||
| Named configs would be created and published through a set of new CLI commands (`zarf config create` and `zarf config publish`). This would pull together any referenced files or necessary artifacts and either create a local `tar.zst` or publish an OCI reference similar to a package. This config would then be referenced and applied during a package deployment. |
There was a problem hiding this comment.
I have some concerns about the scope creep here. In a perfect world, what would land in scope for MVP (minimum viable product) and an MLP (minimum lovable product) implementation?
There was a problem hiding this comment.
I'll add my two cents as well. I'm struggling to understand the usefulness of this approach. In most scenarios (gitops based) you have a script that is responsible for deploying your application, which means with ZEP-0021 you'll be able to keep the values file next to the script checked into the repository. So why the extra step to publish this to an OCI registry?
3 participants
