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:
You can convert from non-federated to federated RGWs so we should document this. Not a 2.0 blocker though.
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.
(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.
Discussed with Anjana at program call today
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.
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?
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
(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.