Hi, Casey for some zones, likes ES/CloudSync , it does not save data as RGW. we could relax those limitations. maybe we could use `RGWSI_Zone::zone_is_writeable()` here. On Tue, Dec 3, 2019 at 12:51 AM Casey Bodley <cbodley@redhat.com> wrote:

On 11/28/19 11:02 PM, liuchang0812 wrote:

...

Hi, @Yehuda Sadeh-Weinraub <mailto:yehuda@redhat.com> @Casey Bodley <mailto:cbodley@redhat.com> @Matt Benjamin <mailto:mbenjamin@redhat.com> and Cephers

We met a problem with the Elastic Search sync module: bucket with custom placement could not be synced to the target zone. The target zone tries to create a bucket instance based on the placement name, but the target zone does have the placement. logs as following:

meta sync: ERROR: can't store key: bucket.instance: * data sync: ERROR: failed to fetch bucket instance info for * ERROR: select_bucket_placement() returned -22

we are going to fix this issue. here are some questions:

1. should we sync those buckets to the ES zone? it seems not necessary 2. should we sync placements? if we sync placements to the target zone, we also need to create rados pools in the target zone

thanks

Chang Liu

I think that all zones should be required to provide a full mapping of pools for all placement targets and storage classes named in its zonegroup. While that doesn't necessarily make sense for sync modules that don't store object data locally, the placement target validation is part of metadata sync - whereas the sync module abstraction applies mainly to data sync.

I would recommend adding those missing placement targets to the elasticsearch zone. You shouldn't need to actually create pools for them, because radosgw won't be writing anything there.

I would like to find a way to enforce this requirement, but that's difficult because the configuration steps are spread out between multiple clusters. You first have to add the placement target to the global zonegroup configuration, and then modify each local zone configuration to add its pools.