Bug 1353854

Summary:	Clarification of Migration to Federated RGW
Product:	[Red Hat Storage] Red Hat Ceph Storage	Reporter:	Shinobu KINJO <skinjo>
Component:	Documentation	Assignee:	John Wilkins <jowilkin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	shilpa <smanjara>
Severity:	medium	Docs Contact:
Priority:	high
Version:	1.3.2	CC:	asriram, cbodley, ceph-docs, hnallurv, jowilkin, kdreyer, mbenjamin, nlevine, uboppana
Target Milestone:	rc
Target Release:	2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-09-30 17:20:30 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1360396
Bug Blocks:

Description Shinobu KINJO 2016-07-08 08:42:12 UTC

Description of problem:

The current documentation [1], there is no description about if it's doable to migrate existing rgw bucket to federated bucket.

It's not actually but but it's better for end users to describe if it's possible or not expressly officially.

[1] https://access.redhat.com/documentation/en/red-hat-ceph-storage/version-1.3/red-hat-ceph-storage-13-ceph-object-gateway-for-rhel-x86-64/#ceph_federated_object_gateway_for_rhel_x86_64

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 4 Neil Levine 2016-07-15 17:46:14 UTC

You can convert from non-federated to federated RGWs so we should document this. Not a 2.0 blocker though.

Comment 6 John Wilkins 2016-07-26 16:55:02 UTC

We will address this post 2.0. The process involves creating a realm and zone group that is not using the default naming. It involves either creating or renaming the existing Default zone group. The same is true of the zone. By default, in 2.0 the pools are named zone-name.rgw.something. If the migration from simple to federated uses a configuration from 1.3, the process may have a slightly different naming convention than if we migrate from a cluster setup in 2.0. We have to verify these steps precisely so that we do not break a customer's production cluster.

Comment 7 Shinobu KINJO 2016-07-27 00:07:41 UTC

(In reply to John Wilkins from comment #6)
> We will address this post 2.0. The process involves creating a realm and
> zone group that is not using the default naming. 

Which credential mechanism are you mentioning here?
If customers don't use any credential, will there be guide for this case?

> It involves either creating
> or renaming the existing Default zone group. The same is true of the zone.
> By default, in 2.0 the pools are named zone-name.rgw.something. If the
> migration from simple to federated uses a configuration from 1.3, the

Will migration steps you are going to verify using 2.0 be applicable for 1.3?
Will it be downward compatibility?

> process may have a slightly different naming convention than if we migrate
> from a cluster setup in 2.0. We have to verify these steps precisely so that
> we do not break a customer's production cluster.

*downward compatibility* is not *must*. In case that they have to use 2.0, will there be guide step by step, including upgrading to 2.0, migrating to federated gw?

This might be beyond of this scope. But it would be better to consider failure of migration.

Comment 8 John Poelstra 2016-07-27 16:30:13 UTC

Discussed with Anjana at program call today

Comment 9 Neil Levine 2016-07-27 16:39:42 UTC

I am going to revert on my comment #4 unfortunately.

For customers who have a 1.3 cluster that is NOT running multisite, who upgrade to 2.0 and then choose to enable multisite, we need to have docs which explains what to do for the 2.0 GA.

Casey is working on a proposed procedure as part of https://bugzilla.redhat.com/show_bug.cgi?id=1360396

What we do NOT need to for 2.0 is customers running 1.3 with Multisite who then upgrade to 2.0 Multisite. For these customers, we should have a note in the docs that they should contact support for advice on recommended steps so we can look at their configuration, environment, and data first.

Comment 11 shilpa 2016-08-10 12:57:02 UTC

John, I think we need to add the last bit from Neil's comment#9 about including a note that customers should contact support if they are migrating from 1.3 Federated configuration to 2.0 multisite. May be add in the release note?

Comment 12 John Wilkins 2016-08-11 22:04:37 UTC

Added a topic immediately after https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#migrating_a_single_site_system_to_multi_site

Comment 13 shilpa 2016-08-12 06:13:44 UTC

(In reply to John Wilkins from comment #12)
> Added a topic immediately after
> https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/
> object-gateway-guide-for-red-hat-enterprise-
> linux#migrating_a_single_site_system_to_multi_site

Thanks. Looks good to me.