as go-ceph is 0.5.0 is released updating
the dependency to latest release.
more info about release at
https://github.com/ceph/go-ceph/releases/tag/v0.5.0
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
Problem:
-------
$ minikube version
minikube version: v1.12.2
commit: be7c19d391302656d27f1f213657d925c4e1cfc2-dirty
$ ./scripts/minikube.sh up
installed minikube version v1.12.2 is not matching requested version latest
Here v1.12.2 is the latest version of minikube, but the script simply bails out.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
In this script we defined all the functions at the top and then started
with executable commands (entry points to script start).
Only this function is odd in the script unlike the rest of them, defined
in between the execution sequence taking away the readability.
Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
we cannot depend on the master branch of external-snapshotter
in cephcsi as the master branch can change anytime. its
good to use released tags to our E2E.
fixes: #1416
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
we should not return the CLI errors in GRPC errors
we need to return proper readable error messages
to the user for better understanding and better
debugging.
updates #1242
Signed-off-by: Madhu Rajanna <madhupr007@gmail.com>
The Git hooks force the developers to satisty
certain rules before commiting changes(locally).
Following checks will be run before allowing developers
to commit changes:
1. Check if the commit message has a valid sign-off.
2. Catch gofmt issues, if any.
3. Verify syntax of yaml and json files.(if present)
4. Makes sure that files end in a new line.
5. Trims trailing whitespace.
6. Run commitlint check on the commit message.
The developers will not be allowed to commit changes
without satisfying the above mentioned rules; This will
inturn help in avoiding failures on CI.
Signed-off-by: Yug <yuggupta27@gmail.com>
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>
