fix UpdateActiveMgrLabel to retry label update on failure. Previously,
the function always returned the current manager, even if update
failed, leading to inconsistent labels. This fix ensures retries on
failures.
Fixes: https://github.com/rook/rook/issues/13601
Signed-off-by: Redouane Kachach <rkachach@ibm.com>
(cherry picked from commit ee7c71c89e)
Someone testing the Multus holder pod removal feature encountered an
issue where the migration process failed to lead to a system state where
PVCs could be created successfully.
The root cause was found to be a ceph csi config map wherein the primary
CephCluster entry was lacking a value for the "namespace" field.
I observed this once in my development on the holder pod removal
feature, but I was unable to reproduce and assumed it was my own error.
Since this has been seen in a user environment, it must be that the
error is a race condition, and I am unable to determine the exact source
of the bug.
I do not believe this bug would be present if the code that updates the
CSI configmap were properly idempotent, but it has many conditions based
on prior states, and I was unable to determine how to resolve this
underlying impelementation pattern issue.
Instead, I opted to separate the `clusterKey` parameter into two clear
parts:
1. `clusterID` for when `clusterKey` is used as an analogue for
`clusterID`
2. `clusterNamespace` for when `clusterKey` is used as an analogue for
`clusterNamespace`
I added unit tests to ensure that SaveClusterConfig() will be able to
detect when the namespace is currently missing, and using the new
`clusterNamespace` field, it should always know what value to use as
input when correcting the bug in already-installed systems.
I also verified that this update works when the function simultaneously
removes netNamespaceFilePath entries, and that those entries are removed
properly.
Finally, manual testing also verifies the change.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
(cherry picked from commit 4ff881240f)
there are some cases where storageClassDeviceSets length
are more 63 chars and osd provisioned failed due to this.
with error
```
failed to run osd provisioning job for PVC "ocs-deviceset-*-local-volume-storageclass-0-data-*": Job.batch "rook-ceph-osd-prepare-*" is invalid: [spec.template.spec.volumes[10].name: Invalid value: "ocs-deviceset-*-local-volume-storageclass-0-data-*": must be no more than 63 characters, spec.template.spec.containers[0].volumeMounts[9].name: Not found: "ocs-deviceset-*-local-volume-storageclass-0-data-*",
```
Using x-validator to limit the maxLength to the deviceClassSet.Name to
40 chars and adding code check that overall pvc name should be less than
63 chars.
Signed-off-by: subhamkrai <srai@redhat.com>
(cherry picked from commit 6f5cc9b01d)
The mon was listening on both v1 and v2 ports inside the daemon
even though the service endpoint would not redirect any traffic
to the v1 port. When msgr2 is required, disable the mon from
listening on the v1 port for reduced security footprint.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
(cherry picked from commit 954b000ba6)
With the removal of Ceph Pacific support, no need to check if Quincy
is avaiable to support encryption on the wire.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
(cherry picked from commit 25d36c4c75)
in case of portable mons, mon scaledown was skipped
with below code
```
if mon.NodeName == "" {
logger.Debugf("mon %q is not scheduled to a specific host", mon.DaemonName)
continue
}
```
which skips mon removal if mon nodeName is empty
but if mons are scale down in case of portable mons
in that case also we want to remove extra mons to match
the cephCluster configuration.
Signed-off-by: subhamkrai <srai@redhat.com>
(cherry picked from commit d23a8433ed)
Unlike other components, the Ceph dashboard Service object could not be
configured with custom labels and annotations. This can be useful when
integrating Rook into a cluster with custom controllers similarly to how
the RGW service is customized.
Signed-off-by: Steven Fackler <sfackler@gmail.com>
(cherry picked from commit 0c38dd81c2)
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>
(cherry picked from commit acd7b4faa0)
In the primary CSI reconcile, ensure the CSI config map
(`rook-ceph-csi-config`) has the correct owner info.
This corrects any pre-existing config maps that might have incorrect
owner info, which has observed to include references to CephClusters.
The config map should only have a single reference, and it should refer
to the operator deployment.
If any existing Rook clusters have a CSI config map which has a
CephCluster as an owner, this change will ensure that the config map is
not deleted when the CephCluster is deleted. This is especially
important for any environments with multiple CephClusters installed.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
(cherry picked from commit 605b9633ea)
There have been some issues with non-CSI Rook controllers that are
creating the CSI config configmap (`rook-ceph-csi-config`). This causes
problems with the K8s OwnerReference. The primary CSI reconciler
(controller) creates the configmap with the correct owner reference,
which is supposed to be the operator deployment.
Other instances were creating the configmap with owner references set to
the CephCluster. This is a minor bug, but it can result in this
configmap being deleted along with the first CephCluster that initially
created it.
To fix this issue, remove all instances of `CreateCsiConfigMap()` except
the single usage which the CSI reconcile uses to initially create the
configmap. Other controllers that might have attempted to create this
configmap previously will return an error indicating that it is waiting
for the configmap to be created.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
(cherry picked from commit eb3278d575)
The CreateOrLoadClusterInfo (and therefore LoadClusterInfo) methods were
not loading the ClusterInfo.OwnerInfo. This should help future CRD
controllers get the full ClusterInfo struct without having missing
information. Current controllers that need ClusterInfo fill the field
themselves.
During testing, I observed one corner case where an upgraded cluster was
missing the `rook-ceph-csi-config` configmap. The cluster had a
CephFilesystemSubVolumeGroup resource created, and the reconcile for
that resource was attempting to create the missing CSI configmap and
failing with a nil pointer exception due to the missing OwnerInfo field
in ClusterInfo. This cluster condition hasn't been reproduced in healthy
environments, and it is unknown how the CSI configmap came to be
missing. However, the case did expose the missing loaded info as a
potential for causing nil pointer exceptions during corner cases when
code is otherwise correct.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
(cherry picked from commit bd9447ea4c)
The following printcolumns were added
CephBlockPoolRadosNamespace: Phase,
BlockPoolName, Age
CephFilesystemSubVolumeGroup: Phase,
FilesystemName, PinningConfig, Age
Also improved the error messages in
SubVolumeGroupClient
Signed-off-by: NymanRobin <nyman.robin@gmail.com>
(cherry picked from commit 70a7e61da5)
If device set names are duplicated, the OSDs will be very confused
when multiple OSDs attempt to be configured with the same
device set names. Updating the device set names does not help
get out of the error situation since the OSDs will also be
confused about which device set they belong to. The reconcile
must fail completely if the device set names are duplicated
to avoid this error scenario.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
(cherry picked from commit 7f68d8be38)
For check if cluster PGs are healthy before osd updates
Which helps gainning more confidence in the osd upgrades
Signed-off-by: mmaoyu <wupiaoyu61@gmail.com>
(cherry picked from commit 6d4afe23e5)
cephfs subvolumegroup supports creating svg
with quota and the datapool, This PR adds the
support for the same.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
(cherry picked from commit f57a8b6bbe)
Cleanup the resources created by subvolumegroup
when its deleted. Following resources will be cleaned up:
- OMAP value
- OMAP keys
- Clones
- Snapshots
- Subvolumes
Signed-off-by: sp98 <sapillai@redhat.com>
(cherry picked from commit ef00fdac53)
this commits updates the go version to 1.22.2 in govulncheck ci and
also updates golang.org/x/net to v0.23.0 to fix the ci
Signed-off-by: subhamkrai <srai@redhat.com>
(cherry picked from commit f063e8fe39)
make the kubectl output for crds more verbose.
Following changes was done for each crd:
CephBlockPool:
Added print columns:
- Type
- FailureDomain
- Replication
- EC-CodingChunks
- EC-DataChunks
- Age
Extended info field of status to include:
type and failureDomain
CephObjectStore:
Added print columns:
- Endpoint
- SecureEndpoint
- Age
Added Age to print columns of following crds:
CephObjectStoreUser, CephObjectZoneGroup,
CephObjectZone, CephBucketTopic, CephClient,
CephRBDMirror, CephFilesystemMirror,
CephFilesystemSubVolumeGroup
Signed-off-by: NymanRobin <nyman.robin@gmail.com>
(cherry picked from commit 17adb16d0b)
Pool name either come from CephBlockPool name or
form the CephBlockPool Spec. Use the correct name
when trying to disable mirroring.
Signed-off-by: sp98 <sapillai@redhat.com>
(cherry picked from commit 996d9e136a)
The omap data for multipart uploads is stored in an
additional data pool, which cannot be an EC pool.
So the extra data pool is set to the metadata pool
for object stores with shared pools.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
(cherry picked from commit 1c612b0f18)
For image mode mirroring, if cephBlockPool.Pool.Spec.Mirroring.Enable
is set to false, then remove the peer cluster and disable mirroring on
all the pool if the user has disabled mirroring on all the pool images.
If mirroring is not disabled on all the pool images, then reconcile will
fail asking the users to manually disable mirroring on those images.
Signed-off-by: sp98 <sapillai@redhat.com>
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>
Add new CSI_DISABLE_HOLDER_PODS option for rook-ceph-operator.
This option will disable holder pods when set to "true".
In the long term, Rook plans to deprecate the holder pods entirely.
This new option will allow users to choose to migrate their clusters to
non-holder clusters when they are ready and able, giving them time to
gracefully migrate before the holders are permanently removed.
This option is set to "false" by default so that upgrading users don't
have their CSI pods modified unexpectedly.
Example manifests are modified to set this value to true so that new
clusters will not deploy holder pods.
Migrating users are provided with documentation to instruct them about
the new requirements they need to satisfy to successfully remove holder
pods, a procedure for migrating pods from holder to non-holder mounts,
and a way to delete holder pods once they are no longer in use.
When users set CSI_DISABLE_HOLDER_PODS="true", the CSI controller will
no longer deploy or update the holder pod Daemonsets, but it does not
delete any existing Daemonsets. This allows already-attached PVCs to
continue operating normally with their network connection continuing to
exist in the current holder pod. This is critical to avoid causing
ia cluster-wide storage outage.
More info: https://github.com/rook/rook/issues/13055
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
Until now, an object store would create all the necessary
metadata pools and the data pool that were exclusively
for its own object store. When isolation between object
stores is necessary, this would cause many pools and
PGs to be created in the cluster, which was not
manageable.
Now one set of pools can be created to be shared
by any number of object stores. The metadata and data
between each object store is isolated by
RADOS namespaces, which by design will keep the
data safe for multi-tenancy.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
With the release of Reef v18.2.2 we update the default
recommended version of Ceph to fix the prometheus issues
seen with v18.2.1
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Redouane Kachach
Blaine Gardner
subhamkrai
Travis Nielsen
Praveen M
mergify[bot]
parth-gr
Steven Fackler
NymanRobin
sp98
mmaoyu
Madhu Rajanna
Liang Zheng
subham rai
Yuma Ogami
Redouane Kachach