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 default service account access is needed for the operator
and the toolbox to run on openshift. This is a follow-up from
PR 13362 that created a new default service account to use with
all ceph or rook components that were relying on the default
service account.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
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>
previously, we had kept the Rook orchestrator manager module disabled
so far because it was causing a bunch of issues and errors on the
dashboard. But with the recent changes made in the cephv v18.2.1
release, we've fixed those issues and made some overall improvements
to the dashboard user experience when Rook is enabled. With all that
in mind, it's time to switch on the Rook orchestrator by default.
Fixes: https://github.com/rook/rook/issues/13760
Signed-off-by: Redouane Kachach <rkachach@redhat.com>
The description of the object store types was improperly
formatted due to a missing newline before the bullet points.
Signed-off-by: Travis Nielsen <tnielsen@redhat.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>
add an option to set prefix for the name of obc provisioner instead of
ceph cluster namespace.
Signed-off-by: Jiffin Tony Thottan <thottanjiffin@gmail.com>
with topologyconstrain pool we can enable any
replica pool usage and also can store data at any
topology
Signed-off-by: parth-gr <partharora1010@gmail.com>
the labels listed under the 'monitoring' section are currently only
being applied to the rook-ceph-mgr ServiceMonitor. This change extends
those labels to also include the rook-ceph-exporter ServiceMonitor.
Fixes: https://github.com/rook/rook/issues/13774
Signed-off-by: Redouane Kachach <rkachach@redhat.com>
The upgrade test should always upgrade from the
previous minor release to the latest master. With 1.14
releasing soon, now we upgrade from 1.13 to master,
to confirm if there are any upgrade issues to 1.14.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>