Skip to content

Add release-scoped RBAC and an overridable image tag - #383

Merged
fwiesel merged 3 commits into
mainfrom
pr-e2e-chart-support
Nov 4, 2026
Merged

fwiesel merged 3 commits into
mainfrom
pr-e2e-chart-support

Conversation

@fwiesel

@fwiesel fwiesel commented Nov 2, 2026 •

Copy link
Copy Markdown
Contributor

A second instance of a specific build may need to run next to the production release in the same cluster. Today it cannot:

  1. Both releases render the same cluster-scoped RBAC objects. The second install fails, and one uninstall can delete the objects of the other release. Therefore the ClusterRole/Binding names derive from the Helm release name. The generator emits that name via rbac:roleName, so make generate reproduces it.
  2. The manager image tag was fixed to Chart.AppVersion, so a specific build could not be deployed. image.tag now overrides it.

The production render is unchanged (fullnameOverride, no image.tag): ClusterRole hypervisor-operator-manager-role, image <repository>:<AppVersion>.

@fwiesel
fwiesel force-pushed the pr-e2e-chart-support branch from 212046d to 055e1a1 Compare November 2, 2026 08:36
@fwiesel fwiesel changed the title Chart: release-scoped RBAC and overridable image.tag for the PR e2e Add release-scoped RBAC and an overridable image tag Nov 2, 2026
@fwiesel
fwiesel force-pushed the pr-e2e-chart-support branch 6 times, most recently from 2f4a1d9 to fde2960 Compare November 2, 2026 09:14
@fwiesel
fwiesel marked this pull request as ready for review November 2, 2026 09:21

@notandy notandy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make generate                                                                                                                                                                                                                                                                                                                                                                                                >> controller-gen
../../api/v1/hypervisor_types.go:21:2: missing go.sum entry for module providing package k8s.io/apimachinery/pkg/api/resource (imported by github.com/cobaltcore-dev/openstack-hypervisor-operator/api/v1); to add:
	go get github.com/cobaltcore-dev/openstack-hypervisor-operator/api/v1@v0.0.0-00010101000000-000000000000
...

Error: not all generators ran successfully
run `controller-gen crd:allowDangerousTypes=true rbac:roleName="{{ include \"openstack-hypervisor-operator.fullname\" . }}-manager-role" webhook paths=./... output:crd:artifacts:config=charts/openstack-hypervisor-operator/crds output:rbac:artifacts:config=charts/openstack-hypervisor-operator/templates -w` to see all available markers, or `controller-gen crd:allowDangerousTypes=true rbac:roleName="{{ include \"openstack-hypervisor-operator.fullname\" . }}-manager-role" webhook paths=./... output:crd:artifacts:config=charts/openstack-hypervisor-operator/crds output:rbac:artifacts:config=charts/openstack-hypervisor-operator/templates -h` for usage
make: *** [Makefile:117: generate] Error 1

The Makefile installs controller-gen unpinned (@latest), so CI and
machines without a preinstalled controller-gen already run v0.23.0
and "make generate" dirties the committed CRDs. Regenerate them to
keep generation idempotent.

Signed-off-by: Fabian Wiesel <fabian.wiesel@sap.com>
A second instance may need to run next to the production release in
the same cluster. Today it cannot: both releases render the same
cluster-scoped RBAC objects. A shared object blocks the second
install, and one uninstall deletes it for both releases. The
generator emits the release-scoped name, so "make generate"
reproduces it. The production release renders the same name as
before.

Signed-off-by: Fabian Wiesel <fabian.wiesel@sap.com>
The chart pinned the manager image to Chart.AppVersion. A specific
build could not be deployed. The tag defaults to Chart.AppVersion,
so existing releases are unaffected.

Signed-off-by: Fabian Wiesel <fabian.wiesel@sap.com>
@fwiesel
fwiesel force-pushed the pr-e2e-chart-support branch from fde2960 to 719b2c7 Compare November 3, 2026 09:52
@fwiesel
fwiesel requested a review from notandy November 3, 2026 11:12
@fwiesel

fwiesel commented Nov 3, 2026

Copy link
Copy Markdown
Contributor Author

I tasked an LLM to reproduce it, because I can't do so on either this branch or main, with any controller-gen from v0.14 to v0.23. (Hence the rebase on a new controller version, as that was my first suspicion).

It says:

Your exact output does reproduce, but only when make generate runs two directories below the checkout root, in a directory holding a copy of the Makefile and a foreign go.mod with a local-directory replace on this repo. That matches all three fingerprints in your paste: the ../../api/v1/... prefix, the unprefixed Makefile:117, and the @v0.0.0-00010101000000-000000000000 pseudo-version in the suggested go get.

It points to the relative path in your error message ../../api/v1 vs ./api/v1.

@notandy notandy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh funny, yeah I had an benchmark project in the workdir that make was trying to compile, works now

@fwiesel
fwiesel merged commit 634df43 into main Nov 4, 2026
7 checks passed
@fwiesel
fwiesel deleted the pr-e2e-chart-support branch November 4, 2026 09:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants