This commit is to handle all those unhandled errors which raises the gosec warning.
Fixed G104: Unhandled Errors are handled now
Signed-off-by: Nizamudeen <nia@redhat.com>
The ceph/ceph:v14.2.7 image is released so we can pick these fixes
up as the recommended version of ceph.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
When the OSD on PVC is backed by a metadata block PVC, the Ceph CRUSH
device class should be set to something else rather than the rotational
property of the drive.
Closes: https://github.com/rook/rook/issues/4881
Signed-off-by: Sébastien Han <seb@redhat.com>
Creating an EC pool was succeeding, but then the update to the
status was failing because of an incorrect check for changing EC
parameters. Now we correctly check if EC parameters are changing
unexpectedly.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The job to wipe devices fails the integration tests periodically.
Now the job will be retried once if it fails to retry wiping the
disks.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
When the cluster is upgraded, the child controllers are notified with the
callback to the ParentClusterChanged() method. These should be made
in a separate goroutine so that the cluster controller is not blocked
on the child controllers and also so child controllers aren't blocked
on each other for the upgrade.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
When ROOK_CURRENT_NAMESPACE_ONLY is true, watches should be limited to
the configured namespace
Signed-off-by: Andrew DeMaria <lostonamountain@gmail.com>
This commit is also part of gosec error handling which handles the following issue:
Fixed G304: Potential File inclusion by cleaning up the file path
Signed-off-by: Nizamudeen <nia@redhat.com>
This commit fixes the gosec warning
G101: Potential hardcoded credential variable by adding a #nosec tag and relavant comment
Signed-off-by: Nizamudeen <nia@redhat.com>
"rook-ceph-operator-config" can be used to override Env Var
initialized during operator deployment.
This commit makes use of the ConfigMap to determine NodeAffinity
and Tolerations for ceph-csi drivers.
Closes#3239
Signed-off-by: Umanga Chapagain <chapagainumanga@gmail.com>
When running on PVC, if the backend resizes the block, Rook will expand
it and the size of the OSD will grow.
Signed-off-by: Sébastien Han <seb@redhat.com>
We now support the addition of the PVC that acts as a metadata device
for a given OSD.
For this, you need to create a new `volumeClaimTemplates`, its name must
be "metadata" otherwise, Rook won't pick it up.
A template will look like this:
```
volumeClaimTemplates:
- metadata:
name: data
spec:
resources:
requests:
storage: 10Gi
# IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, gp2)
storageClassName: gp2
volumeMode: Block
accessModes:
- ReadWriteOnce
- metadata:
name: metadata
spec:
resources:
requests:
storage: 6Gi
# IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, gp2)
storageClassName: gp2
volumeMode: Block
accessModes:
- ReadWriteOnce
```
We now map block and block.db directly inside the container instead of
running ceph-volume activate. This is much cleaner.
Closes: https://github.com/rook/rook/issues/3852
Signed-off-by: Sébastien Han <seb@redhat.com>
This change sets the ResourceVersion on the PrometheusRule object before
it is updated in Kubernetes.
This change fixes the following error
```
is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
```
which can occur during update when no ResourceVersion is set.
Resolves#4528
Signed-off-by: Alexander Trost <galexrt@googlemail.com>
The owner references for the csi driver are causing the csi driver
to disappear when the garbage collector rebuilds its references.
To unblock production clusters we remove the owner references
until we can find the correct fix for the owner references.
Neither the apiVersion of v1 or core/v1 is working.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
In the case where the node disappears abrubtly,
there was nothing to trigger the nodedrain reconciler to clean up
the stale canary.
Signed-off-by: Rohan CJ <rohantmp@gmail.com>
The CSI driver was disappearing in some clusters after certain events such
as restarting the operator or master nodes being restarted. This is due to
an incorrect owner reference on the csi driver back to the configmap. The
owner reference must specify core/v1 instead of v1 for the APIVersion
of the configmap. This issue is only hit when the k8s garbage collector
rebuilds its cache, which would happen at indeterminate times from
Rook's perspective.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Currently there is no option to turn on and off the
log level verbosity in csi containers, This PR adds
the functionality to select logging levels for csi containers.
Fixes: #4690
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
TuneSlowDeviceClass wasn't part of the StorageClassDeviceSet types but
only in VolumeSource which is not exposed in the CR spec so setting the
option would never work.
The only issue is that this apply to all volumeClaimTemplates
where each can point to a particular storage class...
Signed-off-by: Sébastien Han <seb@redhat.com>
Fixed conditions getting resetted after the operator restart.
Did the changes which required to implement conditions on the rook ceph cluster
Conditions will eliminate the current status.State and incorporates a type which
provides much more description to the current status of the cluster.
Signed-off-by: Nizamudeen <nia@redhat.com>
If for any cause the operator processing a mon failover is restarted, the
mon canary pods created in order to get the right placement for this
kind of pods can remain in <pending> state forever.
The following labels have been added to the mon canary deployments:
"mon_type" = "canary"
"canary_pvc_name" = <PVC name used for the canary pod>
A separate <removeCanaryDeployments> has been implemented for
removing the dependence of the variable <canaryCleanup>.
This function uses the <canary> labels to obtain the <real>
and <existing> list of mon canary deployments in any moment.
This change, by itself, will avoid most of the problems with
pending canary pods, but as second safe guard measure a call to this
function has been added in the health check, to <force> a canary pod
deletion if the cluster of monitors is healthy and complete (this implies
that no canary pods should be present)
Resolves#3764
[test ceph]
Signed-off-by: Juan Miguel Olmo Martínez <jolmomar@redhat.com>