Configs per step #1499
Draft
Configs per step #1499
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 5 commits
March 15, 2024 09:25
Values used in pkgis can be configured to apply to specific template steps of the pkg. The default behaviour stays the same, so that no specific step is defined for data values, they apply to the first one that takes values. Some implementation details: We classify the pkg's template steps, currently supported classes are ytt, helm, cue, and "valueable" which is either of the previously mentioned. When it is time to apply the data values' secrets to the template steps of the reulting app, we either find the template step that is explicitly configured, or we find the first one that takes data values (the first "valueable" step). This flips the the approach around: previously we iterated through all the pkg's template steps and applied the data values, if we have not. Now we iterate over the the data values from the pkgi and apply them to the appropriate template step. If the user configured data values for invalid steps (e.g. a step that does not exist, or a step that does not take any data values) we produce a human readable error and therefore block the reconciliation. Signed-off-by: Hannes Hörl <[email protected]>
This allows to control an app's individual template steps via annotations. It is modelled after the fetch annotations, considering the template step's index when pulling information from the app's annotations, e.g. `ext.packaging.carvel.dev/ytt-0-paths-from-secret-name`. The original annotations, without the index, are still used, for the first occurrence of the relevant template step class. The annotations are not as "strict" as the data values from the pkgi. E.g. when there is an annotation for a template step that either does not exist or is not of the desired class, it does not error, the annotation is just & silently ignored. After all, with annotations we don't have as strict of an API. Signed-off-by: Hannes Hörl <[email protected]>
Signed-off-by: Hannes Hörl <[email protected]>
Signed-off-by: Hannes Hörl <[email protected]>
Signed-off-by: Hannes Hörl <[email protected]>
hoegaarden
force-pushed
the
configs-per-step
branch
from
fda9325 to
4eed172
Compare
|
@hoegaarden Thank you so much for working on this and apologies for not being able to look into it. |
Sure. I'll try to wip up a PR for a proposal the next couple of days. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
This allows finer grained configurations of an
app's template steps from apkgi.valuesin apkgican be configured to be be attached to a specific template step in the resultingappapp's template step, through annotations on thepkgi, can be configured to apply to a specific templating stepWhich issue(s) this PR fixes:
Related issues / comments:
Does this PR introduce a user-facing change?
First off: the previous behavior regarding values and annotations should have kept the same, so this should be fully backwards compatible.
It introduces a couple of new and additional knobs:
pkgi.spec.values.templateStepsis an[]intpkgi.spec.values.templateSteps: [ 0 , 2 ]would attach this value secret as a value to the first and third template stepext.packaging.carvel.dev/helm-template-namewhich applies to the first helm template step,ext.packaging.carvel.dev/helm-0-template-namecan be used to explicitly target the first template stepNote: A user deploying a
pkgiwould still need to understand the implementation details of thepkg, i.e. which template steps it consists off, which values a certain step takes, ...Additional Notes for your reviewer:
Review Checklist:
a link to that PR
change
Additional documentation e.g., Proposal, usage docs, etc.:
Footnotes
ext.packaging.carvel.dev/helm-template-nameext.packaging.carvel.dev/helm-template-namespaceext.packaging.carvel.dev/ytt-paths-from-secret-nameext.packaging.carvel.dev/helm-template-values-from-secret-nameext.packaging.carvel.dev/ytt-data-values-overlays↩ext.packaging.carvel.dev/helm-%d-template-nameext.packaging.carvel.dev/helm-%d-template-namespaceext.packaging.carvel.dev/ytt-%d-paths-from-secret-nameext.packaging.carvel.dev/helm-%d-template-values-from-secret-nameext.packaging.carvel.dev/ytt-%d-data-values-overlays↩ext.packaging.carvel.dev/fetch-%d-secret-name↩