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)
1. setvals clears the digest, even for a new object, since we aren't doing
anything clever with the digest for the provided keys (yet).
2. setheader clears the digest, always, since we aren't doing anything
clever.
Backport: hammer
Signed-off-by: Sage Weil <sage@redhat.com>
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>
The current blanket check in prepare_transaction() will trigger only when
there is a net obs.exists change from the commited obs to new_obs.
However, this misses the case where the first osd_op is a delete and then a
subsequent osd_op recreates the object. Changing the whiteout check to
look only at new_obs does not work because it fails to understand when
_delete_oid sets the whiteout and will simply clear it again.
In order to support sequences of delete + create in general, we need to do
the whiteout flag clearing when the actual create happens (to match the
fact that we set it when we process the delete osd_op). Use a helper to
do this and consolidate most other obs.exists = true code to use it.
Backport: giant, firefly
Signed-off-by: Sage Weil <sage@redhat.com>
Even if the tail != last_update, the log might be empty due to split
moving all entries into other logs.
Fixes: 10718
Signed-off-by: Samuel Just <sjust@redhat.com>
When processing arguments stash an exception which is seen when looking
for another argument type. If we have extra args at the end, output
information about the exception which probably caused the problem.
Fixes: #11093
Original fix: 71ff794eca
Signed-off-by: David Zafman <dzafman@redhat.com>
