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>
Currently, when rook provisions OSDs(in the OSD prepare job), rook effectively run a
c-v command such as the following.
```console
ceph-volume lvm batch --prepare <deviceA> <deviceB> <deviceC> --db-devices <metadataDevice>
```
but c-v lvm batch only supports disk and lvm, instead of disk partitions.
We can resort to `ceph-volume lvm prepare` to implement it.
Signed-off-by: Liang Zheng <zhengliang0901@gmail.com>
The 'extra' block device attached to GH actions runners has changed size
twice in 3 months. The previous strategy of detecting the disk by size
is becoming harder to maintain. Additionally, the block size with recent
changes (75G) is now the same as the boot device (also 75G), making the
method inexact.
The method can now be summarized as, "find the boot disk and choose the
disk that isn't the boot disk to be the 'extra' one used."
Prior to this, we used a one-liner based on `lsblk`. While we could
still make this a one-liner, the method is now updated to 2 effective
lines, plus debug text output to stderr to help if we need to debug
further in the future.
Of note, the 'extra' disk has a mount point of "/mnt", but it is unclear
whether this is a reliable heuristic for detecting the extra disk. For
years now, GH action runners have had only 2 disks. Therefore, it seems
slightly more likely that a heuristic to "choose the non-boot disk" will
be a more robust long-term solution.
If this strategy proves to be unreliable in the future, it may be wise
to consider whether "the device with a partition mounted to '/mnt'"
would be a good alternative.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
the disk size in the github action machine has
increased from 64G to 75G. Now, we detech the version
automatically not fetching hard coded value.
Co-authored-by: Jan Klippel <jan.klippel@uhurutec.com>
Signed-off-by: subhamkrai <srai@redhat.com>
This is needed because not all contributors may be using gomft to format
source code, and this could result in inconsistent usage over time.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
Sometimes we need to run canary test on custom ceph images
to test any issue. For this we always need to create separate
PR with custom image. Now, with github action workflow_dispatch
we can use GitHub UI to pass ceph image as input for CI tests
and that image will be used to run the canary test otherwise,
it will be default value provided.
Signed-off-by: subhamkrai <srai@redhat.com>
we have changed the --cluster-name flag to --k8s-cluster-name
but to support automation while upgrade we should support
the legacy flag
Signed-off-by: parth-gr <partharora1010@gmail.com>
Currently, `wait_for_prepare_pod` only waits until 1 prepare pod and 1
OSD pod are in Running state.
So if `wait_for_ceph_to_be_ready` failed after `wait_for_prepare_pod`
succeeded, there are 4 possible cases:
1. some prepare pods didn't start correctly;
2. some prepare pods didn't finish correctly;
3. some OSD pods didn't start correctly; or
4. all prepare pods and OSD pods worked correctly, but some other
process failed.
As far as I understand, the number of prepare pods on the GitHub CI is
always 1, so cases 1 and 2 are not problematic. However, it is hard to
distinguish the other two cases from the CI log.
To solve the above problems, this patch makes wait_for_prepare_pod wait
for all OSD pods to become running state. If wait_for_prepare_pod
timeouts before the OSD pods become running state, this will be a strong
indication that the OSD pods didn't start properly (i.e., case 3).
Signed-off-by: Ryotaro Banno <ryotaro.banno@gmail.com>
currently, in the cluster-test yaml, file we have both cephCluster
CR and cephBlockPool CR and we're trying to update the cephCluster
CR to disable the livnessProbe of mon, osd, mgr but since we had `yq write -d1`
it was updating the second instance of `spec` which is cephBlockPool
instead we have to do `yq write -d0` to update the cephCluster `spec`.
Signed-off-by: subhamkrai <srai@redhat.com>
I was debugging helm tests, I noticed, the operator namespace
content is empty and operator is created in same namespace as
other pods. Also, let's collect the 'kube-system' namespace logs
in multus test only as that is the only test where we need to debug
cluster networking and require kube-system logs.
Signed-off-by: subhamkrai <srai@redhat.com>
use `sed` to update all the namespace in filesystem-test.yaml file.
Since with subvolumegroup CR added there are more than one `namespace: *`
present and only one was updating by yq command.
Signed-off-by: subhamkrai <srai@redhat.com>
In canary test `multi-cluster-mirroring` we also need to collect
logs of `rook-ceph-secondary` namespace to debug the ci.
Signed-off-by: subhamkrai <srai@redhat.com>
we are passing inputs to composite action, like
`github_token` which is not being used anymore. Its'
better to clean those lines.
Signed-off-by: subhamkrai <srai@redhat.com>
Loop variables cannot be reliably uses since they will
change with each iteration. Update these loop variable
uses to be safe by indexing the slice rather than
using the loop variable directly.
Also suppress the linter issues for passwords used
in tests.
Signed-off-by: travisn <tnielsen@redhat.com>
The K8s v1.25.17 release does not exist, which was mistakenly
set in the CI for the master and release tests. Now we revert
it back to v1.25.16.
Signed-off-by: travisn <tnielsen@redhat.com>
change the json output of storageclass to also inclusde rados namespace,
and also added the changes in the csi secret
Signed-off-by: parth-gr <paarora@redhat.com>
Upgrade minimum kubernetes support to 1.23.17 from 1.22.17.
Also, upgrade kubernetes version latest minor release.
Signed-off-by: subhamkrai <srai@redhat.com>
In, go 1.20 govulncheck ci is failing due to
some vulnerabilities which affects windows
machine and rook is not used in windows machine.
The solution is to update go version to 1.21.4
Signed-off-by: subhamkrai <srai@redhat.com>
Since nobody seems to see the instructions for opening a PR,
make another attempt to clarify what someone should do
when they are opening a PR.
Signed-off-by: travisn <tnielsen@redhat.com>
github ci runner is allocating both 14 and 64 Gb disks to the setup.
Rook CI currently hard codes the lsblk with a 14G filter.
This PR updates the filter to use either 14G or 64G disks.
Signed-off-by: sp98 <sapillai@redhat.com>
subham rai
dependabot[bot]
Blaine Gardner
Liang Zheng
sp98
Travis Nielsen
subhamkraiandJan Klippel
parth-gr
Praveen M
Ryotaro Banno
Anthony D'Atri
parth-gr