GCE e2e build/test passed for commit 1f9d882f96e61458941045b3111a84fbf38a3dfa.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Still have to update cert:
reflector.go:136] Failed to list *api.Endpoints: Get https://10.247.0.1:443/api/v1beta3/endpoints: x509: certificate is valid for 10.245.1.2, not 10.247.0.1

@derekwaynecarr are you going to update the cert as part of this change?

Yes. I just ran out of time.

On Tuesday, June 30, 2015, Robert Bailey notifications@github.com wrote:

@derekwaynecarr https://github.com/derekwaynecarr are you going to
update the cert as part of this change?

—
Reply to this email directly or view it on GitHub
#10562 (comment)
.

Assigning to yourself. Assign someone else when this is ready.

This is a targeted PR that affects just the Vagrant deployment's usage of Salt.

I know @eparis has a solution that would enable AWS, but my bias is that should be a follow-on if time is an issue (also at that time, we would need to bring back cert_ip in vagrant pillar).

Either way, this fixes kube2sky on vagrant.

My hopefully generic solution which solves the problem for all is at:
eparis@ab52932

But I think this patch is fine for 0.20.x We should solve it for everyone, but this one only makes things a little worse. (I say worse, because the more we build scripts and hacks which are cloud provider only the more we build a brittle impossible to manage system, so I argue we do more in salt, less in 'provision', and less 'per cloud provider' everywhere.

@zmerlynn - this is ready for your review... tried to make the most targeted fix to lower risk. we can do a cleaner, more risky change as follow-on per @eparis

GCE e2e build/test passed for commit 3ade2ef.

• Build Log
• Test Artifacts
• Internal Jenkins Results

GCE e2e build/test passed for commit 8fdfdd9.

• Build Log
• Test Artifacts
• Internal Jenkins Results

LGTM

cc @eparis for another review

cc @dchen1107 for rubber stamp

LGTM

Can this get merged today?

@brendandburns: Since you seem to be awake, too, feel like signing off on this? I'd like to get it in ASAP, too.

Friendly poke to merge?

Rebase?

Pending a rebase and waiting on @dchen1107's "ok-to-merge"

This is rebased and now works with @justinsb changes for how it uses the sans for certs. Be good to see this merged ;-)

GCE e2e build/test passed for commit cfb8ba05ddd583872d7e43929ade633a41334fd4.

• Build Log
• Test Artifacts
• Internal Jenkins Results

GCE e2e build/test passed for commit e2ddd2d.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Still LGTM

still LGTM

This is hitting core in literally exactly one place and is otherwise confined to vagrant. Let's merge it.

/cc @vmarmol, the on-call today.

I'm still getting

Validating master
Validating minion-1
........
Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: x509: certificate is valid for 192.168.56.101, 10.247.0.1, not 10.245.1.2

when running

export KUBERNETES_PROVIDER=vagrant
cluster/kube-up.sh

on the v0.21.1.

@derekwaynecarr though I'm currently trying to repeat this on a clean installation. I'll let you know.

Yep, the problem still persists.

Are you using virtual box or VMware?

What host OS are you running from?

On Thursday, July 9, 2015, Alexey Kupershtokh notifications@github.com
wrote:

Yep, the problem still persists.

—
Reply to this email directly or view it on GitHub
#10562 (comment)
.

@AlexeyKupershtokh - can you remove the ~/.kube directory and try to reproduce?

See my comment here for steps I followed:

#10900 (comment)

I'm running ubuntu 14.04.2 lts 64 bit, virtualbox 4.3.28.
Trying to repeat using your way. I'll let you know any results in about 12h.

Thanks for your help! It's possible there is some race condition or
something that is not working deterministically all the time, so having
outside help with error details is always a big help.

On Thu, Jul 9, 2015 at 1:11 PM, Alexey Kupershtokh <notifications@github.com

wrote:

I'm running ubuntu 14.04.2 lts 64 bit, virtualbox 4.3.28.
Trying to repeat using your way. I'll let you know any results in about
12h.

—
Reply to this email directly or view it on GitHub
#10562 (comment)
.

Yep, still the same result.
I've also performed a test with logging the *SANS env variable.
It has the value of IP:10.247.0.1,DNS:kubernetes,DNS:kubernetes.default,DNS:kubernetes.default.svc,DNS:kubernetes.default.svc.cluster.local,DNS:kubernetes-master in my case.
As far as I understand the cert_ip is vagrant eth1 ip which is 192.168.56.101.
So there is really no MASTER_IP (which is "10.245.1.2") that is used when accessing the cluster from the host machine.
If I add the MASTER_IP to the *SANS list, everything goes fine.

So you are getting a different eth1 ip than me. I will look to put the
certip grain back to resolve and cc you on the PR to verify it fixes for
you.

On Thursday, July 9, 2015, Alexey Kupershtokh notifications@github.com
wrote:

Yep, still the same result.
I've also performed a test with logging the *SANS env variable.
It has the value of
IP:10.247.0.1,DNS:kubernetes,DNS:kubernetes.default,DNS:kubernetes.default.svc,DNS:kubernetes.default.svc.cluster.local,DNS:kubernetes-master
in my case.
As far as I understand the cert_ip is vagrant eth1 ip which is
192.168.56.101.
So there is really no MASTER_IP (which is "10.245.1.2") that is used when
accessing the cluster from the host machine.
If I add the MASTER_IP to the *SANS list, everything goes fine.

—
Reply to this email directly or view it on GitHub
#10562 (comment)
.