RGWSimpleRadosReadCR won't currently fail with ENOENT, but instead
passes an empty object to handle_data(). add an empty_on_enoent flag to
the constructor, defaulting to true, to make this behavior optional for
callers that do want to fail on ENOENT

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit c5c95e7)

RGWMetaSyncCR was using operator== but it always returned true!

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 09c847f)

Fixes: http://tracker.ceph.com/issues/18639

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 7c23713)

RGWInitDataSyncStatusCoroutine operates on a given rgw_data_sync_status
pointer, which saves us from having to read it back from rados

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 69be410)

Conflicts:
	src/rgw/rgw_data_sync.cc: rgw_pool, rgw_raw_obj

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit a898fb7)

sync status markers can't be compared between periods, so we need to
record the current period's realm epoch with its markers. when the
rgw_meta_sync_info.realm_epoch is more recent than the marker's
realm_epoch, we must treat the marker as empty

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 574ff5f)

Conflicts:
	src/rgw/rgw_sync.cc: rgw_pool

makes the same change to read_sync_status() in RGWMetaSyncStatusManager,
needed to support multiple concurrent readers for the rest interface

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 0372df2)

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit a4bf014)

Conflicts:
	src/rgw/rgw_sync.cc: rgw_pool, rgw_raw_obj

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit bb49e2f)

Conflicts:
	src/rgw/rgw_rados.cc: RGWPeriod::update removed

if a zone is promoted to master before it has a chance to sync from the
previous master zone, any metadata entries after its sync position will
be lost

print an error if 'period commit' is trying to promote a zone that is
more than one period behind the current master, and only allow the
commit to proceed if the --yes-i-really-mean-it flag is provided

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 721e3d6)

when the master zone is changed, this config variable was increasing the
window of time where the old master zone would continue to handle
requests to modify metadata. those changes would not be reflected by the
new metadata master zone, and would be lost to the cluster

it was an attempt to optimize for the unlikely case of multiple period
changes in a short period of time, but the logic in reload() handles this
case correctly as is

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit f422d4f)

avoid marker comparisons between different periods

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 20df35a)

test was only creating objects in subsequent periods, which wasn't
adding any entries to the mdlog. this wasn't correctly testing
incremental metadata sync across periods

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 2976fd3)

Signed-off-by: Casey Bodley <cbodley@redhat.com>
(cherry picked from commit 5cc99db)