From ee488b394693ff64f2902db4130205ab49e9f095 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Tue, 1 Apr 2025 14:15:11 -0600 Subject: [PATCH 1/7] ZEP-0023: Zarf Named Configs Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 274 ++++++++++++++++++++++++++++++ 0023-zarf-named-configs/zep.yaml | 25 +++ 2 files changed, 299 insertions(+) create mode 100644 0023-zarf-named-configs/README.md create mode 100644 0023-zarf-named-configs/zep.yaml diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md new file mode 100644 index 0000000..2af923d --- /dev/null +++ b/0023-zarf-named-configs/README.md @@ -0,0 +1,274 @@ + + +# ZEP-0023: Zarf Named Configs + + + + + + +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [User Stories (Optional)](#user-stories-optional) + - [Story 1](#story-1) + - [Story 2](#story-2) + - [Risks and Mitigations](#risks-and-mitigations) +- [Design Details](#design-details) + - [Test Plan](#test-plan) + - [Prerequisite testing updates](#prerequisite-testing-updates) + - [Unit tests](#unit-tests) + - [e2e tests](#e2e-tests) + - [Graduation Criteria](#graduation-criteria) + - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy) + - [Version Skew Strategy](#version-skew-strategy) +- [Implementation History](#implementation-history) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) +- [Infrastructure Needed (Optional)](#infrastructure-needed-optional) + + +## Summary + + + +## Motivation + + + +### Goals + + + +### Non-Goals + + + +## Proposal + + + +### User Stories (Optional) + + + +#### Story 1 + +#### Story 2 + +### Risks and Mitigations + + + +## Design Details + + + +### Test Plan + + + +[ ] I/we understand the owners of the involved components may require updates to +existing tests to make this code solid enough prior to committing the changes necessary +to implement this proposal. + +### Graduation Criteria + + + +### Upgrade / Downgrade Strategy + + + +### Version Skew Strategy + + + +## Implementation History + + + +## Drawbacks + + + +## Alternatives + + + +## Infrastructure Needed (Optional) + + diff --git a/0023-zarf-named-configs/zep.yaml b/0023-zarf-named-configs/zep.yaml new file mode 100644 index 0000000..70bd9c3 --- /dev/null +++ b/0023-zarf-named-configs/zep.yaml @@ -0,0 +1,25 @@ +schema-version: 1.0.0 + +title: Zarf Named Configs +zep-number: 0023 +authors: + - "@racer159" +status: implementable +creation-date: 2025-04-01 +reviewers: + - "@zarf-dev" +approvers: + - "@zarf-dev" + +# The target maturity stage in the current dev cycle for this ZEP. +stage: alpha + +# The most recent milestone for which work toward delivery of this ZEP has been +# done. This can be the current (upcoming) milestone, if it is being actively +# worked on. +latest-milestone: "NA" + +# The milestone at which this feature was, or is targeted to be, at each stage. +milestone: + alpha: "NA" + stable: "v1.0" From 3a7ea1fee4e0f35aaf02378072cd4f217647e769 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Tue, 1 Apr 2025 17:18:41 -0600 Subject: [PATCH 2/7] port info from 0017 Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 175 +++++++++--------------------- 1 file changed, 49 insertions(+), 126 deletions(-) diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md index 2af923d..443d624 100644 --- a/0023-zarf-named-configs/README.md +++ b/0023-zarf-named-configs/README.md @@ -83,160 +83,93 @@ any additional information provided beyond the standard ZEP template. ## Summary - +This ZEP proposes to enable a namespace override for charts similar to the namespace override [functionality available in UDS CLI](https://uds.defenseunicorns.com/reference/bundles/overrides/#namespace). This would allow namespaces of charts within a Zarf package to be overridden so that multiples of the same Zarf package could be deployed to the same cluster under different namespaces (without needing to maintain variants of the same package). ## Motivation - +Doing this allows more flexibility with certain Zarf packages where you may want to have multiples of them installed in the cluster with slightly different configurations (such as [GitLab Runners](https://github.com/defenseunicorns/uds-package-gitlab-runner)). Right now the release namespace of any chart has to be hardcoded into the package and will be overwritten even if the chart allows namespace overrides for some manifests within the chart. The current behavior is also different from what Helm does by default which may not be what users of Zarf expect (Helm allows the use of the `namespace` flag on install to set the Chart's namespace without it needing to be baked into the Chart). ### Goals - +- Provide a way for an already created Zarf package containing Helm Charts to be easily installed more than once with different configurations ### Non-Goals - +- Move away from the declarative nature of Zarf packages ## Proposal - +The proposed solution is to introduce a new named override config to Zarf to allow for a managed way to provide overrides for namespaces and eventually different values. This allows for potential future override expansion while also forcing the overrides to be named and versioned to a package rather than be as fluid as an existing zarf-config file helping reduce declarative loss. These overrides could also eventually be signed as an artifact if desired. ### User Stories (Optional) - - #### Story 1 -#### Story 2 +**As** Jacquline **I want** to be able to set namespace overrides **so that** I can install the same package with different configurations in different namespaces. + +**Given** I have a Zarf Package with a chart named `my-chart` in a component named `my-component` +**And** I have a new ZarfOverrideConfig created from the following +```yaml +kind: ZarfOverrideConfig +metadata: + name: test-override + ref: oci://my-registry/test:0.1.0 + version: 0.1.0 + +overrides: + my-component: + my-chart: + namespace: new-namespace +``` +**When** I deploy that package with a `--override` like the below: +```yaml +zarf package deploy oci://my-registry/test:0.1.0 --override oci://my-registry/test-override:0.1.0 +``` +**Then** Zarf will change the chart's release namespace to `new-namespace` ### Risks and Mitigations - +TODO - (@WSTARR) ## Design Details - +TODO - (@WSTARR) - We need to discuss format if we co with named configs. Items of discussion: -### Test Plan - - +### Test Plan -[ ] I/we understand the owners of the involved components may require updates to +[X] I/we understand the owners of the involved components may require updates to existing tests to make this code solid enough prior to committing the changes necessary to implement this proposal. -### Graduation Criteria +##### Prerequisite testing updates - +TODO - (@WSTARR) + +### Graduation Criteria + +TODO - (@WSTARR) ### Upgrade / Downgrade Strategy - +NA - There would be no upgrade / downgrade of cluster installed components ### Version Skew Strategy - +NA - This proposal doesn't impact how Zarf's components interact ## Implementation History @@ -253,22 +186,12 @@ Major milestones might include: ## Drawbacks - +TODO - (@WSTARR) ## Alternatives - + ## Infrastructure Needed (Optional) - +NA - This change requires no additional infrastructure as it is internal to Zarf's operation. From 7b8a77b577fa4134f7c43a0fefa535d330004bae Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Thu, 3 Apr 2025 14:01:35 -0600 Subject: [PATCH 3/7] a bit more detail Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 20 +++++++++++--------- 0023-zarf-named-configs/zep.yaml | 4 ++++ 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md index 443d624..d0c59f1 100644 --- a/0023-zarf-named-configs/README.md +++ b/0023-zarf-named-configs/README.md @@ -83,34 +83,36 @@ any additional information provided beyond the standard ZEP template. ## Summary -This ZEP proposes to enable a namespace override for charts similar to the namespace override [functionality available in UDS CLI](https://uds.defenseunicorns.com/reference/bundles/overrides/#namespace). This would allow namespaces of charts within a Zarf package to be overridden so that multiples of the same Zarf package could be deployed to the same cluster under different namespaces (without needing to maintain variants of the same package). +This ZEP proposes to allow configuration specific to a Zarf package deployment to be able to be named, versioned and published to a registry so that it can simplify the deployment experience for end users. ## Motivation -Doing this allows more flexibility with certain Zarf packages where you may want to have multiples of them installed in the cluster with slightly different configurations (such as [GitLab Runners](https://github.com/defenseunicorns/uds-package-gitlab-runner)). Right now the release namespace of any chart has to be hardcoded into the package and will be overwritten even if the chart allows namespace overrides for some manifests within the chart. The current behavior is also different from what Helm does by default which may not be what users of Zarf expect (Helm allows the use of the `namespace` flag on install to set the Chart's namespace without it needing to be baked into the Chart). +This proposal comes from a desire to even further lower the barrier to entry for the deploy persona by pre-baking some deployment configuration for a Zarf package into named configurations that can be selected from. In some environments a user deploying a Zarf package may not have system administrator experience and an SRE may want to pre-configure the package for them to make the package even more declarative and easier to manage. Additionally many Zarf packages cross security domains and so might not be able to contain their related configuration inside the package at create time. Having a way to marry the package with the configuration within the deployment environment would help with this as well. ### Goals -- Provide a way for an already created Zarf package containing Helm Charts to be easily installed more than once with different configurations +- Provide a way for Zarf packages to reference pre-baked configurations during deployments +- Enhance the declarative design of Zarf ### Non-Goals -- Move away from the declarative nature of Zarf packages +- Provide configuration outside of the deployment of the package +- Include security relevant deployment configuration in the registry (i.e. package signing keys) ## Proposal -The proposed solution is to introduce a new named override config to Zarf to allow for a managed way to provide overrides for namespaces and eventually different values. This allows for potential future override expansion while also forcing the overrides to be named and versioned to a package rather than be as fluid as an existing zarf-config file helping reduce declarative loss. These overrides could also eventually be signed as an artifact if desired. +The proposed solution introduces a new named configuration type to Zarf to allow for a managed way to provide deployment configuration for a package. This would include most options that are available in a `zarf-config` file under `package.deploy` including the new options mentioned in [ZEP-0021](../0021-zarf-values/README.md) and [ZEP-0017](../0017-chart-namespace-overrides/README.md). This file would refer to a specific Zarf package name and version and itself would have a reference for itself. This would then be published in a registry and could be refered to on `zarf package deploy` or `zarf dev deploy`. ### User Stories (Optional) #### Story 1 -**As** Jacquline **I want** to be able to set namespace overrides **so that** I can install the same package with different configurations in different namespaces. +**As** Jacquline **I want** to be able to pre-bake package configuration **so that** I can provide a more declarative package to Ashton. **Given** I have a Zarf Package with a chart named `my-chart` in a component named `my-component` -**And** I have a new ZarfOverrideConfig created from the following +**And** I have a new ZarfNamedConfig created from the following ```yaml -kind: ZarfOverrideConfig +kind: ZarfNamedConfig metadata: name: test-override ref: oci://my-registry/test:0.1.0 @@ -190,7 +192,7 @@ TODO - (@WSTARR) ## Alternatives - +TODO - (@WSTARR) ## Infrastructure Needed (Optional) diff --git a/0023-zarf-named-configs/zep.yaml b/0023-zarf-named-configs/zep.yaml index 70bd9c3..9c305e1 100644 --- a/0023-zarf-named-configs/zep.yaml +++ b/0023-zarf-named-configs/zep.yaml @@ -11,6 +11,10 @@ reviewers: approvers: - "@zarf-dev" +see also: + - "/0021-zarf-values" + - "/0017-chart-namespace-overrides" + # The target maturity stage in the current dev cycle for this ZEP. stage: alpha From ce56960fa0b0164c9568dbbd57c7e041174518e0 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Thu, 3 Apr 2025 15:02:58 -0600 Subject: [PATCH 4/7] a little more Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 58 ++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 17 deletions(-) diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md index d0c59f1..7f7a2ee 100644 --- a/0023-zarf-named-configs/README.md +++ b/0023-zarf-named-configs/README.md @@ -109,8 +109,27 @@ The proposed solution introduces a new named configuration type to Zarf to allow **As** Jacquline **I want** to be able to pre-bake package configuration **so that** I can provide a more declarative package to Ashton. -**Given** I have a Zarf Package with a chart named `my-chart` in a component named `my-component` -**And** I have a new ZarfNamedConfig created from the following +**Given** I have a Zarf Package created from the below: +```yaml +metadata: + kind: ZarfPackageConfig + name: example + version: 0.1.0 + namespace: example + +variables: + - name: EXAMPLE + +values: + - values-default.yaml + +components: + - name: first + ... + - name: second + ... +``` +**And** I have a new ZarfNamedConfig published from the following ```yaml kind: ZarfNamedConfig metadata: @@ -118,30 +137,35 @@ metadata: ref: oci://my-registry/test:0.1.0 version: 0.1.0 -overrides: - my-component: - my-chart: - namespace: new-namespace +components: [ first ] + +namespace: new-namespace + +set: + EXAMPLE: example + +values: + - values-override.yaml + +adopt-existing-resources: true ``` -**When** I deploy that package with a `--override` like the below: -```yaml -zarf package deploy oci://my-registry/test:0.1.0 --override oci://my-registry/test-override:0.1.0 +**When** I deploy that package with a `--config` like the below: +```bash +zarf package deploy oci://my-registry/test:0.1.0 --config oci://my-registry/test-override:0.1.0 ``` -**Then** Zarf will change the chart's release namespace to `new-namespace` +**Then** Zarf will set the deploy options in accordance with the referenced config ### Risks and Mitigations -TODO - (@WSTARR) +This would make it easy to potentially accidentaly store secrets in the registry which is not desireable. We should add documentation about this and potentially prevent the storage of variables that are marked `sensitive` in named configs. ## Design Details TODO - (@WSTARR) - We need to discuss format if we co with named configs. Items of discussion: -1. How will named override configs reference the Zarf package they are attached to. -2. Would named override configs have a local format (or be OCI only) -3. How would publishing / pulling overrides work in practice - -This proposal will affect the release namespace of a chart (or manifest) so that the Helm release secrets and any templates that use the `.Release.Namespace` template would use the newly provided namespace. This would ensure that charts wouldn't affect the history or objects of prior deployments and would be able to properly install alongside one another. This would not affect namespaces that are defined under .Values as those would still be controlled by the package configuration and Zarf variables as they are today. +1. How will named configs reference the Zarf package they are attached to. +2. Would named configs have a local format (or be OCI only) +3. How would publishing / pulling named configs work in practice ### Test Plan @@ -171,7 +195,7 @@ NA - There would be no upgrade / downgrade of cluster installed components ### Version Skew Strategy -NA - This proposal doesn't impact how Zarf's components interact +NA - This proposal is an entirely new feature and does not impact existing behavior ## Implementation History From cfac732bf6783bbf3f05c538635cd77dd5bc9b89 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Thu, 3 Apr 2025 17:39:51 -0600 Subject: [PATCH 5/7] more deets Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 56 ++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 15 deletions(-) diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md index 7f7a2ee..a979ff8 100644 --- a/0023-zarf-named-configs/README.md +++ b/0023-zarf-named-configs/README.md @@ -83,7 +83,7 @@ any additional information provided beyond the standard ZEP template. ## Summary -This ZEP proposes to allow configuration specific to a Zarf package deployment to be able 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 @@ -129,11 +129,16 @@ components: - name: second ... ``` -**And** I have a new ZarfNamedConfig published from the following +**And** I have a new configuration published from the following ```yaml +# option 1 kind: ZarfNamedConfig +# option 2 +kind: ZarfDeployConfig +# option 3 +kind: ZarfConfig metadata: - name: test-override + name: test-config ref: oci://my-registry/test:0.1.0 version: 0.1.0 @@ -151,21 +156,18 @@ adopt-existing-resources: true ``` **When** I deploy that package with a `--config` like the below: ```bash -zarf package deploy oci://my-registry/test:0.1.0 --config oci://my-registry/test-override:0.1.0 +zarf package deploy oci://my-registry/test:0.1.0 --config oci://my-registry/test-config:0.1.0 ``` **Then** Zarf will set the deploy options in accordance with the referenced config ### Risks and Mitigations -This would make it easy to potentially accidentaly store secrets in the registry which is not desireable. We should add documentation about this and potentially prevent the storage of variables that are marked `sensitive` in named configs. +This would make it easy to potentially accidentally store secrets in the registry which is not desireable. We should add documentation about this and potentially prevent the storage of variables that are marked `sensitive` in named configs. ## Design Details -TODO - (@WSTARR) - We need to discuss format if we co with named configs. Items of discussion: - -1. How will named configs reference the Zarf package they are attached to. -2. Would named configs have a local format (or be OCI only) -3. How would publishing / pulling named configs work in practice + +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. ### Test Plan @@ -179,15 +181,15 @@ NA - This is a modification of existing behavior that should not require prerequ ##### Unit tests -TODO - (@WSTARR) +Unit tests would need to be added to ensure that the config was passed into the package deploy library interface correctly. ##### e2e tests -TODO - (@WSTARR) +Additional end to end tests would need to be added to ensure that the CLI flags and Viper config properly configured Zarf to use the published config. Config publishing from the CLI would also need to be tested. ### Graduation Criteria -TODO - (@WSTARR) +Pending review / community input these changes would be moved from alpha status and be marked as stable within Zarf's Package definition. This would be based on user adoption of the feature and confidence in its continued stability. ### Upgrade / Downgrade Strategy @@ -212,11 +214,35 @@ Major milestones might include: ## Drawbacks -TODO - (@WSTARR) +This is limited to only the package deployment options and does not allow for the full range of options that one may want to change in a Zarf package. This means that while an SRE can set configuration for a package they cannot override the package contents in any way and would need to contact the original package creator for assistance. ## Alternatives -TODO - (@WSTARR) +Similar to [ZEP-0017](../0017-chart-namespace-overrides/README.md) we could allow for Zarf package remixing: + +**Given** I have a Zarf Package with a chart named `my-chart` in a component named `my-component` +**And** I have a new ZarfRemixConfig created from the following +```yaml +kind: ZarfRemixConfig +metadata: + name: test-override + version: 0.1.0 + ref: oci://my-registry/test:0.1.0 + +remix: + my-component: + my-chart: + namespace: new-namespace +``` +**When** I create a new package from that with: +```bash +zarf package create zarf-remix.yaml +``` +**Then** Zarf will change the chart's release namespace to `new-namespace` in the new package +**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. ## Infrastructure Needed (Optional) From f888d83668ba1cb067d8978351151b7d49abdd56 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Thu, 3 Apr 2025 18:05:44 -0600 Subject: [PATCH 6/7] add more info Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md index a979ff8..35d0161 100644 --- a/0023-zarf-named-configs/README.md +++ b/0023-zarf-named-configs/README.md @@ -87,7 +87,7 @@ This ZEP proposes to allow configuration specific to a Zarf package deployment t ## Motivation -This proposal comes from a desire to even further lower the barrier to entry for the deploy persona by pre-baking some deployment configuration for a Zarf package into named configurations that can be selected from. In some environments a user deploying a Zarf package may not have system administrator experience and an SRE may want to pre-configure the package for them to make the package even more declarative and easier to manage. Additionally many Zarf packages cross security domains and so might not be able to contain their related configuration inside the package at create time. Having a way to marry the package with the configuration within the deployment environment would help with this as well. +This proposal comes from a desire to even further lower the barrier to entry for the deploy persona by pre-baking some deployment configuration for a Zarf package into named configurations that can be selected from. In some environments a user deploying a Zarf package may not have system administrator experience and an SRE may want to pre-configure the package for them to make the package even more declarative and easier to manage. Additionally many Zarf packages cross security domains and might not be able to contain their related configuration inside the package at create time. Having a way to marry the package with the configuration within the deployment environment would help with this as well. ### Goals @@ -101,7 +101,7 @@ This proposal comes from a desire to even further lower the barrier to entry for ## Proposal -The proposed solution introduces a new named configuration type to Zarf to allow for a managed way to provide deployment configuration for a package. This would include most options that are available in a `zarf-config` file under `package.deploy` including the new options mentioned in [ZEP-0021](../0021-zarf-values/README.md) and [ZEP-0017](../0017-chart-namespace-overrides/README.md). This file would refer to a specific Zarf package name and version and itself would have a reference for itself. This would then be published in a registry and could be refered to on `zarf package deploy` or `zarf dev deploy`. +The proposed solution introduces a new named configuration type to Zarf to allow for a managed way to provide deployment configuration for a package. This would include most options that are available in a `zarf-config` file under `package.deploy` including the new options mentioned in [ZEP-0021](../0021-zarf-values/README.md) and [ZEP-0017](../0017-chart-namespace-overrides/README.md). This file would be tied to a specific Zarf package name and version in addition to its own name and version. This configuration could then be published in a registry and/or be referenced on `zarf package deploy` or `zarf dev deploy`. ### User Stories (Optional) @@ -138,8 +138,11 @@ kind: ZarfDeployConfig # option 3 kind: ZarfConfig metadata: - name: test-config - ref: oci://my-registry/test:0.1.0 + name: example-config + version: 0.1.0 + +package: + name: example version: 0.1.0 components: [ first ] @@ -156,7 +159,7 @@ adopt-existing-resources: true ``` **When** I deploy that package with a `--config` like the below: ```bash -zarf package deploy oci://my-registry/test:0.1.0 --config oci://my-registry/test-config:0.1.0 +zarf package deploy oci://my-registry/example:0.1.0 --config oci://my-registry/example-config:0.1.0 ``` **Then** Zarf will set the deploy options in accordance with the referenced config @@ -167,7 +170,9 @@ This would make it easy to potentially accidentally store secrets in the registr ## Design Details -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. +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. + +Because package configurations refer to packages a `zarf config list oci:///` command would also be added that, for an OCI reference, would list the available named configs for that package. ### Test Plan From 2e730cf592b1a52d25f1b81e614db25aecaf4127 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Sat, 5 Apr 2025 13:53:48 -0600 Subject: [PATCH 7/7] more info Signed-off-by: Wayne Starr --- 0023-zarf-named-configs/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/0023-zarf-named-configs/README.md b/0023-zarf-named-configs/README.md index 35d0161..0d357bd 100644 --- a/0023-zarf-named-configs/README.md +++ b/0023-zarf-named-configs/README.md @@ -87,7 +87,7 @@ This ZEP proposes to allow configuration specific to a Zarf package deployment t ## Motivation -This proposal comes from a desire to even further lower the barrier to entry for the deploy persona by pre-baking some deployment configuration for a Zarf package into named configurations that can be selected from. In some environments a user deploying a Zarf package may not have system administrator experience and an SRE may want to pre-configure the package for them to make the package even more declarative and easier to manage. Additionally many Zarf packages cross security domains and might not be able to contain their related configuration inside the package at create time. Having a way to marry the package with the configuration within the deployment environment would help with this as well. +This proposal comes from a desire to even further lower the barrier to entry for the deploy persona by pre-baking some deployment configuration for a Zarf package into named configurations that can be selected from. In some environments a user deploying a Zarf package may not have system administrator experience and an SRE may want to pre-configure the package for them to make the package even more declarative and easier to manage. Additionally many Zarf packages cross security domains and might not be able to contain their related configuration inside the package at create time. Having a way to marry the package with the configuration within the deployment environment would help with this as well. Some packages also may have a set of configurations that could be selected from (i.e. `device1`, `device2`, `device3`) that would be useful to manage sets of similar but different deployments. ### Goals @@ -96,7 +96,7 @@ This proposal comes from a desire to even further lower the barrier to entry for ### Non-Goals -- Provide configuration outside of the deployment of the package +- 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) ## Proposal