Change:
curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -M -N # Install salt-api <del> # </del> <ins> # # This is used to provide the network transport for salt-api yum install -y python-cherrypy </ins> # This is used to inform the cloud provider used in the vagrant cluster yum install -y salt-api # Set log level to a level higher than "info" to prevent the message about

Discussion:
I use ubuntu 13.04 system. (kernel version 3.8.0-44-generic, vagrant version 1.6.5, virtualbox version : 4.3.20) I download the kubernetes tar file version 0.5.4. and then, I run script file "/cluster/kube-" master, minion-1,2,3 each machine instance has been created. but when "" script file run, it could loop forever. the message is "Waiting for each minion to be registered with cloud provider" maybe during provision of cluster, it occurs some problems. but I don't know what is problem. please let me know to solve problem.
Related to . it loops trying to detect minions, but master node can't find any. I tried with the git master branch, various commits picked from the time doc has been updated, v0.6.0, v0.5.5, v0.5.4, all without success. I find it hard to believe that it's broken since that time, but I can't figure out what else could cause that problem.
I'm currently tracking this down as well. I believe it is related to commit (which was cherry-picked from ). If you run do you see that the kubelet is running, but is unable to send events to the kube-apiserver? Probably due to x509 certificate signed by an unknown authority? Also, please confirm that no minions at all register by running could you try running with v0.5.0? I'm not at my desk at the moment to work on a proper fix just yet, assuming the commit I mentioned is the problem.
yes, I ran list minions everytime, and the list was empty. Tried to build v0.5, but got the error . Getting late here, will try again another time. Thanks for looking into it!
I've made some headway here today. There are a few different things at play, I think. 1) The kube-apiserver is provided /dev/null as tokenauthfile. It should just be omitted. 2) The kubelet only has an empty /var/lib/kubelet/kubernetes_auth file. It should be populated appropriately with the CA and certs 3) 's on the group pointed me to the last piece of the puzzle.

It appears that the minions are registered with salt. For some reason on the master, the python cherrypy module is missing, and as far as I can tell, the salt rest interface never comes up during the provisioning. I, for now, hacked in a to the script and that appeared to work. I'll try to come up with a full solution and submit a PR.
Seconded. I independently went through the same steps as ryaneleary. I don't have too much to add on top of his comments. There are some bits of authorization around the apiserver, but they seem unrelated to minion registration. Nonetheless, I did try to implement token generation for it for Vagrant as part of my flailing around with this problem. I might send a PR for that in case it's useful on its own. The real issue, though, was the salt-api service. As ryan mentioned, that service depends on python-cherrypy, which somehow wasn't installed as part of "yum install -y salt-api" in the setup scripts. I tried to track down what happened there. All of the RPM spec files I can find for the salt-api package are (a) ancient and (b) contain a "Requires: python-cherrypy" line. However, the package that's actually installed on my system is versioned 2014.7.0-3.fc20 and does not have the dependency. I can't find the corresponding SRPM for it. yumdownloader --source gives me an older version. So, in summary, this looks to me like a Fedora bug. I'll file a bug with them once I figure out how to access their bug tracker. I think it makes sense to apply ryan's solution in the meantime, so that no one else trips over this issue.
Upstream bug report:
Shouldn't we move to CoreOS for the vagrant system? I do not understand why Fedora, which is not supported anymore, was chosen for this example :)
/cc
I can try to reproduce and fix-up any issue described here on Monday. The environment was stable prior to the holiday when I was working from HEAD, so it should be quick to nail down. - can you elaborate on your Fedora not being supported comment? The Fedora based environment has been supported for months now.

I have been debating about adding CentOS support, but when I originally authored the environment, it was intended to help support compatibility in a distribution in the broader RHEL ecosystem. If someone wants to submit a PR to support an additional Vagrant environment using CoreOS that is fine, but we need someone to take ownership of supporting it. We at Red Hat will probably add an Atomic host (CentOS 7 Atomic) at some point in the future as a supported Vagrant provider. The Vagrantfile structure is setup today to allow you to provide other boxes, but it would also require custom provisioners, etc.
Sorry, please discard my comment, got it wrong.
There appears to have been a packaging change in that caused the module to not get included, and as a result, the cloud_provider used in the vagrant env is not able to contact the salt-server to find out the available minions. Submitting a PR now. Thanks for reporting the issue.