Conversation
The FRR path assembles an owner reference naming the singleton by hand. The credentials path is about to need the same one, so give it a name rather than a second copy.
The request carries no owner, so it outlives the configuration that asked for it: deleting the BGPCloudConfiguration leaves the request behind, and with it, on a cluster that mints, the cloud identity the cloud credential operator made to serve it. Name the configuration as the request's owner. It is cluster scoped, which is what lets it own an object in a namespace that is not its own -- the ban on crossing namespaces applies to namespaced owners. Reconciling also adopts a request that has no owner, so a cluster installed before this change is repaired rather than left as it was. blockOwnerDeletion stays unset. OpenShift enforces ownerReferencesPermissionEnforcement, which would otherwise require this operator to hold delete on bgpcloudconfigurations/finalizers.
The cleanup specs delete the configuration and check what should have gone with it. The request this operator makes of the cloud credential operator now belongs on that list: it is collected by the garbage collector rather than by any code here, so nothing short of a cluster can show that it works. An operator whose pod already holds credentials asks the cluster for none, and on such a run there is no object to own or collect. The specs say so on the way past rather than asserting nothing quietly, because an assertion that passes for want of an object reads exactly like one that passed on its merits.
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Owner
Author
|
Reopened against the openshift repository as openshift#143. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The
CredentialsRequestthis operator makes carries no owner, so it outlives the configuration that asked for it. Deleting theBGPCloudConfigurationleaves the request behind, and with it, on a cluster that mints, the cloud identity the cloud credential operator made to serve it. That is alebedev87's observation on openshift#122 (r4038418679), raised there as work for a dedicated PR.This is stacked on
azure-e2erather thanmainso it can fix both platforms at once:internal/platform/azure/credentials.godoes not exist onmainyet.Three commits:
The configuration is cluster scoped, which is what lets it own an object in
openshift-cloud-credential-operator: the ban on crossing namespaces applies to namespaced owners.blockOwnerDeletionis left unset deliberately -- OpenShift enforcesownerReferencesPermissionEnforcement, which would otherwise require this operator to holddeleteonbgpcloudconfigurations/finalizers.Worth stating plainly: an operator uninstall does not delete the
BGPCloudConfiguration, so an uninstall on its own still leaves the request behind. What this buys is that deleting the configuration collects it.The e2e assertion can only fire where the operator actually asked the cluster for credentials. A pod that already holds some -- the identity webhook's, or the profile on a desk running
make run-- never asks, so there is no object to own or collect; the specs say so on the way past rather than asserting nothing quietly.What it does on a cluster
Self-managed AWS,
credentialsMode: Manual, drivingaws.ResolveCredentialsagainst the live API server. Before:After, on the same cluster:
A request seeded by hand with no owner -- what an earlier release leaves -- is adopted on the next resolve and then collected with the configuration. Azure gives the same before and after on a live Azure cluster: survives 90s unowned, collected in 1.58s once owned.
The whole chain, in-cluster, through
Reconcilerather than a harness, running the packaged image:CCO served the request and the operator authenticated with what it wrote -- discovery came back
404 ResourceNotFoundfor a deliberately fabricated route server name, which only a working token reaches. Deleting the configuration took the request, and CCO's finalizer took the secret with it. That cluster is passthrough, so there is no minted identity to reclaim; the credential material CCO placed on the cluster is the closest thing it has, and it went.Test plan
make testandmake lintgreen.make deploy, driving the full reconcile, as above.