Designate service permanently broken after relation removal

Bug #1803397 reported by Jay Kuri
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Designate Charm
Confirmed
Medium
Unassigned

Bug Description

Summary:

Removing the relation between designate:shared-db and mysql:shared-db causes designate to be permanently unable to re-attach to the database. Re-adding the relation after it's been removed is only partly successful, and while the relation is shown as existing, the database is never set up again, and the status gets stuck at 'Blocked: shared-db incomplete'

What I did:

On an existing environment, I removed the designate - mysql relation (because it was not working) and re-added it.

What I expected:

I expected after the relation establishment process was finished, we would have a working relation and designate would be able to talk to its database.

What happened instead:

The relation process on the designate side failed to fully complete and stuck at 'Blocked: shared-db incomplete'

What appears to be the cause:

When the relation was removed, two reactive states remained: db.synched and shared-db.setup

The code in the charm seems to guard the setup based on whether shared-db.setup is not set. This means that in this scenario, it can't run the setup.

It appears that when the relation is removed, the db.synched and shared-db.setup flags should be removed.

Workaround:

After the removal of the relation I manually cleared the two flags on each unit:

juju run --unit designate/0 'charms.reactive clear_flag db.synched'
juju run --unit designate/0 'charms.reactive clear_flag shared-db.setup'

Then, after a moment or two, I re-added the designate:shared-db mysql:shared-db relation and the process was able to complete and created the designate database as expected.

Revision history for this message
Jay Kuri (jk0ne) wrote :

Also - it appears when the relation is removed, the database is not removed from the mysql server (though I'm not 100% sure if that is designate's job, or mysql's job)

Revision history for this message
Drew Freiberger (afreiberger) wrote :

I think deletion of the DB would be put to mysql, but kind of a dangerous methodology to delete upon relation-departed, especially if you lose track of how many relations you still have left, etc, or expect to remove nova-compute and add nova-compute-myflavor while maintaining the nova db intact.

Revision history for this message
Paul Goins (vultaire) wrote :

I just hit this on a customer cloud. I see the fix in #1800730, however it doesn't appear to do anything regarding the shared-db.setup flag for designate. Thus, I don't think this is a duplicate, I think it's its own issue.

Changed in charm-designate:
importance: Undecided → Medium
status: New → Confirmed
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.