Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

Hm, my CLA should be on file. I'll look into that.

/cc @thockin @brendandburns. an one of you suggest a reviewer?

I will try this in morning.

Can you tell me what version of vagrant you tested this against? I was not seeing ssh problems earlier this week, so
I want to know if there is a drift somewhere.

@jameskyle - I am confused by this change. Were you actually seeing errors when invoking:

$ vagrant ssh master

I had never received an error in the past, so I am confused on the issue that is being resolved.

Reread the issue, just remove the WARNING log output, then this will be good to go.

Thanks!

Will do, but to answer the other questions:

$ vagrant version
Installed Version: 1.7.2
Latest Version: 1.7.2

Warning removal incoming.

I'm curious about you not seeing an error with 'vagrant ssh' though. Was that accurate?

@jameskyle - I was not seeing an error.

$ uname -a
Linux localhost.localdomain 3.18.7-100.fc20.x86_64 #1 SMP Wed Feb 11 19:01:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ VBoxManage -version
4.3.22r98236
$ vagrant version
Installed Version: 1.7.2
Latest Version: 1.7.2

You're running an up-to-date version of Vagrant!

@jameskyle - you build a release before trying to up the boxes, right?

@derekwaynecarr Oh, I have an idea. Do you set your KUBE_TEMP variable? If you do, then the temp directory and generated scripts persist and the error won't appear.

Yes, they're all built. the error comes from vagrants inability to find the specified provision script (which is deleted at the end of a kube-up.sh run). It doesn't just happen with 'vagrant ssh', but with any command as it's a syntax error. The provisioner is set to: ENV['KUBE_TEMP']/master-start.sh. But since KUBE_TEMP is only set in the $KUBE_PROVIDER/util.sh script and the master-start.sh is deleted after the kube-up.sh script runs, $KUBE_TEMP is not set.

$ vagrant ssh master
There are errors in the configuration of this machine. Please fix
the following errors and try again:

shell provisioner:
* `path` for shell provisioner does not exist on the host system: /master-start.sh

Running:

$ env | grep KUBE_TEMP

returns nothing.

Either way, I am good with this PR now, but stumped why I was not seeing it.

@smarterclayton - can you merge this now assuming his CLA with googlebot is fine.

I unfortunately can't check the CLA - would need one of the others to do that.

@jameskyle I haven't been able to find a CLA, can you see it at: https://cla.developers.google.com/clas

@vmarmol We've signed the CLA, but it was before they changed the CLA system. dbsmith, on #google-containers chan in freenode, looked into it and said he saw the cla in the 'old' system and was inquiring what it would take to move it to the 'new' system (if possible).

I'm waiting for word back from smith in the mean time.

edit

TL;DR

We've signed the CLA, but it's not in the system the bot checks.

Aaaah this is a corporate CLA, now I found it. Looks good :) thanks for letting me know! and thanks for double checking @smarterclayton. Merging.