There was a typo in actions.yaml for the resume action that was breaking
builds. This change fixes that typo. The charm will build.
Closes-Bug: 2030677
Change-Id: I4501c3142620dc6bff87f554a9f26b39ac4c927d
1.) Currently multi-site can only be configured when system is being
deployed from scratch, migration works by renaming the existing
Zone/Zonegroups (Z/ZG) to Juju config values on primary site before
secondary site pulls the realm data and then rename and configure
secondary Zone accordingly.
During migration:
2.) If multiple Z/ZG not matching the config values are present at
primary site, the leader unit will block and prompt use of
'force-enable-multisite' which renames and configures selected Z/ZG
according to multisite config values.
3.) If the site being added as a secondary already contain Buckets,
the unit will block and prompt the operator to purge all such Buckets
before proceeding.
Closes-Bug: #1959837
Change-Id: I01a4c1c4551c797f0a32951dfbde8a1a4126c2d6
func-test-pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/840
Add new radosgw-multisite typed master and slave relations to
support configuration of separate ceph-radosgw deployments as
a single realm and zonegroup to support replication of data
between distinct RADOS gateway deployments.
This mandates the use of the realm, zonegroup and zone
configuration options of which realm and zonegroup must match
between instances of the ceph-radosgw application participating
in the master/slave relation.
The radosgw-multisite relation may be deployed as a model local
relation or as a cross-model relation.
Change-Id: I094f89b0f668e012482ca8aace1756c911b79d17
Closes-Bug: 1666880
Adds pause and resume unit to the charm such that the
charm stays paused during maintenance operations.
Change-Id: Iba0d39f9c5ca482a12fdb9f91d2890a715d3f8b7
Jadon Naas