updated juju credentials on o7k isn't passed to cdk-addons

Bug #1939596 reported by Jeff Hillman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Openstack Integrator Charm
Fix Released
High
George Kraft

Bug Description

k8s 1.19
substrate = openstack ussuri on focal
charms = stable/latest

In a scenario where juju is bootstrapped into an environment, and a cluster is built with the above specifications using openstack-integrator, if that password for that openstack account expires and needs to be reset, juju has an `update-credentials` options to update both the client and controller. This is working as expected.

However, in the case of cdk-addons for openstack-cloud-conf, the new credentials aren't getting propagated to the occm pods. They are failing with a CrashLoopBackOff due to invalid credentials.

decoding the base64 for openstack-cloud-conf shows that the old o7k password is still present. `sudo snap get cdk-addons`.

Tags: cpe-onsite
Revision history for this message
Jeff Hillman (jhillman) wrote :

subscribed field-high. some customers will require rotating passwords for their security requirements.

George Kraft (cynerva)
Changed in cdk-addons:
importance: Undecided → High
George Kraft (cynerva)
no longer affects: cdk-addons
Changed in charm-openstack-integrator:
importance: Undecided → High
assignee: nobody → George Kraft (cynerva)
status: New → In Progress
Revision history for this message
George Kraft (cynerva) wrote :

The openstack-integrator charm isn't propagating the change to kubernetes-master. I've confirmed that, once openstack-integrator sends the new info, the change makes it all the way through to the openstack-cloud-controller-manager secret. If the pods are in CrashLoopBackOff then we shouldn't have any issues with pods using stale secret data, so, getting the secret updated should be sufficient.

Unfortunately, Juju doesn't notify the charm when cloud credentials have changed. We can check for changes in the update-status hook, but that could mean up to 5 minutes delay before the changes are propagated automatically. We can add a "refresh-credentials" action to allow the user to propagate the credentials more quickly, but that of course requires user action.

We'll have to do both, I think. Have the charm check in update-status so we get slow but automatic recovery. Add an action so users can recover more quickly if needed.

Revision history for this message
George Kraft (cynerva) wrote :
George Kraft (cynerva)
Changed in charm-openstack-integrator:
milestone: none → 1.22+ck1
Changed in charm-openstack-integrator:
status: In Progress → Fix Committed
Revision history for this message
George Kraft (cynerva) wrote :
George Kraft (cynerva)
Changed in charm-openstack-integrator:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.