Commit Graph
282 Commits
Author SHA1 Message Date
Blaine Gardner 50ff29140a Merge pull request #17052 from BlaineEXE/osd-cephx-key-init-fix
osd: in cephx key init, don't overwrite key on failure
2026-02-09 12:21:54 -07:00
Blaine Gardner d69ffdfd2c osd: in cephx key init, don't overwrite key on failure
Previously, if the OSD cephx-keyring-update init container couldn't
contact the mons, the output redirect would overwrite the on-disk
keyring file with no text, removing the on-disk keyring.

Modify the init container to only overwrite the keyring file when the
ceph command to get the latest key suceeds, to avoid removing the
on-disk key.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
2026-02-09 10:06:27 -07:00
Jan Breitkopf 1ff6f70311 operator: fix OSD info
This fixes OSD info being incomplete when a sidecar container is first
in the .spec.Template.Spec.Containers list.
I added a small helper function to find a container named "osd" instead
of always assuming the first one.

Signed-off-by: Jan Breitkopf <jan.breitkopf@prorocketeers.com>
2026-01-27 11:20:41 +01:00
Travis Nielsen 93adc5dd6b core: include namespace more consistently in logging
When writing to the operator log, where possible
the namespace of the resource on which the operator
is working will be logged as a standard prefix
to more easily troubleshoot what resource is being reconciled

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2025-11-20 15:49:43 -07:00
Travis NielsenandMatthias Osthues d3c0bacd88 osd: set osd resources for specific device class
The OSDs may require different resources based on their device
class. The overall osd resources were only being used, rather
than properly looking up the specific device class resources.
Now the expected resources will take affect per device class.

Co-authored-by: Matthias Osthues <osthues.matthias@gmail.com>
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2025-10-22 10:21:40 -06:00
Blaine Gardner d9d31fe527 osd: allow OSD init keyring update to be best-effort
When OSDs start, init containers attempt to get the latest CephX key for
the OSD to allow OSDs to potentially continue working after key rotation.

However, in Ceph corner cases, mons could be unavailable while OSDs
could still be viable with existing on-disk keys. Since key rotation is
a rare event, it's likely that the on-disk keys are still good.

The worst case scenario is that key updates were needed but didn't
succeed in init containers. In this case, instead of the init container
failing, the OSD startup will fail instead. Thus, this should introduce
no extra risk but merely shift the failure to a different container.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
2025-10-14 10:19:21 -06:00
Santosh Pillai b4e1c1720d osd: rotate lockbox keys for encrypted osd
ceph-volume creates osd-lockbox keys for the encryted osds. This PR
rotates those keys along with the OSD keys.

Signed-off-by: Santosh Pillai <sapillai@redhat.com>
2025-09-01 08:44:14 +05:30
Blaine Gardner 4189a196c1 osd: implement automated cephx key rotation for osds
Implement automated CephX key rotation for OSDs.

OSDs have marshalled CephX statuses applied as an annotation on the OSD
pod spec, which differs from other Rook Ceph daemons for a two reasons:

A large cluster could have hundreds or thousands of OSDs, so it is more
critical that Rook avoid rotating OSD keys more than once in the event a
CephCluster reconcile restarts partway through OSD creation/updation.

OSDs do not have their CephX keys stored in K8s Secrets, whose resource
version is used for enforcing the desired restart behavior other daemon
pods like RGWs.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
2025-07-30 14:18:54 -06:00
Blaine Gardner 2c7a5f156b osd: load latest cephx key during osd pod init
Create a new OSD pod init container that loads the latest CephX key for
the OSD. The init container must be run after OSD activation, due to
keyfile reset behavior of ceph-bluestore-tool, used during activation.

The primary purpose of this work is to allow OSDs to start and run
correctly after key rotation, whether done manually by users or
automatically by future Rook work.

