Bug 1423886 - In a multisite env, realm rename does not get updated to other zones
Summary: In a multisite env, realm rename does not get updated to other zones
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: RGW
Version: 2.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 2.3
Assignee: Casey Bodley
QA Contact: Tejas
Erin Donnelly
Depends On:
Blocks: 1412948 1437916
TreeView+ depends on / blocked
Reported: 2017-02-17 15:06 UTC by shilpa
Modified: 2017-07-30 15:40 UTC (History)
10 users (show)

Fixed In Version: RHEL: ceph-10.2.7-12.el7cp Ubuntu: ceph_10.2.7-14redhat1xenial
Doc Type: Bug Fix
Doc Text:
.The output of the `radosgw-admin realm rename` command now alerts the administrator to run the command separately on each of the realm's clusters In a multi-site configuration, the name of a realm is only stored locally and is not shared as part of the period. As a consequence, when it is changed on one cluster, the name is not updated on the other cluster. Previously, users could easily miss this step, which could lead to confusion. With this update, the output of the `radosgw-admin realm rename` command contains instructions to rename the realm on other clusters as well.
Clone Of:
Last Closed: 2017-06-19 13:29:41 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1497 normal SHIPPED_LIVE Red Hat Ceph Storage 2.3 bug fix and enhancement update 2017-06-19 17:24:11 UTC

Description shilpa 2017-02-17 15:06:48 UTC
Description of problem:
In a multisite cluster, change the realm name on master zone and update the period. The change is not propagated to other zones

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Configure multisite with 3 zones in different clusters
2. Rename the realm name using 'realm rename' command and do a period update commit.
3. The change is not propagated to other zones. 

Expected results:
Spoke to Casey and it appears to be an expected behaviour. Opening a BZ to discuss further.

Comment 2 Casey Bodley 2017-02-22 15:35:05 UTC
This is the case because the realm name is not included in the period, and the period is the only information that gets shared between zones to keep their multisite configuration consistent.

The realm name could be added to the period to support this. When a zone gets a new period, it could update its local realm name accordingly (with care that its update doesn't race with another period).

Comment 8 Ken Dreyer (Red Hat) 2017-04-06 23:10:54 UTC
Casey what is the next step with this bug? Do we plan to fix this in a PR, or is the current behavior expected?

Comment 9 Casey Bodley 2017-04-17 18:52:48 UTC
Hi Ken,

I tend to agree with Orit that there isn't a good fix for this. I do think it's useful for admins to be able to rename their realms, so we should continue to support it. But the name itself is unused outside of these radosgw-admin commands, so we're unlikely to see any bugs caused by a mismatch in realm names between clusters.

My only recommendation is that we add some extra output to the 'radosgw-admin realm rename' command which instructs the admin to run that command on the other clusters as well.

Comment 11 Casey Bodley 2017-04-25 14:55:03 UTC
cherry-picked changes to ceph-2-rhel-patches

Comment 15 Tejas 2017-05-02 04:45:27 UTC
FIx verified on ceph version 10.2.7-13.el7cp (4955aa6a90abc27bc043729db19df24e1c840eac)

radosgw-admin realm rename --rgw-realm studs --realm-new-name=movs --cluster master
Realm name updated. Note that this change only applies to the current cluster, so this command must be run separately on each of the realm's other clusters.

Mopving to verified.

Comment 16 Erin Donnelly 2017-05-15 15:52:17 UTC
Hi Casey, 

I've updated the Doc Text field to reflect the fix so that it can be included in the Release Notes as a bug fix.

Could you check out the text and let me know if you think it is sufficient?


Comment 17 Casey Bodley 2017-05-15 17:11:49 UTC
Looks great Erin, thanks.

Comment 19 errata-xmlrpc 2017-06-19 13:29:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.