Instead of removing the | when an alternative is found in the control
file such as
cryptsetup-bin | cryptsetup
remove the surrounding spaces so that it is treated as a regular
expression that matches either one.
Replace the form
sudo bash -c "FOO=bar ..."
with
sudo env FOO=bar ...
to reduce the levels of shell escaping.
Reported-by: http://dyweni.com/
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The wheel and pip module must not only be installed in each wheelhouse
directory for tox to find. They must also be installed in the virtual
environment that populates the wheelhouse directory. Otherwise older pip
modules such as the one found by default on Ubuntu 12.04 will fail.
Python 2.7.3 on Ubuntu 12.04 also requires that distribute >= 0.7.3 is
installed although it is redundant with setuptools, otherwise it will
fail to run the wheel module.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
Otherwise we can reorder an op around another op which got blocked by a
scrub which started after the first blocked on an obc.
Fixes: #11691
Signed-off-by: Samuel Just <sjust@redhat.com>
os/chain_xattr: cope with xfs limit of 254 bytes for inlined xattrs.
Reviewed-by: Haomai Wang <haomaiwang@gmail.com>
Reviewed-by: Ning Yao <zay11022@gmail.com>
Replicated: For COPY_GET, only src has data/omap digest, the dst can do.
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Samuel Just <sjust@redhat.com>
Create an lrc erasure coded pool and run corruption and repair tests on
it.
http://tracker.ceph.com/issues/11665Fixes: #11665
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The erasure code repair test is split in two function:
* setup conditions specific to jerasure (4 osds, jerasure
profile)
* populate and corrupt and repair the erasure coded pool,
with one or two failures.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
When ceph-objectstore-tool was moved from ceph-test to
ceph by 61cf5da0b5, the ceph package in
debian/control was updated accordingly, as recommended by
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
The same must be done for the ceph-dbg package because
/usr/lib/debug/usr/bin/ceph-objectstore-too is no longer in
ceph-test-dbg.
Although the change was merged may 6th, 2015
8f23382064, teuthology jobs were not
always failing because packages were not systematically upgraded during
the installation. The missing dependencies that were responsible for
this upgrade problem were fixed by
f898ec1e4e on may 18th, 2015 and all
upgrade tests relying on ceph-*-dbg packages started to fail
systematically after this date.
http://tracker.ceph.com/issues/11546Fixes: #11546
Signed-off-by: Loic Dachary <ldachary@redhat.com>
* change from
print_tree(ostream*, Formatter*)
to
print_tree(Formatter*, ostream*)
this is more consistent with other map's print
functions. e.g.
MDSMap::print_summary(Formatter *f, ostream *out)
* and in print_tree(Formatter* f, ostream* os),
- `f` and `os` will be mutual exclusive.
- will assert(0) if both of them are NULL.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* so we are able to dump more info from osdmap using this tool,
and this allows us to reproduce the behavior of "ceph osd tree".
* add a test for 'osdmaptool --tree=<format> filepath'
Signed-off-by: Kefu Chai <kchai@redhat.com>
Otherwise, we might send our deletes based on deleted snaps. This is
problematic since we may have trimmed the clones to which those snaps
belong, causing us to send them at an earlier snap than we used before.
The specific situation was
78:[78, 70, 63, 5a, 58, 57]:[64(63), 58(58, 57)]
with 58 already clean. To flush 64, we send:
delete@58
delete@59
copyfrom@62
Then, snap 63 is trimmed leaving us with a snapset of:
78:[78, 70, 63, 5a, 58, 57]:[58(58, 57)]
since trim_object doesn't filter the head object snapset snaps. This
isn't really a bug since in general all snapset users must be aware
that there may be trimmed snaps in snapset::snaps. However, here
it becomes a problem when we go to flush head:
delete@58 -- ignored due to snapc
delete@59 -- ignored due to snapc
copyfrom@78 -- not ignored
The base pool head is at snap seq 62, so it clones that value into
clone 78(78, 70) instead of forgetting it. What should have happened
is that we should have based our flushes on filtered snapset:
78:[78, 70, 58, 57]:[58(58, 57)]
Causing us to instead send:
delete@58 -- ignored due to snapc
delete@69 -- not ignored, causes no clone to be made
copyfrom@78 -- not ignored, updates head such that a subsequent clone
will leave 70 out of the clone snaps vector.
Fixes: 11787
Signed-off-by: Samuel Just <sjust@redhat.com>