This work makes redundant prior code changes done in #14826. The CI test
added in the prior work is kept to ensure no regression.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
2025-06-18 10:49:19 -06:00
Artem Torubarov c1fd2f2ee8 rgw: use pod name in ops log filename
Signed-off-by: Artem Torubarov <artem.torubarov@sap.com>
2025-04-29 09:43:35 +02:00
Joshua Hoblitt 3cb343f62a core: run gofumpt on all files
Signed-off-by: Joshua Hoblitt <josh@hoblitt.com>
2025-03-26 10:41:48 -07:00
Travis Nielsen 612979b6f0 Merge pull request #15293 from travisn/node-ceph-conf-override
osd: Enable node specific ceph conf overrides
2025-02-25 14:13:54 -07:00
Steven Fackler bbe600aa20 osd: avoid lvm device scan deadlock in activate
If a locally mounted volume is blocked on reads because this OSD is
down, lvs will deadlock trying to read from it. To avoid this, tell LVM
to filter out RBD volumes from its scanning process.

Signed-off-by: Steven Fackler <sfackler@gmail.com>
2025-02-08 13:39:16 -05:00
Artem Torubarov 25ee6b4f59 operator: custom hostname topology label
Signed-off-by: Artem Torubarov <artem.torubarov@clyso.com>
2025-01-24 15:59:07 +01:00
Travis Nielsen b0aefed8e5 osd: enable node specific ceph conf overrides
Some ceph.conf settings need to be unique per node
depending on the hardware. The ceph.conf overrides
can now be customized per-node by creating a node-specific
configmap that will be loaded for all OSDs and OSD prepare
jobs on that node, instead of the default ceph.conf
that is loaded from the rook-config-override configmap.

The node-specific configmaps must have the label
node.config.rook.io/osd, and be named as:
rook-config-override-<hostname>

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2025-01-17 15:57:48 -07:00
Peter Razumovsky 62ffcd4cbe osd: remove excess if-else for keyring file import in activate script
Remove unnecessary if-else statement inside "if keyring file exists"
condition of osd activate script.

Resolves: #14825
Signed-off-by: Peter Razumovsky <prazumovsky@mirantis.com>
2024-11-12 21:20:57 +04:00
Peter Razumovsky 6eb2d1121a osd: import keyring file on activate to ceph auth if not imported yet
If host path keyring file exists and created during osd-prepare but not
imported to ceph auth then rook-ceph-osd activate init container will
create new keyring in ceph auth by ceph auth get-or-create command. To
avoid keyrings difference in host path and in ceph auth, consider
importing key from host path keyring file if no keyring found in ceph
auth.

Resolves: #14825
Signed-off-by: Peter Razumovsky <prazumovsky@mirantis.com>
2024-11-12 21:20:57 +04:00
Peter Razumovsky 97a13628e5 core: add capabilities to securityContext to fix CIS 5.2.8
Resolves CIS benchmark 5.2.8 rule by adding capabilities with
explicitly defined empty "add" list (where it needed) and with
NET_RAW capability in "drop" list.

5.2.8 Minimize the admission of containers with added capabilities

Containers must drop the `NET_RAW` capability and are not permitted
to add back any capabilities.

Signed-off-by: Peter Razumovsky <prazumovsky@mirantis.com>
2024-11-05 16:27:43 +04:00
Guillaume Abrioux dbcd0d46dd osd: mount /run/udev in the init container for ceph-volume activate
The /run/udev directory is now mounted in the OSD init container. This change
is necessary because `ceph-volume activate` needs access to /run/udev [1] in order
to properly handle devices. Without this mount, `ceph-volume activate` could
fail to discover devices during OSD initialization.

[1] https://github.com/ceph/ceph/commit/c2e8c295dc46f1bd74861feb163d9d82f8bb5509

Signed-off-by: Guillaume Abrioux <gabrioux@ibm.com>
2024-10-24 17:16:10 +02:00
Peter Razumovsky 516eab4d8a core: define empty securityContext for pods to fix CIS 5.7.3
Resolves CIS benchmark rule 5.7.3, Pods part. SecurityContext
should be explicitly defined in pod level of Pod spec section.
It is sufficient to specify empty securityContext to satisfy
CIS 5.7.3 rule.

5.7.3 Apply Security Context to Your Pods and Containers

When designing your containers and pods, make sure
that you configure the security context for your pods,
containers, and volumes.

Signed-off-by: Peter Razumovsky <prazumovsky@mirantis.com>
2024-10-09 16:10:03 +04:00
Travis Nielsen b665d7a7b7 core: remove support for ceph quincy
Given that Ceph Quincy (v17) is past end of life,
remove Quincy from the supported Ceph versions,
examples, and documentation.

