Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix mismatch in SecurityGroups handling with launch templates #9288

Merged
merged 2 commits into from
Jun 10, 2020

Conversation

johngmyers
Copy link
Member

When launch templates are enabled, they will be unnecessarily updated when they have a security group and are in a private subnet.

/kind bug
Targeted for 1.18

@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jun 6, 2020
@k8s-ci-robot k8s-ci-robot added the area/provider/aws Issues or PRs related to aws provider label Jun 6, 2020
@hakman
Copy link
Member

hakman commented Jun 8, 2020

/retest

@hakman
Copy link
Member

hakman commented Jun 9, 2020

@johngmyers This change was intentional, as best practice. I think for Mixed instance policies is the only possibility.
Does this happen only first time or during subsequent deployments also?

@johngmyers
Copy link
Member Author

@hakman Every kops update cluster --yes updates the launch template, as it thinks it needs to add the SecurityGroup back in. It causes the lifecycle tests to fail when I enable launch templates by default.

@johngmyers
Copy link
Member Author

@hakman Notice I'm changing Find(), not RenderAWS().

@hakman
Copy link
Member

hakman commented Jun 10, 2020

@hakman Notice I'm changing Find(), not RenderAWS().

Thanks. Looks pretty good. Let me know what you think about the other comment and we can get this in.

@kubernetes kubernetes deleted a comment from johngmyers Jun 10, 2020
@@ -208,6 +208,10 @@ func (t *LaunchTemplate) Find(c *fi.Context) (*LaunchTemplate, error) {
actual.SecurityGroups = append(actual.SecurityGroups, &SecurityGroup{ID: id})
}
}
// In older Kops versions, security groups were added to LaunchTemplateData.SecurityGroupIds
for _, id := range lt.LaunchTemplateData.SecurityGroupIds {
actual.SecurityGroups = append(actual.SecurityGroups, &SecurityGroup{ID: fi.String("legacy-" + *id)})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the "legacy-" prefix?
I thought we just want to move the SGs from LaunchTemplateData.SecurityGroupIds to LaunchTemplateData.NetworkInterfaces[0].Groups.

Copy link
Member Author

@johngmyers johngmyers Jun 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Find() builds a representation of the "actual" object, the state as it currently exists. The caller then diffs that against the representation of the "expected" object, the state that was built from the config in the state store. Only if those two differ does it call RenderAWS, which would build a new launch template to attach to the ASG.

If we did not add the "legacy-" prefix then the actual could equal the expected and thus the caller would believe that no changes were necessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this particular case, if SG is in the legacy place, I think the LT should not change. Only on next change the SG will be moved together with something else to the new location.

I guess it is debatable if we want this or not. Your choice here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the change should happen when kops is upgraded, not when some unrelated configuration is changed days or months later. To assist diagnosis the effect should be close to the cause.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Then this should be merged as is.

@hakman
Copy link
Member

hakman commented Jun 10, 2020

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 10, 2020
@rifelpet
Copy link
Member

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: johngmyers, rifelpet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 10, 2020
@k8s-ci-robot k8s-ci-robot merged commit c493264 into kubernetes:master Jun 10, 2020
@k8s-ci-robot k8s-ci-robot added this to the v1.19 milestone Jun 10, 2020
@johngmyers johngmyers deleted the launch-template-mismatch branch June 10, 2020 16:27
k8s-ci-robot added a commit that referenced this pull request Jun 10, 2020
…88-upstream-release-1.18

Automated cherry pick of #9288: Fix mismatch in SecurityGroups handling with launch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/provider/aws Issues or PRs related to aws provider cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants