Building cluster in existing VPC takes over VPC and IGW

[erkolson]

I'm trying to use an existing VPC to test upgrading from v1.6.1 to v1.7.3. This VPC contains my dev/qa kubernetes cluster running 1.6.1 managed by kops.

I've built the test cluster at 1.6.1 and all looks great. When I run kops update cluster (using kops 1.7.0), it wants to make the expected changes but also the following:

  InternetGateway/k8s-17-test.example.com
  	Name                	 kubernetes-devqa.example.com -> k8s-17-test.example.com

  VPC/k8s-17-test.example.com
  	Name                	 kubernetes-devqa.example.com -> k8s-17-test.example.com
  	Tags                	 {Name: kubernetes-devqa.example.com} -> {kubernetes.io/cluster/k8s-17-test.example.com: shared, KubernetesCluster: k8s-17-test.example.com, Name: k8s-17-test.example.com}

I think the behavior is wrong. It did not create the VPC or the IGW, it should leave it alone. Is kops expected to support more than one cluster in a VPC?

One more note, I also see the same changes when I run kops update cluster with kops v1.6.1.

[KashifSaadat]

Hi @erkolson. The dry-run will alert for the Name and Tag changes but will not actually modify those resources. There is a fix for it in progress here: #3184

[chrislovecnm]

Any update on this issue? Can we close?

[danieljamesscott]

I'm still seeing this issue

[KashifSaadat]

Hi @danieljamesscott, which version of the Kops binary are you using? Can you provide a snippet of the kops update cluster dryrun command so I can see what resources it is saying will be updated?

[danieljamesscott]

dscott@localhost:~$ $ kops version
Version 1.8.0 (git-5099bc5)

...
Will modify resources:
  InternetGateway/kube.dan.example.com
        Name                     dan-igw -> kube.dan.example.com

  SSHKey/qmg-aws
        PublicKey                <nil> -> <resource>
        KeyFingerprint           <<OMITTED>> -> <<OMITTED>>

  VPC/kube.dan.example.com
        Tags                     {} -> {kubernetes.io/cluster/kube.dan.example.com: shared}

Must specify --yes to apply changes

dscott@localhost:~$ $ 

So it's showing that it will change the name of the gateway. For the SSH key, I created the cluster with no ssh key, then added an 'sshKeyName' entry to the spec - possibly it needs to re-upload a public SSH key?

EDIT: I'm fine with the VPC tagging, it's mainly the IGW name that's bothering me - the SSH key is probably a separate issue.

[KashifSaadat]

Hi @danieljamesscott, thanks for providing the output.

I've tested with the specific kops version you were using (git hash 5099bc5) and was able to recreate the issue. I then built kops from source, retested and found that both the IGW and SSHKey changes were no longer shown, so it seems this has been fixed now.

Would you be able to test and confirm by building kops off the master branch?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[MadWombat]

I am on 1.8.1 and I am still seeing this issue.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close