Since https://github.com/rook/rook/pull/4219, lv devices are now
presented to ceph-volume when preparing the device.
So on this initial run, this won't fail because the dm hasn't been
created yet but if an orchestration is re-triggered, the prepare pod
ensures idempotency with the ceph-volume batch command.
Unfortunately, c-v seems to have a bug where it doesn't read the dm to
detect whether or not they are ceph members already.
Ceph bug: https://tracker.ceph.com/issues/43209
Signed-off-by: Sébastien Han <seb@redhat.com>
ceph client CRD refactoring
Add info about client crd to documentation
Add tests for client controller CRD
Signed-off-by: Mateusz Los <los.mateusz@gmail.com>
Add documentation to clone the correct release branch of the repo
to reduce confusion from pulling the wrong branch.
Signed-off-by: Alex Punnen <alexcpn@gmail.com>
The deviceFilter property needs to have a value rather
than be completely empty as it was in the settings.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
When a node has been removed, cordoned, or is otherwise
missing from the filters that rook uses to evaluate deploying
osds on nodes, the orchestration should continue instead
of failing. Otherwise, the orchestration will stay stuck
in a retry loop if any nodes are cordoned or removed in
the middle of an orchestration.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
"OSD on PVC" doesn't work for PV backed by LV. Fixing this problem
by the following changes.
- Rook accepts LVM disk type.
- If a LV-backed device is passed, Rook/Ceph invokes
"ceph-volume lvm prepare" with "--data vg/lv"
instead of "--data /path/to/device".
- If a LV-backed device is passed, Rook/Ceph suppresses
activation/deactivation of VG that owns this LV.
Fixes: https://github.com/rook/rook/issues/4185
Signed-off-by: dulltz <isrgnoe@gmail.com>
Co-authored-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
This patch removes the need of using both tini and rook binary to run
the main osd container.
By removing this, we know can upgrade the operator image without
restarting the OSD since the osd pod does not use the rook image
anymore.
This patch only works when not running OSD on PVC since they are certain
actions that we cannot achieve with an init container.
A new init container has been introduced to do the activation of the
OSD, the activate files are placed in a empty dir mount and shared with
the main osd process.
Now the main osd process runs the ceph-osd daemon binary directly.
This currently has a few limitation:
* only works with bluestore OSDs
* only works when not running OSD on PVC
Closes: https://github.com/rook/rook/issues/4363
Signed-off-by: Sébastien Han <seb@redhat.com>
There is use case when need to run rook operator on host network since
ceph mon is not accessible from kubernetes pod network.
Signed-off-by: ruslanloman <ruslanloman@gmail.com>
We shouldn't need to compute the location from the main OSD pod, since
the prepare pod runs on the same node we can populate the crush location
information from that pod and pass it along to the main osd container.
This is an initial commit that aims to eventually remove the need of
using the rook binary when running the main osd container.
Closes: https://github.com/rook/rook/issues/4362
Signed-off-by: Sébastien Han <seb@redhat.com>
`ceph-volume` cannot handle a device correctly if the device has an alias
under `/dev/mapper/`.
This commit fixes it by checking whether the device has that kind of alias
and using the alias as an argument for `ceph-volume`.
Signed-off-by: Kazuhito MATSUDA <kazuto.jinnai@gmail.com>
This reverts commit 7553318235.
The append puts the filter at the end of the file and it's out of any
lvm section, so it does not work anymore.
LVM complains with:
Configuration setting "filter" invalid. It's not part of any section.
Signed-off-by: Sébastien Han <seb@redhat.com>
During an orchestration if there were failures to update any OSD deployment,
the orchestration would fail and continue trying again. If the OSD(s)
continued failing, the operator would be stuck in a loop and never
respond to other CR updates.
Now the operator will log the OSD errors, if any, and complete the
orchestration. We will rely on K8s to continue to attempt to start
the OSD pods instead of the operator being stuck in the loop.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>