charm looks to have issues retrieving mysql and keystone relation data from multiple units
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
glance-sync-layer |
Won't Fix
|
Medium
|
Jose Guedez |
Bug Description
Attempted to deploy this in cloud with multiple keystone and mysql units. Deployed a glance-sync unit which initially failed to pick up relation data from keystone. Using "relation-get -r $relation_id - $keystone_unit", I found keystone/0 did not have the required service_XXX information for configuring novarc. keystone/1 and /2 did have this information. However, the charm was only looking at /0 data, so the unit was erroring out, complaining about no keystone entry in context dict when generating jinja template (for novarc).
After a redeploy of the unit, everything worked, and the charm was able to get the information. However, for another unit (the master in another environment), it was in active/ready state, but no mysql credential information existed in novarc. So looks like there was another problem in when the relation was passing information.
Also, this novarc file gets updated often due to flag logic, so making this process air tight is important.
Changed in charm-glance-sync: | |
status: | New → Triaged |
importance: | Undecided → Critical |
assignee: | nobody → Jose Guedez (jfguedez) |
Spent significant time attempting to reproduce this, and wasn't able to (5+ full master/slave deployments using 3 keystone and 3 mysql units). As there were suspicions of issues with the juju controller during the original issue, I also used the old version of juju involved at the time (v2.4.1), and novarc was rendered correctly for both keystone and mysql data in each case.
While the handling of the relation data can certainly be improved, I am reluctant about changing it without decent test coverage (see LP#1865051), given that it seems to be working at the moment.
Reducing severity and marking incomplete as it cannot be reproduced.