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

Spotinst: Do not log unmatched groups as warning messages #6025

Merged
merged 1 commit into from
Nov 9, 2018

Conversation

liranp
Copy link
Contributor

@liranp liranp commented Oct 31, 2018

When executing kops rolling-update cluster without instance group name/role, if the user has multiple Elastigroups that aren't managed by kops, kops prints a lot of less than worthwhile warning messages:

W1030 21:29:37.226502 21141 resources.go:109] Found group with no corresponding instance group "name-of-the-elastigroup"

This PR changes the logging level from Warning to Info.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Oct 31, 2018
@KashifSaadat
Copy link
Contributor

Hey @liranp, thanks for the contribution!

The GetCloudGroups function accepts a bool for warnUnmatched so it is probably better to look at where this is called in the code and update there, e.g. : https://github.com/kubernetes/kops/blob/1.11.0-alpha.1/cmd/kops/rollingupdatecluster.go#L269

Unless you think in all cases (for the supported cloud providers / different implementations) the log line should be downgraded, in which case warnUnmatched should be removed altogether. @justinsb what do you think?

@liranp
Copy link
Contributor Author

liranp commented Nov 5, 2018

@KashifSaadat You're right, but there's no way to toggle the warnUnmatched boolean off when the rolling-update command is executed against the whole cluster.

@justinsb
Copy link
Member

justinsb commented Nov 9, 2018

Oh - this is in the spotinst code, not the general AWS code. In that case it's fine by me.

I think for general AWS we do some tag filtering (so we only match ASGs that are tagged to this cluster), so this is more surprising in the general AWS case - and justifies a warning. If you can do similar filtering, I would recommend doing that and keeping it as a warning.

But ... if you choose to do that, it can be a follow-on PR.

Thanks @liranp

(PS and thanks @KashifSaadat for thinking through the implications)

/approve
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 9, 2018
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, liranp

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 Nov 9, 2018
@k8s-ci-robot k8s-ci-robot merged commit 73a24b4 into kubernetes:master Nov 9, 2018
@liranp liranp deleted the fix-warn-unmatched branch May 5, 2019 14:36
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. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants