Currently we are relaying on the error output from
the umount command we run on the nodes when mounting
the volume but we are not checking for all the error
message to verify the volume is mounted or not.
This commits uses IsMountPoint function in util
to check the mountpoint.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
as callers are already taking care of returing
the GRPC error code return the actual error
from the IsMountPoint function.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
when using pre-provisioned volumes, pass these parameters:
- kernelMountOptions
- fuseMountOptions
- subVolumeGroup
in spec.csi.volumeAttributes in PV declaration
Signed-off-by: YingshuoTao <frigid.blues@gmail.com>
Move the repairing of a volume/snapshot from CreateVolume to its own
function. This reduces the complexity of the code, and makes the
procedure easier to understand. Further enhancements to repairing an
exsiting volume can be done in the new function.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
This commit calls `waitForDaemonSets` and `waitForDeploymentComplete`
after upgrading to wait for csi driver pods to be in running state
for both rbd and cephfs upgrade tests.
Signed-off-by: Rakshith R <rar@redhat.com>
Bringup the rbd-nbd map/attach process on the rbd node plugin and expect the
IO to continue uninterrupted.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
This is a negative testcase to showcase as per current design
the IO will fail because of the missing mappings
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
client-go 1.20.6 has a fix for below CVE: This patch address this
via updating client-go and other dependencies.
CVE-2019-11250 : The MITRE CVE dictionary describes this issue as:
The Kubernetes client-go library logs request headers at verbosity
levels of 7 or higher. This can disclose credentials to unauthorized
users via logs or command output. Kubernetes components (such as
kube-apiserver) prior to v1.16.0, which make use of basic or bearer
token authentication, and run at high verbosity levels, are affected.
Ref# https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11250
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
This commit addresses ifshort linter issues which
checks if short syntax for if-statements is possible.
updates: #1586
Signed-off-by: Rakshith R <rar@redhat.com>
This commit removes calling of .String() when logging
since `%s`,`%v` or `%q` will call an existing .String() function
automatically.
Fixes: #2051
Signed-off-by: Rakshith R <rar@redhat.com>
Current implementation of semvercompare fails against
pre-release versions. This commit fixes it by using
the entire version string at which csidriver api became GA.
s|">=1.18"|">=1.18.0-beta.1"
Fixes: #2039
Signed-off-by: Rakshith R <rar@redhat.com>
minikube waits for 6 minutes for the minikube or
host to be ready, due to resource issue sometimes
the host/minikube might take longer time to start
the cluster. Increase the timeout to 10m by default
updates #1969
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
Test if metrics are available at all. The actual values are a little
difficult to validate.
BlockMode volumes support metrics since Kubernetes 1.22.
See-also: kubernetes/kubernetes#97972
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The NodeGetVolumeStats procedure can now be used to fetch the capacity
of the RBD block-device. By default this is a thin-provisioned device,
which means that the capacity is not reserved in the Ceph cluster. This
makes it possible to over-provision the cluster.
In order to detect the amount of storage used by the RBD block-device
(when thin-provisioned), it is required to connect to the Ceph cluster.
Unfortunately, the NodeGetVolumeStats CSI procedure does not provide
enough parameters to connect to the Ceph cluster and fetch more details
about the RBD image.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The CephFS NodeServer should handle the CephFS specific requests. This
is not something that the NodeServer for RBD should handle.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
This commit disables mon,mgr and mds liveness probe
which on failing caused `crashLoopBackOff` state.
Updates: #2094
Signed-off-by: Rakshith R <rar@redhat.com>
Mergify.io has removed bot_account from its free open source plan.
This commit removes bot_account option from comment, merge and rebase
actions default and documenting the implications going forward.
Signed-off-by: Rakshith R <rar@redhat.com>
Quite a few PRs have the `build:` prefix. It would be good to teach
Mergify to set the label for those.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Added an E2E test to test below case
* Create PVC
* Create Snapshot from PVC
* Delete PVC
* Create Clone from Snapshot
* Delete Snapshot
* Mount clone to Application
* Delete Application and PVC Clone
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
flatten the image if the deep-flatten feature
is present on the images in the chain or if the
images in chain is not zero, as we cannot check
the deep-flatten feature the images which are
in trash.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
For flatten we call checkImageChainHasFeature
which internally calls to getImageInfo returns
the parent name even if the parent is in the trash,
when we try to open the parent image to get its
information it fails as the image not found.
we should treat error as nil if the parent is not found.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
When the configuration for Mergify itself gets updated, there is not
need to run the e2e tests.
It seems that the `(ci)` part of matching a title for ci/testing PRs
would match partial words like 'capacity'. This is not intended, so
rephrasing the regex and adding `e2e` as match too.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The new gosec 2.7.0 complains like:
G304 (CWE-22): Potential file inclusion via variable (Confidence: HIGH, Severity: MEDIUM)
Updates: #2025
Signed-off-by: Niels de Vos <ndevos@redhat.com>
To recover from split brain (up+error) state the image need to be
demoted and requested for resync on site-a and then the image on site-b
should gets demoted.The volume should be marked to ready=true when the
image state on both the clusters are up+unknown because during the last
snapshot syncing the data gets copied first and then image state on the
site-a changes to up+unknown.
If the image state on both the sites are up+unknown consider that
complete data is synced as the last snapshot
gets exchanged between the clusters.
* create 10 GB of file and validate the data after resync
* Do Failover when the site-a goes down
* Force promote the image and write data in GiB
* Once the site-a comes back, Demote the image and issue resync
* Demote the image on site-b
* The status will get reflected on the other site when the last
snapshot sync happens
* The image will go to up+unknown state. and complete data will
be copied to site a
* Promote the image on site-a and use it
```bash
csi-vol-5633715e-a7eb-11eb-bebb-0242ac110006:
global_id: e7f9ec55-06ab-46cb-a1ae-784be75ed96d
state: up+unknown
description: remote image demoted
service: a on minicluster1
last_update: 2021-04-28 07:11:56
peer_sites:
name: e47e29f4-96e8-44ed-b6c6-edf15c5a91d6-rook-ceph
state: up+unknown
description: remote image demoted
last_update: 2021-04-28 07:11:41
```
* Do Failover when the site-a goes down
* Force promote the image on site-b and write data in GiB
* Demote the image on site-b
* Once the site-a comes back, Demote the image on site-a
* The images on the both site will go to split brain state
```bash
csi-vol-37effcb5-a7f1-11eb-bebb-0242ac110006:
global_id: 115c3df9-3d4f-4c04-93a7-531b82155ddf
state: up+error
description: split-brain
service: a on minicluster2
last_update: 2021-04-28 07:25:41
peer_sites:
name: abbda0f0-0117-4425-8cb2-deb4c853da47-rook-ceph
state: up+error
description: split-brain
last_update: 2021-04-28 07:25:26
```
* Issue resync
* The images cannot be resynced because when we issue resync
on site a the image on site-b was in demoted state
* To recover from this state (promote and then demote the
image on site-b after sometime)
```bash
csi-vol-37effcb5-a7f1-11eb-bebb-0242ac110006:
global_id: 115c3df9-3d4f-4c04-93a7-531b82155ddf
state: up+unknown
description: remote image demoted
service: a on minicluster1
last_update: 2021-04-28 07:32:56
peer_sites:
name: e47e29f4-96e8-44ed-b6c6-edf15c5a91d6-rook-ceph
state: up+unknown
description: remote image demoted
last_update: 2021-04-28 07:32:41
```
* Once the data is copied we can see that the image state
is moved to up+unknown on both sites
* Promote the image on site-a and use it
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
Adding labels to Pull-Requests can be done by Mergify. It is very useful
to filter PRs on their labels so that experts in certain areas can
identify PRs to review.
Adding labels is currently a complete manual process, this adds some
automation for it. There is no intention of it being complete, this is
mostly for getting started and trying things out.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The matching with regexes on the `base=` configuration in Mergify does
not seem to work as intended. Possibly this is due the addtional quotes
around the regex.
Fixes: 8d7c66363 (ci: apply standard Mergify rules for release branches too)
Signed-off-by: Niels de Vos <ndevos@redhat.com>
It is not always possible to automatically backport PRs to release
branches. That also means that these backport PRs are not created by the
mergify[bot] account. Because of this, it is needed to manually merge
PRs, as Mergify refuses to do it.
By changing the `base=` option to match a regular expression that
includes both `devel` and `release-*` branches, Mergify should assist
with merging PRs to release branches too.
Note that the `ci/centos` branch is different, as runs other tests than
the normal branches.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
when a Snapshot is encrypted during a CreateSnapshot
operation, the encryption key gets created in the KMS
when we delete the Snapshot the key from the KMS
should also gets deleted.
When we create a volume from snapshot we are copying
required information but we missed to copy the
encryption information, This commit adds the missing
information to delete the encryption key.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
At present the cert keys are not unique which is not correct.
The keys in the secret should be unique and this patch address
the same.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
