Open czeslavo opened 2 weeks ago
Another approach could be
Move KGO chart related code into KGO
repository. This would allow some parts of the mechanism to be automated, e.g. generating the manager role's policy rules and will resolve the chicken and egg problem that we have.
The chart would still be available to users from https://github.com/Kong/charts/: we'd introduce a mechanism for syncing the chart with https://github.com/Kong/charts/blob/gh-pages/index.yaml which is the source of truth for helm artifacts.
There are 2 challenges that I can see at this moment:
Problem Statement
Currently, a Helm chart for the operator (kong/gateway-operator) resides in a separate repository (kong/charts), a central place for our charts to live.
The tests verifying an upgrade procedure live in the KGO repository and rely on the Helm chart.
Testing our Helm chart with the
main
version of the operator comes with an issue - when adding new RBAC rules or CRDs, those have to be updated manually in the charts repo first and released. That makes the process of robust testing before the actual release cumbersome.This issue aims to find a solution that will make this process smoother, ticking as many as possible of the following boxes:
kong/gateway-operator
chart doesn't have to be released to test new RBACs and CRDs with the chart (that are not yet needed or handled by KGO)Proposed Solutions
Solution A - keep a separate branch in the charts repo
Maintain a
kgo/next
(or a specifickgo/vX.Y.Z
) branch in thekong/charts
repository where we'll stack all the changes needed for the next release (and merge it after a KGO release). Test against it in the KGO upgrade tests (could be done by cloning the charts repo and using it locally to avoid unnecessary releases polluting charts).Pros:
Cons:
Solution B - Make CRDs and RBACs templates conditionally render new content based on KGO versions
Similarly to KIC, introduce version-based conditionals in templates, adding RBAC rules and CRDs if they're satisfied. (Note: this potentially could be automated with a generator iterating over all KGO versions, assembling the output files with conditionals).
This approach would impose the following flow when adding new CRDs/RBACs to KGO and implementing a reconciler for them:
Pros:
Cons:
Acceptance Criteria