Rook has been setting the application automatically on all
pools to rbd for CephBlockPools, rook-ceph-rgw for
CephObjectStores, mgr on the built-in .mgr pool,
and nfs on the built-in .nfs pool.
The legacy pool device_health_metrics is long gone
from Pacific which is no longer supported, so we can
remove special handling for that pool in the upgrade
guide and in the code.
The application setting is now available on the pool spec
although it is not expected to commonly need to override
the default applications set by Rook.
The application for CephFilesystem pools is now being
set to cephfs, where it was previously blank.
Signed-off-by: travisn <tnielsen@redhat.com>
The pg_autoscaler is always enabled by ceph and cannot be disabled.
In a previous PR the pg_autoscaler config was removed from the main example.
Now the remaining config for the pg_autoscaler is removed as well.
Signed-off-by: travisn <tnielsen@redhat.com>
For nightly jobs, canary tests are all running with the same job IDs,
making the last-run jobs cancel previous runs. Add a workflow-id
parameter to canary jobs that can be used to give each job in a canary
suite a unique job ID to prevent this.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
to keep the code consistent and to propogate
more details about error rook uses error wraping.
updating current code whereever its required to
wrap the details.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The cephfs PVC might exist on the kubernetes
node object but due to some timing issues the
ip might not be visible on the ceph cluster or
the client might already got evicted or disconnected
from ceph cluster. In this case we will not be
able to get IP details for the subvolume and we dont
have any check for empty ip's in the code and rook
tries to create NetworkFence CR with empty Ip's
and the NetworkFence will get moved to the Failed state.
This PR adds the necessary check and logging to prevent
this one.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
Looking forward to the 1.14 release in April,
update the roadmap of planned feature work.
The features are not limited to this list,
it is just for context on what is currently
planned.
Signed-off-by: travisn <tnielsen@redhat.com>
upgrading minimum kubernetes supported version to v1.24.17
and also upgrading other kubernetes version to their latest
respective version.
Signed-off-by: subhamkrai <srai@redhat.com>
since networkFence is a cluster-based resource so that we don't need
the namespace and ownerReferences as it cause garbage-collector errors.
Also, now we create the networkFence with clusteUID label so when doing
cleanup we match the cephCluster uid and networkFence label clusterUID.
Signed-off-by: subhamkrai <srai@redhat.com>
Mgr sidecar was using a privileged security context because it needed
to create the /var/lib/rook directory, generate the config on it, and
then copy it to the /etc/ceph directory. This change creates empty
directories on /var/lib/rook and /etc/ceph so the mgr sidecar can use
them, removing the need for using a privileged security context.
Fixes: https://github.com/rook/rook/issues/13719
Signed-off-by: Redouane Kachach <rkachach@redhat.com>
Fixes: #13692
Since the introduction of the "host" network provider, the legacy
"hostNetwork" setting is intended to be used only in combination with
the default network provider (""), but the code did not enforce this.
This change adds the required validation checks to throw errors
in invalid constellations.
These checks are added both in the operator's input validation code
and as kubernetes x-validation admission policies in the Cepcluster CRD.
Signed-off-by: Michael Adam <obnox@samba.org>
Run the canary test suites with nightly CI so that we can detect
incoming issues with Ceph devel versions.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
since networkFence is a cluster-based resource so that we don't need
the namespace and ownerReferences as it cause garbage-collector errors.
Signed-off-by: subhamkrai <srai@redhat.com>
When CPU requests and limits are assigned to a pod,
the pod will be guaranteed the requests, up to the limits.
Even if there are spare CPU cycles, the pod cannot use
them. Thus, pods can be unnecessarily denied compute
when they need to burst if the limits are set.
Therefore, it is not recommended to set CPU limits
since the CPU requests are already guaranteeing that
no pod will be starved at least for its requests.
Signed-off-by: travisn <tnielsen@redhat.com>
subhamkrai
Blaine Gardner
Travis Nielsen
Tim Olow
Madhu Rajanna
dependabot[bot]
subham rai
Redouane Kachach
Michael Adam
Satoru Takeuchi
Joshua Hoblitt