Closed viccuad closed 2 years ago
Does all of that have to live inside of the root of the repository? Can we put that under a dedicated directory instead (like rancher-helm-chart
or something similar)?
Yeah, simpler, no need for readme and so. Repushed the branch that way.
Yeah, simpler, no need for readme and so. Repushed the branch that way.
Thanks, I think this reduces the clutter and also makes it easy to find all the files that have to be touched in order to update the rancher chart
I spent more time looking into this PR, I was thinking about the conversation we had about adding all these information into the metadata.yml
and then have a scaffold tool that generates these files. While doing that I came to some realizations.
Chart.yml
fileappVersion
key, this doesn't existing inside of this PR, I think it should be added. This must stay in sync with the version number of the policyversion
: this is going to be a different version number compared to the one of the policy. Meaning, it wouldn't make much sense to have that included into the metadata.yml
filequestions.yaml
filepolicy.yaml
and values.yaml
fileI think the current contents of the values.yaml
file should be moved into the policy.yaml
file. The policy.yaml
file should be a templated policy definition.
Things that should be templated are:
ClusterAdmissionPolicy
or AdmissionPolicy
. This is based on the answer provided by the usermutating
: non-mutating policies will have this value hard coded, not templated. Mutating policies will have that value templated, it will depend on the answer provided by the usersettings
: this should be composed using the answers provided by the userI wonder if it makes sense to have all this information stored into metadata.yml
file. Is it going to be worth the effort given how few parts of the file need to be changed across releases?
Also, is it possible to have a really generic scaffold that covers all the policies? What about the exceptions, how are we going to handle them... These are questions for the RFC probably
Superseded by https://github.com/kubewarden/helm-charts/pull/130/files.
Description
Relates to https://github.com/kubewarden/rfc/pull/12
The policy resource template is rendered completely from whatever Helm values are passed. This is done by consuming everything in
values.yaml
, and of course accepts--set
to overwrite, expand, or remove things that end in the template.Test
To create an
AdmissionPolicy
instead of the defaultClusterAdmissionPolicy
:helm template . --set kind="AdmissionPolicy"
To set the policy as non-mutating:
helm template . --set kind="AdmissionPolicy" --set mutating="false"
And so on.
Additional Information
Tradeoff
See RFC 10.