Supported versions now include only Reef and Squid.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2024-10-03 11:12:55 -06:00
Michael Adam ab8fd90aa6 core: add ROOK_REVISION_HISTORY_LIMIT operator setting
This adds an operator config setting ROOK_REVISION_HISTORY_LIMIT
defaulting to kubernetes'value for RevisionHistoryLimit.

If configured, the provided value will be used as RevisionHistoryLimit

for all Deployments rook creates.

Fixes: #12722

Signed-off-by: Michael Adam <obnox@samba.org>
2024-10-02 19:40:37 +02:00
Travis Nielsen 88e952a3ac osd: update the device class if desired state changes
Normally the device class of an OSD is determined at provisioning
and is not updated thereafter. In some scenarios the admin may
want to force update the device class to a new value. The device
classes can be updated by first setting allowDeviceClassUpdate
in the storage spec of the cephcluster, then updating the
device class specified on the deviceSets or other OSDs.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2024-07-17 13:54:21 -06:00
Blaine Gardner f2304bf8b8 osd: fix activate failure when block device moves
Block devices can move between reboots. In corner cases, an OSDs block
device might move to a lower-indexed device while the previous device
does not exist. For example, an OSD on /dev/sde might move to /dev/sdd
on reboot if the original /dev/sdd died. There would be no /dev/sde
after that.

Users report that NVMe drives commonly change names, even when there are
no disk failures.

For these cases, ensure the activate script properly handles cases where
the previous disk is not present on the node and where the OSD is still
available on a different disk.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
2024-06-24 11:38:24 -06:00
Travis Nielsen 3628e83892 osd: add cephcluster status for legacy osds to replace
LVM-based OSDs on PVCs are legacy and are not well tested.
Therefore, we add status to the cephcluster CR that at least
gives a clue that the OSDs should be replaced.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2024-05-10 16:00:41 -06:00
Travis Nielsen acd7b4faa0 osd: legacy osds on lvm pvcs crash on resize init container
OSDs on LVM-mode PVCs are failing to come up and crashing
in the expand-bluefs init container. To avoid the crash
and allow the OSDs to start, a workaround was found to
simply remove that init container. Now we disable the
OSD resize for this case to avoid others hitting this
during upgrade as well.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2024-04-19 16:26:45 -06:00
Liang Zheng 30bdd43e27 core: fix typos in reconcile cluster disruption
Signed-off-by: Liang Zheng <zhengliang0901@gmail.com>
2024-04-12 17:11:41 +08:00
Yuma Ogami cdd655ed3f osd: delete the key file deletion in encryption open init containers
The key file deletion process is in the shell script commonly used by
all of encryption-open, encryption-open-metadata, and
encryption-open-wal init containers. The key file is deleted at the
encryption-open init container and encryption-open-metadata and
encryption-open-wal init containers are failed to open the key file.

The key file is in the /etc/ceph folder. Unless that folder is shared,
the key file anyway won't be available in the other init containers
even if it is not deleted by these init containers. And it will
naturally anyway be deleted after the init containers are
completed. So The key file deletion process in shell scripts is
unnecessary.

Fixes: #13737

Signed-off-by: Yuma Ogami <yuma-ogami@cybozu.co.jp>
2024-03-19 08:43:36 +00:00
sp98 ffd69291f1 osd: use bash script if restart interval is > 0
If `FlappingRestartIntervalHours` for OSD is > 0 in the cephCluster CR,
then start OSD inside a bash script.

Signed-off-by: sp98 <sapillai@redhat.com>
2023-10-11 11:38:26 +05:30
sp98 4eb9f62205 osd: make osd pod to sleep when osds are flapping
When OSDs flap, ceph stops the OSD daemon if its marked down greater than
5 times in 600 seconds. But OSD pod restarts and marks the OSD `up` again.
This causes the PGs mapped to these OSDs to peer. While the PGs are peering,
IO to these PGs are blocked.

So we need to ensure that if ceph is marking OSD `down` due to flapping, OSD pod
should not restart to mark the OSDs `up` again.

