Action resume failed: Couldn''t resume: Unit is not in sync

[Björn Tillenius]

I have a 3-unit percona cluster and after successfully pausing one of the units, it fails to resume:

  Action resume failed: Couldn''t resume: Unit is not in sync

This is using cs:trusty/percona-cluster-244.

A while after the action has failed, the unit does get synced, without any interaction on my side.

I guess either the action shouldn't fail, or it should wait until the unit is synced. I would prefer the latter.

[James Page (james-page)]

The resync operation is async to the start of the daemon, but yes I agree that the resume operation should wait for a reasonable amount of time for the unit to go from blocked->active as a result of the resync op.

[James Page (james-page)]

charm has a util for checking cluster state.

def cluster_in_sync():

we should plug this into the action.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/441136

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/441136
Committed: https://git.openstack.org/cgit/openstack/charm-percona-cluster/commit/?id=12af56c74693949d89d3e75526f156e34c2ee8f5
Submitter: Jenkins
Branch: master

commit 12af56c74693949d89d3e75526f156e34c2ee8f5
Author: James Page <email address hidden>
Date: Fri Mar 3 13:52:42 2017 +0000

    Recheck sync status when assessing status of unit

    After a resume operation, or after a boot following a prolonged
    period of downtime, it may take some time for the local unit
    to re-sync with its peers.

    Update the function that assesses local unit status to recheck
    sync status up to 10 times (with an increasing delay between
    recheck) before declaring that the unit is in a blocked state.

    Change-Id: Idaa960ade4c52c9ebba6c65a55bade6b22e90cdc
    Closes-Bug: 1626450