At CSI spec < 1.2.0, there was no volumecapability in the
expand request. However its available from v1.2+ which allows
us to declare the node operations based on the volume mode.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
With '# make image-cephcsi GOARCH=amd64'
On Fedora observed errors like:
---> Running in 3e2dbf48ebc6
OCI runtime create failed: this version of runc doesn't work on cgroups
v2: unknown
make: *** [Makefile:175: image-cephcsi] Error 1
hence it is recommended to switch to podman if available.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
if the commit header is not present in the list of
the component we maintain. the commitlint check should
show error instead of showing the warning.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The aggregate clusterrole were designed for the scenario where
the rules are not completely owned by one component.
the aggregate rules can be removed and simplify
certain issues around upgrades.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The GitHub commitlint App does not get triggered for new or updated PRs
since the last days. It is possible to manually start a test in the
CentOS CI for this with `/test commitlint`, but Travis CI already
includes a test (as part of "static-checks") too. There is no need to
run the tests 2x, so remove the status check from the Mergify
configuration.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
After fetching the target branch for the PR, the GIT_SINCE ref in the
git repository may not be set (in CI environments). This causes 'git
rebase' to fail. Use FETCH_HEAD instead, so that the checked out PR gets
rebased correctly.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
When Mergify adds a merge commit to the branch that is being tested with
commitlint, the tool tries to detect the most recent changes based on
the newly merged commit. This is for most PRs the master branch, and
that contains incorrect commit messages in the history. Because of this,
commitlint will fail.
By adding an option (REBASE=1) to the commitlint make target, CI jobs
can request a rebase so that the history of the PR becomes linear again
and commitlint should be able to detect only the new commits.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
The 'need-container-cmd' make target is marked as .PHONY which will
cause it to be run every time. That triggers a rebuild of the container
images, even when that is not required.
By removing the 'need-container-cmd' target from .PHONY, and storing the
contents of CONTAINER_CMD in .container-cmd, unneeded rebuilds are
prevented.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
currently the lock is not released which is
taken on the request name. this is causing issues
when the subvolume is requested for delete.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
execCommandErr returns both error and stderror
message. checking strings.HasPrefix is not helpful
as the stderr will be the first string. its good
to do string comparison and find out that error
is volume not found error.
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
It seems the 'rebase' action in Mergify causes each PR to be
automatically rebased once there is a change in the target branch. This
causes a very high load on the CI, which delays other PRs from getting
their test results.
Remove the 'rebase' action, as it does not work as intended. The
expectation was that '@mergifyio rebase' uses the configuration.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Merge commits cause the CentOS CI commitlint job to fail. By configuring
Mergify to not do merge commits, but rebases before final testing, we
can use the CentOS CI commitlint job when the GitHub commitlint App does
not work.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Currently the "@mergifyio rebase" commands uses a random person from the
GitHub organization that owns the repository. This is rather confusing
and ugly. With this change, alls rebase/merge actions are done with the
ceph-csi-bot account that also posts the result of jobs in the CentOS CI.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
There can be spurious failures in the CI when running kubectl create. On
occasion, the command returns with an error, but the api-server did
receive and process the request. This causes a 2nd create action to fail
with messages like:
cephcluster.ceph.rook.io/my-cluster created
Error from server: error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": etcdserver: request timed out
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": configmaps "rook-config-override" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": cephclusters.ceph.rook.io "my-cluster" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": configmaps "rook-config-override" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": cephclusters.ceph.rook.io "my-cluster" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": configmaps "rook-config-override" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": cephclusters.ceph.rook.io "my-cluster" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": configmaps "rook-config-override" already exists
Error from server (AlreadyExists): error when creating "/tmp/tmp.Ur1ZPG85o9/cluster-test.yaml": cephclusters.ceph.rook.io "my-cluster" already exists
By handling the create action differently, and checking for the
AlreadyExists word in the stderr output, it is possible to detect
repeated creates that are not needed.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
