Add application credential finalizer management

[Deydra71]

Jira: OSPRH-29269

Application Credential dev-doc: https://github.com/openstack-k8s-operators/dev-docs/blob/main/application_credentials.md

• Tracks the active AC secret name in Status.ApplicationCredentialSecret
• Add openstack.org/placementapi-ac-consumer finalizer to the AC secret after service config is rendered
• On AC rotation, move the finalizer from the old secret to the new one
• On CR deletion, remove the consumer finalizer from the AC secret before cleaning up the CR

This ensures that the keystone-operator cannot revoke a rotated AC secret while Placement is still consuming it.

2026-04-28T11:58:50Z	INFO	Controllers.PlacementAPI	Added consumer finalizer	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"placement","namespace":"openstack"}, "namespace": "openstack", "name": "placement", "reconcileID": "74813a11-99ba-4418-be48-594d27216bb5", "object": "ac-placement-323aa-secret", "finalizer": "openstack.org/placementapi-ac-consumer"}
2026-04-28T11:58:50Z	INFO	Controllers.PlacementAPI	Removed consumer finalizer	{"controller": "placementapi", "controllerGroup": "placement.openstack.org", "controllerKind": "PlacementAPI", "PlacementAPI": {"name":"placement","namespace":"openstack"}, "namespace": "openstack", "name": "placement", "reconcileID": "74813a11-99ba-4418-be48-594d27216bb5", "object": "ac-placement-6433f-secret", "finalizer": "openstack.org/placementapi-ac-consumer"}

Depends-On: openstack-k8s-operators/keystone-operator#685

Assisted-by: Claude Opus 4.6 noreply@anthropic.com

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Deydra71
Once this PR has been reviewed and has the lgtm label, please assign abays for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[amartyasinha]

@Deydra71 IIUC, circular dependency on openstack-operator is not here as pointed in nova-operator change. (both quote copied from nova-operator PR)

The plan:

keystone-operator's cleanupUnusedRotatedSecrets() will add a NodeSet
status check only for EDPM-consuming ACs (ac-nova, ac-ceilometer). Before
revoking an old Keystone AC or deleting its K8s Secret, it will list all
OpenStackDataPlaneNodeSet CRs and check AreAllNodesUpdated(). If any
NodeSet has pending node updates, revocation/deletion is skipped and retried
on the next reconcile.
Service operators are not allowed to depend on the OpenStackControlPlane or
OpenStackDataPlaneNodeSet CRs.

So this also breaks the architecture by creating a circular dependency between
the meta operator and the keystone operator. Service operators are not allowed to
read any input CRs reconsiled by the openstack operator like the node set cr.

Another thing, if agreed, placement-op code should also follow this recommended approach.

A better approach is to follow how the RabbitMQ rotation works
where the infra operator will remove the finalizer from the application
credential CR once the update of the EDPM nodes has been completed.

We just need to provide the reference to those in the config maps that we
generate so it has the names and can add and remove the finalizer
automatically.

Just to be sure, am I understanding this correctly?

[Deydra71]

Hi @amartyasinha !

The EDPM concern does not apply to placement. Placement is a ctlplane only service - it has no config rendered or deployed to EDPM dataplane nodes. There is no placement entry in the NodeSet's status.secretHashes, and no placement ansible service runs during EDPM deployments.

The EDPM tracking is only relevant for services whose AC secret data gets rendered into a config secret that is then deployed to dataplane nodes (only nova and ceilometer). For these services, there's a window between AC rotation on the controlplane and the next EDPM deploy where the old credential is still in use on the nodes. That's what the EDPM aware revocation prevents.

For ctlplane only services like placement, barbican, or cinder, etc the consumer finalizer , eg in placement openstack.org/placement-ac-consumer is sufficient. The service operator holds the finalizer on the AC secret it's actively using, and removes it once it picks up the new secret. Keystone-operator won't revoke/delete a secret that still has a consumer finalizer. No EDPM awareness needed.

Re the circular dependency concern: we changed our current approach in keystone-operator to use unstructured access to OpenStackDataPlaneNodeSet via lib-common/modules/edpm (no typed import of openstack-operator). This is the sijmilar pattern that infra-operator is going to use for RabbitMQ user deletion.

[amartyasinha]

Thanks @Deydra71 for explaining. Now it is clear to me. But seems like I haven't get clarity regarding the second quote.

A better approach is to follow how the RabbitMQ rotation works
where the infra operator will remove the finalizer from the application
credential CR once the update of the EDPM nodes has been completed.

We just need to provide the reference to those in the config maps that we
generate so it has the names and can add and remove the finalizer
automatically.

Is this the answer to the above concern? Just want to ensure I get the clear idea.

we changed our current approach in keystone-operator to use unstructured access to OpenStackDataPlaneNodeSet via openstack-k8s-operators/lib-common#692 (no typed import of openstack-operator). This is the sijmilar pattern that infra-operator is going to use for RabbitMQ user deletion.

[Deydra71]

@amartyasinha Yes, that's the answer to quoted concern, however we chose not to include any app cred logic in infra-operator, but keep it in keystone-operator openstack-k8s-operators/keystone-operator#685 using unstructured client.

[amartyasinha]

overall lgtm! maybe a couple of test cases should be added for failing cases. JFYI, placement-operator is planned to be merged into nova-operator. Once that merge is completed, this PR will be migrated in nova-operator, and then will be formally reviewed.

[Deydra71]

@amartyasinha additional env tests added. I will also need to remove the custom replace for keystone-operator from go.mod files, after the PR in keystone-operator is merged and bumped.

Thanks for review/comments!

[amartyasinha]

Thanks @Deydra71 for additional test cases. Yes, I ignored go.mod file as it was not a formal review for merge.

[Deydra71]

Thanks @Deydra71 for additional test cases. Yes, I ignored go.mod file as it was not a formal review for merge.

I also realized that Lints will be failing unless the replace directive is removed.

[amartyasinha]

Hey @Deydra71!
placement-operator repo no longer accepts changes to main branch, as its code is now maintained in nova-operator repo. Please open a PR in nova-operator repo for these changes and close this PR.

[Deydra71]

@amartyasinha Hi! Thanks for notifying me, I will do that today. A question - does this merge to nova-op affect openstack-operator? Specifically https://github.com/openstack-k8s-operators/openstack-operator/blob/main/internal/openstack/placement.go structure?

[amartyasinha]

Hey @Deydra71! All Placement APIs will work the way they used to earlier, the only difference is now they are managed through nova-operator. To answer your question, the file you've pointed has got only one single change, that is of referencing placement API import from nova-operator repo.

[Deydra71]

Closing as placement-op is fully included on nova-operator. New PR for placement app cred support is available --> openstack-k8s-operators/nova-operator#1120