2 Dec
2019
2 Dec
'19
10:17 p.m.
Thanks for your explanation.
On Tue, Dec 3, 2019 at 12:51 AM Casey Bodley <cbodley(a)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.