This PR adds a sleep to the OSD pod if the container returned with a 0 exit code
Default behavior is to sleep for 6 hrs. But user can configure it from the
ceph cluster spec.

Signed-off-by: sp98 <sapillai@redhat.com>
2023-09-15 22:59:46 +05:30
Blaine Gardner 17f0072d9d Merge pull request #12778 from BlaineEXE/multus-allow-cidr-spec
multus: allow using NADs without inspectable CIDRs
2023-09-07 13:42:41 -06:00
Blaine Gardner 3c43268d0a multus: detect network CIDRs via canary
Change how Rook detects network CIDRs for Multus networks. The IPAM
configuration is only defined as an arbitrary string JSON blob with a
"type" field and nothing more. Rook's detection of CIDRs for whereabouts
had already grown out of date since the initial implementation.
Additionally, Rook did not support DHCP IPAM, which is a reasonable
choice for users. And more, Rook did not support CNI plugin chaining,
which further complicates NADs. Based on the CNI spec, network chaning
can result in any changes to network CIDRs from the first-given plugin.

All these problems make it more and more difficult for Rook to support
Multus by inspecting the NAD itself to predict network CIDRs. Instead,
it is better for Rook to treat the CNI process as a black box. To
preserve legacy functionality of auto-detecting networks and to make
that as robust as possible, change to a canary-style architecture like
that used for Ceph mons, from which Rook will detect the network CIDRs
if possible.

Also allow users to specify overrides for CIDR ranges. This allows Rook
to still support esoteric and unexpected NAD or network configurations
where a CIDR range is not detectable or where the range detected would
be incomplete. Because it may be impossible for Rook to understand the
network CIDRs wholistically while residing only on a portion of the
network, this feature should have been present from Multus's inception.

Improving CIDR auto-detection and allowing users to specify overrides
for auto-detected CIDRs rounds out Rook's Multus support for CephCluster
(core/RADOS) installations. No further architectural changes should be
needed for CephClusters as regards application of public/cluster network
CIDRs for Multus networks.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
2023-09-07 10:12:55 -06:00
subhamkrai 29d2b6a071 core: restart ceph daemons when network updated
We need to restart all the ceph daemons whenever
cephCluster network settings are modified like
requiremsgr2, encryption and compression. This
required for Ceph to consider the new settings
it require new ceph daemons all over.

Signed-off-by: subhamkrai <srai@redhat.com>
2023-09-01 11:30:48 +05:30
Sheetal Pamecha d86fa2abbc osd: use cp -a command for copying init-containers
remove copy-binaries cmd and related code

Signed-off-by: Sheetal Pamecha <spamecha@redhat.com>
2023-07-31 09:31:38 +05:30
sp98 c13d34f8d3 osd: configure backend store
Configure osd backend store from the cephCluster spec

Signed-off-by: sp98 <sapillai@redhat.com>
2023-07-24 09:16:30 +05:30
avanthakkar 541d091f9c core: use ROOK_CEPH_MON_HOST from config store in OSD pods too
Signed-off-by: avanthakkar <avanjohn@gmail.com>

Volume "ceph-daemons-sock-dir" is coming empty in case if dataDirHostPath,
which is the case for osd onPVC. Fix the volume creation by using the
ceph cluster spec dataDirHostPath, which allows to run socket commands
on osd containers.
2023-06-01 21:09:58 +05:30
Satoru Takeuchi 13e4464fed osd: supoprt expand lvm osd on pvc
The expansion of OSD on PVC is only supported in raw mode OSD.
It's nice to support lvm mode osd too.

Closes: https://github.com/rook/rook/issues/10835

Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
2023-05-16 00:23:09 +00:00
sp98 9e8e85d68b core: use clusterID for service nslookup
use ClusterID of the k8s cluster while doing nslookup of the
exported mon or osd service IP

Signed-off-by: sp98 <sapillai@redhat.com>
2023-04-11 15:24:08 +05:30
sp98 12bbc9b1a8 osd: add container ports only if mcs is enabled
Add container ports for OSD container only when multi cluster service is
enabled in the cluster spec.

