Code change:
hack/e2e-test.sh ``` ### Troubleshooting #### I just created the cluster, but I am getting authorization errors! <del> You probably have an incorrect ~/.kubernetes_auth file for the cluster you are attempting to contact. </del> <ins> You probably have an incorrect ~/.kubernetes_auth_vagrant file for the cluster you are attempting to contact. </ins> ``` <del> rm ~/.kubernetes_auth </del> <ins> rm ~/.kubernetes_auth_vagrant </ins> ``` <del> And when using kubecfg.sh, provide the correct credentials: </del> <ins> After using kubecfg.sh make sure that the correct credentials are set: </ins> ``` <del> Please enter Username: vagrant Please enter Password: vagrant </del> <ins> cat ~/.kubernetes_vagrant_auth { "User": "vagrant", "Password": "vagrant" } </ins> ``` <del> #### I just created the cluster, but I do not see my container running! </del> <ins> #### I just created the cluster, but I do not see my container running ! </ins> If this is your first time creating the cluster, the kubelet on each minion schedules a number of docker pull requests to fetch prerequisite images.  This can take some time and as a result may delay your initial pod getting provisioned. <del> #### I changed Kubernetes code, but it's not running! </del> <ins> #### I changed Kubernetes code, but it's not running ! </ins> <del> Are you sure there was no build error?  After running $ vagrant provision, scroll up and ensure that each Salt state was completed successfully on each box in the cluster. </del> <ins> Are you sure there was no build error?  After running `$ vagrant provision`, scroll up and ensure that each Salt state was completed successfully on each box in the cluster. </ins> It's very likely you see a build error due to an error in your source files! <ins> #### I want to change the number of minions ! You can control the number of minions that are instantiated via the environment variable `KUBERNETES_NUM_MINIONS` on your host machine.  If you plan to work with replicas, we strongly encourage you to work with enough minions to satisfy your largest intended replica size.  If you do not plan to work with replicas, you can save some system resources by running with a single minion. You do this, by setting `KUBERNETES_NUM_MINIONS` to 1 like so: ``` export KUBERNETES_NUM_MINIONS=1 ``` </ins>  No newline at end of file

Related discussion:
text: Which jobs are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /priority important-soon /cc /cc /milestone v1.18 /sig release
/assign
This is failing because a 1.18 release for CRI tools doesn't exist yet. I can tweak the test job arguments to skip this later.
(As a note, this job is important, but not ) /remove-priority critical-urgent /priority important-soon
Do we need to remove the job from dashboard?
-- No. I'll work on fixing the job later today.
I've started to investigate, but I haven't yet reproduced the new error locally: This is likely related to a recent refactor of the package that handles interpreting deb/rpm package versions. As is not currently in use, I'm moving this to the milestone. /milestone v1.19
the version issue is fixed via The test is now failing because it tries to download cri-tools v1.18.0: which I think is related to this code part:
Updating testgrid link here: Any updates here /retitle [Flaky Test] build-packages-debs (ci-release-build-packages-debs) /kind flaky-test
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Updating testgrid link here: /kind flaky-test Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind flake
I was assuming that is working on this issue. I can jump in if you want and do not find the time to work on it. :)
/assign /unassign Sascha -- Can you take this? I thought I was going to have time to look at this, but it's been a while.
Sure, the reason for the failing test seems to have changed, I'm on it.
Fix is incoming in