You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 22, 2026. It is now read-only.
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
It's not obvious to the casual contributor how the Constellation Node Operator module interacts with its Helm chart: some resources are duplicated, even with a slight mismatch sometimes, and changing the Kubernetes resources is in the best case toily, but in the worst case might lead to bugs (diff between make deploy vs. what ends up bundled in the CLI).
On a related note: the kubebuilder project version we're using does not seem to be supported anymore for current Kubernetes versions. A scary warning reads:
[Deprecation Notice] This version is deprecated.The `go/v3` cannot scaffold projects using kustomize versions v4x+ and cannot fully support Kubernetes 1.25+.It is recommended to upgrade your project to the latest versions available (go/v4).Please, check the migration guide to learn how to upgrade your project
This PR assumes that we want to keep compatibility with kubebuilder workflows (e.g. make deploy)! If we can drop this requirement, we would not need to migrate project versions and could remove a lot of things in the operators/constellation-node-operator directory.
This PR does not fix the discrepancies between kustomized resources in o/c/config/... and helmified resources in i/c/helm/...! (e.g. the csp value) This is fundamentally hard, because we have diffs on top of the initially generated Helm chart that we would need to backport to kustomize. I suggest to ignore this for now - the embedded code generation directives are imho much more error prone than resource patches in a directory clearly related to kubebuilder Makefiles, and we're fixing the former here. This problem would obviously go away if we were to drop support for kubebuilder dev workflows.
Proposed change(s)
Migrate kubebuilder project to go/v4 layout (guide)
Add Bazel autogeneration for the generate and manifests targets of the kubebuilder Makefile.
Reorganize the Constellation Helm chart to accommodate code generation (rename files, split RBAC into resources).
Directly generate RBAC and CRDs into the Helm chart.
This introduces a few cosmetic changes that should not alter behaviour of the chart.
This also introduces whitespace errors, but that should be fixed upstream.
The commits are suitable for individual review, which might also help understanding the logical relationships better.
Additional info
AB#3611 (unblocks removal of the kube-rbac-proxy by making changes to resources safe)
This problem would obviously go away if we were to drop support for kubebuilder dev workflows.
I do see your point regarding overhead for supporting the kubebuilder workflows. The added benefits are quite limited. Before we invest more costs into supporting it: What is your preferred resolution?
I would be fine with either solution. Maybe to add some more background to this: I originally added the skaffolding when I was inexperienced with writing operators. If we were to build a new operator today, we might skip this support entirely.
This problem would obviously go away if we were to drop support for kubebuilder dev workflows.
I do see your point regarding overhead for supporting the kubebuilder workflows. The added benefits are quite limited. Before we invest more costs into supporting it: What is your preferred resolution? I would be fine with either solution. Maybe to add some more background to this: I originally added the skaffolding when I was inexperienced with writing operators. If we were to build a new operator today, we might skip this support entirely.
What I think is valuable to keep are the CRD and RBAC permission workflows, which is part of the reason why I ported them to Bazel in the first place. I like the idea of stating the permissions you need right next to the location where you use them in code, and nobody should be hand-crafting any CRD yaml :) What I can definitely live without is the Makefile, the config dir etc - if nobody is using this for rapid feedback operator development, I'd say we're better off without that.
What I can definitely live without is the Makefile, the config dir etc - if nobody is using this for rapid feedback operator development, I'd say we're better off without that.
This commit adds the controller-gen tool as a Bazel dep and adds the
equivalent of `make manifests` to //:generate.
Rename CRDs in the operator Helm chart to match kubebuilder v4 generated
names and add a generation directive to output CRD resources directly
into the Helm chart. CRDs are not templated, so we don't need to helmify
them.
Split the manager-rbac.yaml into a role.yaml and a rolebinding.yaml, and
add a directive to generate role.yaml from operator sources. We're
losing the labels on the role, but that is only a cosmetic defect.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
no changelogChange won't be listed in release changelog
3 participants
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.
burgerdev
requested review from
derpsteb,
katexochen and
malt3
as code owners
Context
It's not obvious to the casual contributor how the Constellation Node Operator module interacts with its Helm chart: some resources are duplicated, even with a slight mismatch sometimes, and changing the Kubernetes resources is in the best case toily, but in the worst case might lead to bugs (diff between
make deployvs. what ends up bundled in the CLI).On a related note: the kubebuilder project version we're using does not seem to be supported anymore for current Kubernetes versions. A scary warning reads:
This PR assumes that we want to keep compatibility with kubebuilder workflows (e.g. make deploy)! If we can drop this requirement, we would not need to migrate project versions and could remove a lot of things in the
operators/constellation-node-operatordirectory.This PR does not fix the discrepancies between kustomized resources in
o/c/config/...and helmified resources ini/c/helm/...! (e.g. thecspvalue) This is fundamentally hard, because we have diffs on top of the initially generated Helm chart that we would need to backport to kustomize. I suggest to ignore this for now - the embedded code generation directives are imho much more error prone than resource patches in a directory clearly related to kubebuilder Makefiles, and we're fixing the former here. This problem would obviously go away if we were to drop support for kubebuilder dev workflows.Proposed change(s)
go/v4layout (guide)generateandmanifeststargets of the kubebuilderMakefile.The commits are suitable for individual review, which might also help understanding the logical relationships better.
Additional info
Checklist