Change:
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

Discussion:
### Setup <del> By default, the Vagrant setup will create a single kubernetes-master and 3 kubernetes-minions.  You can control the number of minions that are instantiated via an environment variable 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. ``` export KUBERNETES_NUM_MINIONS=3 ``` To start your local cluster, open a terminal window and run: </del> <ins> By default, the Vagrant setup will create a single kubernetes-master and 3 kubernetes-minions. Each VM will take 512 MB, so make sure you have at least 2 GB of free memory. To start your local cluster, open a shell and run: </ins> ``` cd kubernetes

[vagrant@kubernetes-minion-1] $ sudo journalctl -r -u kubelet ``` <ins> ### Interacting with your Kubernetes cluster with Vagrant. With your Kubernetes cluster up, you can manage the nodes in your cluster with the regular Vagrant commands. </ins> To push updates to new Kubernetes code after making source changes: ``` vagrant provision ``` <del> To shutdown and then restart the cluster: </del> <ins> To stop and then restart the cluster: </ins> ``` vagrant halt vagrant up

To destroy the cluster: ``` <del> vagrant destroy -f </del> <ins> vagrant destroy </ins> ``` <del> You can also use the cluster/kube-*.sh scripts to interact with vagrant based providers just like any other hosting platform for kubernetes. </del> <ins> Once your Vagrant machines are up and provisioned, the first thing to do is to check that you can use the `kubecfg.sh` script. Set the `KUBERNETS_PROVIDER` environment variable and try to list the minions: </ins> ``` <del> cd kubernetes modify cluster/kube-env.sh: KUBERNETES_PROVIDER="vagrant" </del> <ins> $ export KUBERNETES_PROVIDER=vagrant $ ./cluster/kubecfg.sh list /minions Minion identifier ---------- 10.245.2.4 10.245.2.3 10.245.2.2 ``` ### Interacting with your Kubernetes cluster with the `kube-*` scripts. Alternatively to using the vagrant commands, you can also use the `cluster/kube-*.sh` scripts to interact with the vagrant based provider just like any other hosting platform for kubernetes. </ins> <del> ## build the binary required by kubecfg.sh </del> <ins> You need to build the binary required by `kube*` scripts: ``` </ins> hack/build-go.sh <ins> ``` Then bring up a vagrant cluster </ins> <del> cluster/kube-up.sh => brings up a vagrant cluster cluster/kube-down.sh => destroys a vagrant cluster cluster/kube-push.sh => updates a vagrant cluster cluster/kubecfg.sh => interact with the cluster </del> <ins> ``` cluster/kube-up.sh ``` Destroy the vagrant cluster ``` cluster/kube-down.sh ``` Update the vagrant cluster ``` cluster/kube-push.sh ``` Interact with the cluster ``` cluster/kubecfg.sh </ins> ``` ### Authenticating with your master <del> To interact with the cluster, you must authenticate with the master when running cluster/kubecfg.sh commands. </del> <ins> When using the vagrant provider in Kubernetes, the `cluster/kubecfg.sh` script will cache your credentials in a `~/.kubernetes_auth_vagrant` file so you will not be prompted for them in the future. </ins> <del> If it's your first time using the cluster, your first invocation of cluster/kubecfg.sh will prompt you for credentials: </del> <ins> ``` cat ~/.kubernetes_auth_vagrant { "User": "vagrant", "Password": "vagrant"} ``` You should now be set to use the `cluster/kubecfg.sh` script. For example try to list the minions that you have started with: </ins> ``` <del> cd kubernetes </del> cluster/kubecfg.sh list minions <del> Please enter Username: vagrant Please enter Password: vagrant </del> <ins> ``` ### Running containers Your cluster is running, you can list the minions in your cluster: ``` $ cluster/kubecfg.sh list /minions </ins> Minion identifier ---------- <ins> 10.245.2.4 10.245.2.3 10.245.2.2 </ins> ``` <del> The kubecfg.sh command will cache your credentials in a .kubernetes_auth file so you will not be prompted in the future. </del> <ins> Now start running some containers! You can now use any of the cluster/kube-*.sh commands to interact with your VM machines. Before starting a container there will be no pods, services and replication controllers. </ins> ``` <del> cat ~/.kubernetes_auth {"User":"vagrant","Password":"vagrant"} </del> <ins> $ cluster/kubecfg.sh list /pods ID                  Image(s)            Host                Labels              Status ----------          ----------          ----------          ----------          ---------- $ cluster/kubecfg.sh list /services ID                  Labels              Selector            Port ----------          ----------          ----------          ---------- $ cluster/kubecfg.sh list /replicationControllers ID                  Image(s)            Selector            Replicas ----------          ----------          ----------          ---------- </ins> ``` <del> If you try Kubernetes against multiple cloud providers, make sure this file is correct for your target environment. </del> <ins> Start a container running nginx with a replication controller and three replicas: ``` $cluster/kubecfg.sh -p 8080:80 run dockerfile/nginx 3 myNginx ``` </ins> <del> ### Running a container </del> <ins> When listing the pods, you will see that three containers have been started and are in Waiting state: </ins> <del> Your cluster is running, and you want to start running containers! </del> <ins> ``` $ cluster/kubecfg.sh list /pods ID                                     Image(s)            Host                    Labels                          Status ----------                             ----------          ----------              ----------                      ---------- 781191ff-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.4/10.245.2.4   replicationController=myNginx   Waiting 7813c8bd-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.2/10.245.2.2   replicationController=myNginx   Waiting 78140853-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.3/10.245.2.3   replicationController=myNginx   Waiting ``` </ins> <del> You can now use any of the cluster/kube-*.sh commands to interact with your VM machines. </del> <ins> You need to wait for the provisioning to complete, you can monitor the minions by doing ``` $ vagrant ssh minion-1 $ sudo docker images REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE <none>              <none>              96864a7d2df3        26 hours ago        204.4 MB google/cadvisor     latest              e0575e677c50        13 days ago         12.64 MB kubernetes/pause    latest              6c4579af347b        8 weeks ago         239.8 kB ``` Once the docker image for nginx has been downloaded, the container will start and you can list it: ``` $ sudo docker ps CONTAINER ID        IMAGE                     COMMAND                CREATED             STATUS              PORTS                    NAMES dbe79bf6e25b        dockerfile/nginx:latest   "nginx"                21 seconds ago      Up 19 seconds                                k8s--mynginx.8c5b8a3a--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1.etcd--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1--fcfa837f fa0e29c94501        kubernetes/pause:latest   "/pause"               8 minutes ago       Up 8 minutes        0.0.0.0:8080->80/tcp     k8s--net.a90e7ce4--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1.etcd--7813c8bd_-_3ffe_-_11e4_-_9036_-_0800279696e1--baf5b21b aa2ee3ed844a        google/cadvisor:latest    "/usr/bin/cadvisor -   38 minutes ago      Up 38 minutes                                k8s--cadvisor.9e90d182--cadvisor_-_agent.file--4626b3a2 65a3a926f357        kubernetes/pause:latest   "/pause"               39 minutes ago      Up 39 minutes       0.0.0.0:4194->8080/tcp   k8s--net.c5ba7f0e--cadvisor_-_agent.file--342fd561 ``` Going back to listing the pods, services and replicationControllers, you now have: ``` $ cluster/kubecfg.sh list /pods ID                                     Image(s)            Host                    Labels                          Status ----------                             ----------          ----------              ----------                      ---------- 781191ff-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.4/10.245.2.4   replicationController=myNginx   Running 7813c8bd-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.2/10.245.2.2   replicationController=myNginx   Running 78140853-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.3/10.245.2.3   replicationController=myNginx   Running $ cluster/kubecfg.sh list /services ID                  Labels              Selector            Port ----------          ----------          ----------          ---------- $ cluster/kubecfg.sh list r/eplicationControllers ID                  Image(s)            Selector                        Replicas ----------          ----------          ----------                      ---------- myNginx             dockerfile/nginx    replicationController=myNginx   3 </ins> ``` <del> cluster/kubecfg.sh list /pods cluster/kubecfg.sh list /services cluster/kubecfg.sh list /replicationControllers cluster/kubecfg.sh -p 8080:80 run dockerfile/nginx 3 myNginx ## begin wait for provision to complete, you can monitor the minions by doing vagrant ssh minion-1 sudo docker images ## you should see it pulling the dockerfile/nginx image, once the above command returns it sudo docker ps ## you should see your container running! exit ## end wait </del> <ins> We did not start any services, hence there is none listed. But we see three replicas displayed properly. Check the [guestbook](examples/guestbook/README.md) application to learn how to create a service. You can already play with resizing the replicas with: </ins> <del> ## back on the host, introspect kubernetes! cluster/kubecfg.sh list /pods cluster/kubecfg.sh list /services cluster/kubecfg.sh list /replicationControllers </del> <ins> ``` $ cluster/kubecfg.sh resize myNginx 2 $ cluster/kubecfg.sh list /pods ID                                     Image(s)            Host                    Labels                          Status ----------                             ----------          ----------              ----------                      ---------- 7813c8bd-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.2/10.245.2.2   replicationController=myNginx   Running 78140853-3ffe-11e4-9036-0800279696e1   dockerfile/nginx    10.245.2.3/10.245.2.3   replicationController=myNginx   Running </ins> ``` Congratulations!

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