Currently, this method also returns true if the object is backfilling.
This commit was reverted earlier in the branch in order to make the
other reverts clean. It's actually a nice rename though, so I'm
re-cherry-picking it.
Signed-off-by: Samuel Just <sjust@redhat.com>
Conflicts:
src/osd/ReplicatedPG.cc
Fixes: #10907
Backport: firefly
Pass any configurables in the rgw frontends config line to civetweb.
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
(cherry picked from commit 986d755442)
If we have a mixed cluster of hammer and pre-hammer OSDs, we will fall back
to using 0 as the initial crc32c value. However, if the primary has a
stored digest, it currently compares its value to the reported value (w/
the wrong initial value) and complains.
There are two possible fixes:
- avoid storing a digest if all peers don't support it, or
- avoid complaining on scrub if all peers don't support it.
The latter is easier, and this fix also has the benefit of fixing the bug
even for clusters where this has already happened.
Fixes: #11102
Signed-off-by: Sage Weil <sage@redhat.com>
Fixes: #11159
Backport: hammer, firefly
Scripts required rgw_socket_path to exist in order to start radosgw.
This is not needed.
Reported-by: Dan Mick <dmick@redhat.com>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
(cherry picked from commit 6823bcdcd0)
Otherwise, we might remember the write, but not that the activation
interval was history.last_epoch_started.
Signed-off-by: Samuel Just <sjust@redhat.com>
It is possible for an incremental change to have both a rm and a set for
a given erasure code profile. It only happens when a rm is followed by a
set. When a set is followed by a rm, the rm will remove the pending set
in the incremental change.
The logic is the same for pool create and pool delete.
We must apply the incremental erasure-code-profile removal before the
creation otherwise rm and set in the same proposal will ignore the set.
This fix is minimal. A better change would be that erasure-code-profile
set checks if there is a pending removal and wait_for_finished_proposal
before creating.
http://tracker.ceph.com/issues/11144Fixes: #11144
Signed-off-by: Loic Dachary <ldachary@redhat.com>
When erasure-code-profile set refuses to override an existing profile,
it may be non trivial to figure out why. For instance:
ceph osd set default ruleset-failure-domain=host
fails with:
Error EPERM: will not override erasure code profile default
although ruleset-failure-domain=host is documented to be the
default. The error message now includes the two profiles that have been
compared to not be equal so that the user can verify the difference.
Error EPERM: will not override erasure code profile default
because the existing profile
{directory=.libs,k=2,m=1,plugin=jerasure,technique=reed_sol_van}
is different from the proposed profile
{directory=.libs,k=2,m=1,plugin=jerasure,ruleset-failure-domain=host,technique=reed_sol_van}
http://tracker.ceph.com/issues/10488Fixes: #10488
Signed-off-by: Loic Dachary <ldachary@redhat.com>
This profile is allowed to create client.rgw.* librados users. They have
access to any pool, which is pretty coarse.
Signed-off-by: Sage Weil <sage@redhat.com>
