rebase: update minikube to latest version #1811
Conversation
Madhu-1
added
rebase
build.env
Outdated
| @@ -36,7 +36,7 @@ SNAPSHOT_VERSION=v3.0.1 | |||
| HELM_VERSION=v3.1.2 | |||
|
|
|||
| # minikube settings | |||
| MINIKUBE_VERSION=v1.14.1 | |||
| MINIKUBE_VERSION=v1.16.0 | |||
There was a problem hiding this comment.
@obnoxxx currently, we are sticking to the available release once the version is tested in the CI. if there is any regression in the latest available release we might end up in the CI issues which could block the merging of the PR.
|
/retest all |
|
/test ci/centos/mini-e2e-helm |
|
@Mergifyio rebase |
|
Command
|
|
@Mergifyio rebase The logs of the CI jobs have been removed, we will need new logs in order to fix issues. |
|
Command
|
|
/test ci/centos/mini-e2e-helm |
|
@Mergifyio rebase The logs of the CI jobs have been removed, we will need new logs in order to fix issues. |
|
Command
|
|
https://github.com/kubernetes/minikube/tree/v1.17.1 has been released and includes a fix for #1840 |
|
/test ci/centos/mini-e2e-helm |
|
/test ci/centos/mini-e2e |
|
/test ci/centos/upgrade-tests-cephfs |
mergify
bot
dismissed
nixpanic’s stale review
Pull request has been modified.
|
The e2e tests seem to fail consistently with the following error: Possibly minikube has tightened its network policy and the node-plugin can not connect to the MDS anymore? During e2e testing, we use two different namespaces for the Ceph cluster and to-test ceph-csi services. Maybe that is problematic... |
|
@nixpanic something has changed in minikube 1.17.1 am not able to run ceph fs commands from the toolbox pod. |
The toolbox pod can access the CephFS MDS, I think. Commands like However, it seems to run into a timeout: Testing communications between toolbox, mds, mgr does not show any restrictions. Installed I have not been able to identify the issue when running |
Analysis It took around 4 minutes to umount the targetPath after that the NodePublish is failing with below error as the umount is already done cephcsi should return success not the Internal server error. |
|
ci/centos/mini-e2e/k8s-1.20 failed with a timeout in the test suite again: Will increase the timeout to 90 minutes. |
mergify
bot
dismissed stale reviews from nixpanic and humblec
Pull request has been modified.
|
ci/centos/mini-e2e-helm/k8s-1.20 failed with some unexpected error: |
|
/retest ci/centos/mini-e2e-helm/k8s-1.20 |
|
/retest ci/centos/mini-e2e/k8s-1.20 |
Failed due to #1795 |
|
/retest ci/centos/mini-e2e-helm/k8s-1.20 |
Resizing a CephFS PVC failed: Maybe the provisioner got hung or something, but I did not immediately see it in the logs. |
|
/retest ci/centos/mini-e2e-helm/k8s-1.20 |
|
/test ci/centos/mini-e2e-helm/k8s-1.20 |
|
@nixpanic looks like merging this PR can affect the cephfs e2e testing. When looking at multiple logs, if feel now cephfs is taking a lot of time for each operation. Merging the PR will make the CI flaky. |
|
@Mergifyio rebase |
|
Sorry but I didn't understand the command. |
|
@Mergifyio rebase |
As minikube 1.17.1 is released and updating the minikube to the latest available version. Signed-off-by: Madhu Rajanna <[email protected]>
It seems that recent minikube versions changed something in the
networking, and that prevents
$ ceph fs subvolumegroup create myfs testGroup
from working. Strangely RBD is not impacted. Possibly something is
confusing the CephMgr pod that handles the CephFS admin commands.
Using the "bridge" CNI seems to help, CephFS admin commands work with
this in minikube.
Signed-off-by: Niels de Vos <[email protected]>
Sometimes testing takes more than 60 minutes. When that is the case, the 60 minute timeout causes a golang panic in the test suite. Signed-off-by: Niels de Vos <[email protected]>
|
Command
|
| @@ -162,6 +162,7 @@ CONTAINER_CMD=${CONTAINER_CMD:-"docker"} | |||
| MEMORY=${MEMORY:-"4096"} | |||
| CPUS=${CPUS:-"$(nproc)"} | |||
| VM_DRIVER=${VM_DRIVER:-"virtualbox"} | |||
| CNI=${CNI:-"bridge"} | |||
There was a problem hiding this comment.
@nixpanic whats the default CNI ? if its not bridge may be the change for CNI to bridge causing the E2E to take lots of time to complete , iow, we are hitting some performance issues being the CNI bridge
There was a problem hiding this comment.
The default CNI is "auto"... There seems to be some logic in minikube somewhere that decides what CNI to use (maybe dependent on the Kubernetes version and hypervisor?).
It is possible that the minikube VM needs more resources with this rebase. Those are settings in the ci/centos branch, so we could increase those, depending on the current values and bare metal systems in the CI.
|
/retest ci/centos/mini-e2e-helm/k8s-1.20 |
Failed to delete a volume, the PVC that needs to be deleted seems to be gone. Looks like a bug in the test case: |
Madhu-1
added
the
ready-to-merge
As minikube 1.17.1 is released and updating the minikube to the latest available version.
Signed-off-by: Madhu Rajanna [email protected]