Because of a missing return, ceph-disk prepare would fail if given a
regular file as a journal. If the journal file does not exist, ceph-disk
will create it but fail to ensure that the ceph user owns it. The
symlink to the journal file is not set when the journal file is
specified on the command line and the journal file does not exist at
all. The ceph-osd daemon will silently create it as a file but it will
not be the file given in argument.
Add a test case to verify using a regular file as a journal works as
expected.
Fixes: http://tracker.ceph.com/issues/17662
Signed-off-by: Jayashree Candadai <jayaajay@indiana.edu>
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The sh function will collect both stderr and stdout and debug
will mess the json parsing.
Fixes: http://tracker.ceph.com/issues/17607
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The scsi_debug SCSI devices do not have a symlink in /dev/disk/by-partuuid
because they are filtered out by 60-persistent-storage.rules. That was
worked around by 60-ceph-partuuid-workaround-rules which has been
removed by 9f76b9ff31.
Add create rules targetting this specific case, only for tests since the
problem does not show in real use cases.
Fixes: http://tracker.ceph.com/issues/17100
Signed-off-by: Loic Dachary <loic@dachary.org>
Simulate the cases where the activation (via udev running trigger)
sequences are:
* journal then lockbox
* data then lockbox
* lockbox
All of them must end with the OSD verfied to be up.
Signed-off-by: Loic Dachary <loic@dachary.org>
Instead of storing the dmcrypt keys in the /etc/ceph/dmcrypt-keys
directory, they are stored in the monitor. If a machine with
OSDs created with ceph-disk prepare --dmcrypt is lost, it does
not contain the key that would allow to decrypt their content.
The dmcrypt key is retrieved from the monitor using a different keyring
for each OSD. It is stored in a small partition called the lockbox. At
boot time the lockbox is mounted
/var/lib/ceph/osd-lockbox/$uuid
and used when the $uuid partition is detected by udev to map it with
cryptsetup.
The OSDs that were prepared prior to the lockbox implementation are
supported by looking up the key found in /etc/ceph/dmcrypt-keys before
looking in /var/lib/ceph/osd-lockbox/$uuid.
http://tracker.ceph.com/issues/14669Fixes: #14669
Signed-off-by: Loic Dachary <loic@dachary.org>
http://tracker.ceph.com/issues/13422 made it so ceph-osd won't start
unless the pidfile can be created successfully. The default location
being the current directory, ceph-osd must explicitly be told to write
in a directory where it has write permissions.
Signed-off-by: Loic Dachary <loic@dachary.org>
Only support the block file for now. It is handled the same as the
journal, only with a different name (block) and it's own set of ptypes
depending on multipath or dmcrypt.
Signed-off-by: Loic Dachary <loic@dachary.org>
If the journal is not unmapped, ceph-disk destroy will fail to zap the
corresponding devices because it is still held by devicemapper.
A consequence of this modification is that
ceph-disk activate --dmcrypt --reactivate
no longer works from the command line, because it does not map the
dmcrypted journal. The --reactivate option is added to activate-journal
which will map both the journal and the data devices, if necessary.
http://tracker.ceph.com/issues/14233Fixes: #14233
Signed-off-by: Loic Dachary <loic@dachary.org>
- using the deactivate/destroy feature to destroy osd
- test reactivate option when the osd goes deactive
- add check_osd_status to check osd status when osd goes up
Signed-off-by: Vicente Cheng <freeze.bilsted@gmail.com>
Instead of using augtool to modify the configuration file, use
configobj. It is also used by the install teuthology task. The .ini
lens (puppet lens really) is unable to read ini files created by
configobj.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The ceph-disk workunit deploy keys that are not deployed by default by
the ceph teuthology task.
The OSD created by the ceph task are removed from the default
bucket (via osd rm) so they do not interfere with the tests.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
If installed on Ubuntu where multipath does not activate properly, it
interferes with the other tests.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
After preparing an OSD, wait for the corresponding OSD to be up
according to ceph osd dump before asserting the devices are in the
expected state. Otherwise the test races with ceph-disk activate which
is run asynchronously via udev / upstart / system.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
It turns out it was not CentOS 7 specific. There is no excuse to skip
the tests anymore.
http://tracker.ceph.com/issues/12787 Refs: #12787
Signed-off-by: Loic Dachary <ldachary@redhat.com>
* Get rid of the cryptsetup calls that are redundant with what ceph
prepare already does
* Do not use the --dmcrypt-key-dir option. This is less coverage but it
interferes with the udev logic and is expected to be refactored soon.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
This new ceph-disk workunit re-implements the tests that previously were
in the src/test/ceph-disk.sh src/test/ceph-disk-root.sh scripts and is
meant to run in a virtual machine instead of docker.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