Signed-off-by: sp98 <sapillai@redhat.com>
2023-03-01 09:07:08 +05:30
Travis Nielsen 6bcf9004a0 Merge pull request #11567 from cybozu-go/fix-10860
osd: handle device name change and device removel correctly
2023-02-27 11:54:30 -07:00
sp98 7292ac5927 core: export mon and OSD services
Signed-off-by: sp98 <sapillai@redhat.com>
2023-02-27 21:36:59 +05:30
Travis Nielsen d655c86b2f osd: create a service for each osd
The osd needs to bind to an ip that will allow both internal
and external access for rbd mirroring scenarios.
THe operator will create a service for each osd and
instruction the osd to bind to the pod ip while
publishing the clusterIP of the service as the
public IP.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
(cherry picked from commit 14e7225e0a18aff85ede1d476fcaddbbfbcbb732)
2023-02-27 21:05:48 +05:30
Satoru Takeuchi 3a44a394b5 osd: handle device name change and device removel correctly
If a kernel device name change happens and a block device file
in the OSD directory becomes dangling link, this OSD fails
to start continuously. This problem can be resolved by confirming
the validity of the device file and recreating it if necessary.

The original problem happened in host-based clusters. A similar
problem exists in PVC-based clusters. In this case, if a PV,
corresponds to an existing OSD, and points to a missing block
device file, the OSD pod fails to consume this PV. Although this
behavior is undesirable, I don't think this problem should be
handled in Rook. If doing so, we must re-create the existing PV.
Rook shouldn't do such work.

Closes: https://github.com/rook/rook/issues/10860

Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
2023-02-24 05:29:14 +00:00
Travis Nielsen 06eb431525 Merge pull request #11674 from travisn/osd-version-label
osd: Ensure rook version label is not set on pod
2023-02-15 12:21:09 -07:00
Avan Thakkar 460900756c core: add service monitor for ceph-exporter service
Signed-off-by: Avan Thakkar <athakkar@redhat.com>
2023-02-15 15:44:56 +05:30
Travis Nielsen 1ba93b4047 osd: ensure rook version label is not set on pod
The rook-version tag must not be set on the pod spec labels
since it will result in the ceph daemons being restarted every
time there is a rook version update, even if the ceph version
or pod spec was not otherwise updated.

The rook-version tag was being added to the OSD pod spec
due to a shared pointer to the labels. The code intended
to only add the version label to the deployment labels,
but since the pod labels shared the map variable, the
pod unintentionally also had the version label added.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2023-02-14 16:10:53 -07:00
Yuma Ogami 7599f1bc6b osd: add expand-bluefs init container for host-based cluster
OSD is not resized in host-based clusters even though expanding
the backing block device. It's due to the lack of bluefs-bdev-expand
init container.

Closes: https://github.com/rook/rook/issues/10930
Signed-off-by: Yuma Ogami <yuma-ogami@cybozu.co.jp>
2023-01-03 05:03:03 +00:00
Satoru Takeuchi 0e10d97431 Merge pull request #11331 from travisn/remove-env-vars
core: Remove unnecessary env vars from pod specs
2022-12-06 08:28:06 +09:00
Rakshith R bde286ef49 osd: re-open encrypted disk during osd-prepare-job if closed
This commit implements this corner case during osd-prepare job.
```
The encrypted block is not opened, this is an extreme corner case
The OSD deployment has been removed manually AND the node rebooted
So we need to re-open the block to re-hydrate the OSDInfo.

Handling this case would mean, writing the encryption key on a
temporary file, then call luksOpen to open the encrypted block and
then call ceph-volume to list against the opened encrypted block.
We don't implement this, yet and return an error.
```
When underlying PVC for osd are CSI provisioned, the encrypted device
is closed when PVC is unmounted due to osd pod being deleted.
Therefore, this may occur more frequently and needs to be handled.
This commit implements the fix for the same.

Signed-off-by: Rakshith R <rar@redhat.com>
2022-11-30 18:54:23 +05:30
Travis Nielsen 33e824a323 core: remove unnecessary env vars from pod specs
The fsid, username, and user secrets were from legacy and no
longer needed on the osd daemon or mon pods. This removes the
unnecessary env vars from the pod specs.

Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
2022-11-18 16:39:22 -07:00