vSphere support for binary deploys #1747
Conversation
|
The new getting started guide assumes that a binary release is available that contains the updated cluster scripts. When this PR is merged, there will be a short window where the current binary release will not contains those scripts. Are you planning to release these binary release very often, or should I include a note in the getting started guide? |
|
@pietern I'm updating the binary release by hand right now. Over the next week we'll get both nightly builds published and official releases. I'll cut and push a new build after this goes in. |
| @@ -0,0 +1,9 @@ | |||
| # This runs highstate on the ALL nodes. | |||
| # | |||
| # Used from the vSphere provider. The IP addresses of the minons are passed to | |||
There was a problem hiding this comment.
I'd take off the vSphere specific comment here and instead just say that this is necessary for any cluster set up where the minion addresses are passed on the command line to the apiserver.
|
This looks awesome! Just some minor nits, really. FYI -- I filed #1749 to try and remove some of the duplicate boilerplate across provider scripts. |
|
Thanks for the thorough review, I'll address the comments later this weekend. |
pietern
force-pushed
the
vsphere-binary-deploy
branch
from
5f49a53 to
286862a
Compare
|
This new set of commits should address all comments. |
|
Hi Peter -- I'll review this first thing today after I make it through my inbox. I was out all day yesterday unfortunately. |
|
@pietern I'm ready to get this in if you can do a final rebase. Looks like things have drifted a bit. Thanks! |
|
I'm out this week, back on Monday. I'll rename and repush then. Sent from my iPhone
|
|
Don't know how Travis is broken, this change doesn't affect any go code. |
|
Thanks for updating. I'm at an airport now so it is hard to do anything, but I'll test this out to make sure it doesn't break GCE or Vagrant tomorrow and then merge. Is it ready to go from your end? |
|
Found an issue with kube-push, please stand by. |
|
Fixing #1783 for vSphere. |
|
@pietern I just cut v0.4.2 as we needed it for other reasons. Once this gets in I'll cut v0.4.3. |
There now are reactor files to run highstate on: * New nodes only * Master nodes * Minion nodes
This displays a progress report, so any slowness can be attributed.
In preparation for kubernetes#1402.
pietern
force-pushed
the
vsphere-binary-deploy
branch
from
024c2bf to
5b22dd7
Compare
|
I'll test and look to merge now. As for the release -- I'm cherry-picking stuff into the release-0.4 branch and then tagging/releasing from that. |
|
Tested with GCE e2e and bringing vagrant up. Looking good so merging. |
vSphere support for binary deploys
|
Thanks for seeing this through!! 👍 |
|
Thanks Joe! |
|
This patch works perfect as expected on my Kubernetes 0.5.4 binary deployment. Thanks a lot. |
[release-4.12] OCPBUGS-20113: UPSTREAM: <carry>: Do not allow nodes to set forbidden openshift labels
Aside form working with binary deploys, this PR changes the following two items (vSphere only):
state.highstateon every node whenever any minion starts. This solves a timing issue introduced with the binary deploys; the master can be done with provisioning much sooner than the minions, meaning the apiserver configuration won't be seeded with the right list of minion IPs. This is solved by runningstate.highstateon minion starts, which causes the apiserver configuration to be rewritten and the daemon to be cycled every time a new minion starts.http://<ip>:10250/healthz. The check that is executed from the GCE scripts depends the minions having completed provisioning before the master becomes available. This allows for the case where docker is not yet provisioned, while the master is already responding to requests, which in turn can cause the sanity check to fail.cc #1732