1. 1. Summary

Changing applicationCredential.roles in OpenStackControlPlane CR does not update existing KeystoneApplicationCredential CRs, causing app creds to retain old roles

1. 1. Description

When `spec.applicationCredential.roles` is changed in the OpenStackControlPlane CR (e.g. from
`["service"]` to `["service", "admin"]`), the openstack-operator does not update the `roles`
field in existing KeystoneApplicationCredential CRs. The roles are only set when the AC CRs
are first created. This means existing app creds in Keystone retain the old roles even after
the controlplane CR is updated.

1. 1. 1. To Reproduce

1. Deploy RHOSO 18 with ZDPR enabled and `roles: ["service"]`
2. Verify app creds have roles: service
   ```bash
   oc get keystoneapplicationcredentials ac-nova -n openstack -o jsonpath='{.spec.roles}'
   # Output: ["service"]
   ```
3. Change the roles in the controlplane CR:
   ```bash
   oc patch openstackcontrolplane controlplane -n openstack --type=merge -p '{
     "spec": {"applicationCredential": {"roles": ["service", "admin"]}}
   }'
   ```
4. Wait for reconciliation
5. Check the AC CR:
   ```bash
   oc get keystoneapplicationcredentials ac-nova -n openstack -o jsonpath='{.spec.roles}'
   ```
6. See: `["service"]` (NOT updated to `["service", "admin"]`)

1. 1. 1. Expected behavior

The KeystoneApplicationCredential CRs should be updated with the new roles, and the
keystone-operator should rotate the app creds in Keystone with the updated roles.

1. 1. Bug Impact

Critical for ZDPR testing. With only the "service" role, Nova cannot perform cross-project
operations when communicating with Neutron. This caused 416 out of 883 Tempest test failures
with `NetworkNotFoundClient` errors - Nova could not find networks created by tempest users
in other projects.

The default roles in the CR are `["admin", "service"]`. If a user accidentally sets only
`["service"]`, there is no way to fix it through the controlplane CR - manual patching of
each AC CR is required.

1. 1. Known Workaround

Manually patch each KeystoneApplicationCredential CR:

```bash
for ac in $(oc get keystoneapplicationcredentials -n openstack -o name); do
  oc patch $ac -n openstack --type=merge -p '{"spec":{"roles":["service","admin"]}}'
done
```

The keystone-operator correctly detects the change in the AC CR, rotates the app cred in
Keystone, and creates a new one with the updated roles. Services then pick up the new
credentials automatically.

The following approaches do NOT work:

• Changing roles in the OpenStackControlPlane CR (not propagated to AC CRs)
• Deleting AC secrets (recreated from unchanged AC CR with old roles)
• Deleting app creds from Keystone (recreated from unchanged AC CR with old roles)
• Disabling and re-enabling applicationCredential globally (recreated with old roles)

1. 1. Additional Context

• openstack-operator PR #1430 (AppCred support) - roles are set on AC CR creation but never updated
• keystone-operator PR #567 (AppCred controller) - correctly handles role changes in AC CRs
• JIRA: OSPRH-21647
• Discovered during manual ZDPR testing on RHOSO 18, Feb 19, 2026