password update shared-db relation does not fire nova_cell_api_relation_changed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Nova Cloud Controller Charm |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Short Description
=================
nova_cell_
Long description
============
Due to an issue with the mysql-percona charm.
We had to remove the units and redeploy the charm.
We then restored the database from backup.
During this time the shared db relation fired many times, however cell0 connection string did not update
https:/
Inspection of the log show no event, for the entire lifecycle of the mysql shared-db relation changed over 2 months.
grep "Cell registration data changed, triggering a remote restart" unit-nova-
ls -liah unit-nova-
98437571 -rw-r----- 1 syslog adm 96M Jun 11 16:01 unit-nova-
head -n 1 unit-nova-
2019-04-19 12:41:39 INFO juju.cmd supercommand.go:57 running jujud [2.5.4 gc go1.11.6]
tail -n 1 unit-nova-
2020-06-11 16:00:51 DEBUG juju-log 0 section(s) found
From the hooks file
===================
grep -ri "Cell registration data changed, triggering a remote restart" /var/lib/
/var/lib/
This led to heat being unable to delete stacks and other strange behaviors
in nova.log the following was observed
=======
2020-06-10 13:53:04.941 1112506 ERROR nova.context OperationalError: (pymysql.
2020-06-10 13:56:02.805 1112506 ERROR nova.context [req-496dac2f-
2020-06-10 13:56:02.805 1112506 ERROR nova.context OperationalError: (pymysql.
2020-06-10 13:57:04.996 1112506 ERROR nova.context [req-99cb2747-
Code in question
===================
@hooks.
def nova_cell_
data = hookenv.
ch_
if not data.get(
return
cell_updated = ncc_utils.
if cell_updated:
"Cell registration data changed, triggering a remote restart",
What we would like
==================
Should this fire on shared-db relation changed, and if so why did it not?
thank you
summary: |
- password uopdate shared-db relation does not fire + password update shared-db relation does not fire nova_cell_api_relation_changed |
tags: | added: scaleback |
Changed in charm-nova-cloud-controller: | |
milestone: | 20.08 → none |
Changed in charm-nova-cloud-controller: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Given the situation (adding/removing database units mixed with rolling back database contents), we would expect the adminsitrator to have to do manual intervention in order to recover operations.
However, we think there is a bug to fix here in less-turbulent scenarios, and we'll look further into that.