-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Allow additional SGs to be added to API loadbalancer #4036
Allow additional SGs to be added to API loadbalancer #4036
Conversation
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
I have signed CLA |
/assign @andrewsykim |
@gambol99 Can you check this pull request, or do I have to find specific reviewer? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, looks good overal. We are trying to not add anymore cli flags A integration test and updating the docs would be awesome. You can follow up with a pr branches on this for the docs, as we need to start moving towards using the api server generated docs.
Again thanks!
ID: fi.String(id), | ||
Shared: fi.Bool(true), | ||
} | ||
if err := c.EnsureTask(t); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The should be add task not ensure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrislovecnm The reason for EnsureTask
is the iteration over the list of security groups. If you added more security groups later and kept the old one, the iteration will be on the whole list and the will raise error for already added security groups if add task is used. EnsureTask will ignore already added security groups or tasks.
It is used also used in autoscalinggroup https://github.com/kubernetes/kops/blob/master/pkg/model/awsmodel/autoscalinggroup.go#L97-L107
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand now. Excellent
cmd/kops/create_cluster.go
Outdated
@@ -311,6 +314,8 @@ func NewCmdCreateCluster(f *util.Factory, out io.Writer) *cobra.Command { | |||
|
|||
cmd.Flags().StringVar(&options.APILoadBalancerType, "api-loadbalancer-type", options.APILoadBalancerType, "Sets the API loadbalancer type to either 'public' or 'internal'") | |||
|
|||
cmd.Flags().StringSliceVar(&options.APILoadBalancerSecurityGroups, "api-loadbalancer-security-groups", options.APILoadBalancerSecurityGroups, "Add precreated additional security groups to the API loadbalancer.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am really trying to not get anymore cli flags and move people toward manifests. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrislovecnm You are right. I think having too much cli flags is sometimes annoying, but having flexibility to use them simplify some operations. If you create the cluster on demand or some other tool try to create the cluster, that would be more easier. In our case we have a jenkins job create the cluster using the cli completely. We were able to manage the whole deployment using the cli without editing or modifying any manifest.
If you have a long running and static setup, the manifests are better in that case. But, if your setup is dynamic and automated, then the cli is better.
Generally, in kops and kubernetes have the ability to configure and operate the cluster using cli and manifests is a great feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, in kops and kubernetes have the ability to configure and operate the cluster using cli and manifests is a great feature.
Yes until you get too many cli options. We already have too many. I love the PR, but another CLI command line is making more of a huge number already ... we do have the override cli option if you want to sneak it in there. I am trying to find the darn thing. @justinsb where is the cli option to allow dynamic yaml via cli?
Let me chew on it, I may be ok since it will basically be parity with the other sec group options, but as a whole, I am trying to not have anymore.
We were able to manage the whole deployment using the cli without editing or modifying any manifest
I would recommend that you start using templated manifests anyways. We have dry-run now to build manifest, and templating to do crazy cool stuff with go templating.
Best practice with my clients is to use YAML. You will soon outgrow the cli. Trust me :)
Again thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrislovecnm Thanks for your explanation. I found the kops cluster templating using toolbox. It is interesting. I mean instead of doing such templating manually using sed or any other tool, using kops toolbox will be more better.
I will remove the cli arg and restore the cmd gen-cli-docs.
/ok-to-test |
cmd/kops/create_cluster.go
Outdated
@@ -942,6 +947,9 @@ func RunCreateCluster(f *util.Factory, out io.Writer, c *CreateClusterOptions) e | |||
} | |||
} | |||
} | |||
if len(c.APILoadBalancerSecurityGroups) > 0 && cluster.Spec.API.LoadBalancer == nil { | |||
return fmt.Errorf("unable to add security groups to nonexistent API loadbalancer") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error handing should be moved into validate.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrislovecnm This error handing is not for validating the cluster spec, it is for cli flags. If you by mistake addd APILoadBalancerSecurityGroups and there is no loadbalancer, it raises the error.
Your thought about a different file for validation is correct. If you run kops validate cluster
, the error handing should be moved into validate.go. But this for kops create cluster
with some non-logical or conflicting cli flags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was not clear enough https://github.com/kubernetes/kops/blob/master/pkg/apis/kops/validation/validation.go
If we choose to have the cli option, we can have it here, but most likely we will either use the option that allows YAML, but we do need validation.go to be updated with the API machinery validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After removing the cli option, we don't need such error handing. The security groups will be a part of the loadbalancer part of the cluster spec.
The part that is not clear for me is why do we need validation.go to be updated with the API machinery validation! Could you explain?
Thanks for your time!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do need it in the api validation so we don’t get stuff like empty sg group names ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The api machinery validation does the same stuff like the cli validation you wrote, but at an api level. The plan is to eventually have kops at a controller, and we need more validation at the api level, and less at the cli level. It eventually ends up at the api anyways. The api is the golang representation of the cluster manifest/spec. If you want to do a separate PR that is fine as well.
/assign |
Also, I will request integration tests. Update this one please https://github.com/kubernetes/kops/tree/master/tests/integration/update_cluster/complex The test go that runs it in is the cmd/kops directory. |
This reverts commit 60a90bf.
@chrislovecnm Could you review the pull request? I updated most of the issues we have discussed. A task list has been added for more details. Thanks! |
pkg/apis/kops/v1alpha1/cluster.go
Outdated
@@ -263,8 +263,9 @@ const ( | |||
) | |||
|
|||
type LoadBalancerAccessSpec struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last nitpick ... should have mentioned it earlier. Can we get some code level docs? Once we generate the api server docs they will show up like: https://github.com/kubernetes/kops/blob/master/docs/apireference/build/index.html ~ we need to get that hosted.
Here is a good guide, https://blog.golang.org/godoc-documenting-go-code, but I assume that you are an experienced gopher.
Docs here and in cluster would be AWESOME!!
One last thing ... then lgtm |
@chrislovecnm The API docs has been updated. |
Awesome contribution @almariah - thank you! /lgtm If you do want to add CLI capabiltiy, Sadly I haven't yet found a nice language / library that lets us specify our API objects in this way, so currently it's behind a feature flag & I've started hard-coding the values: I figure once we've hard-coded a dozen values we can see how they "feel" and if there's a nice library/language we can use. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/test all [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue. |
Allow adding precreated additional security groups to the API loadbalancer using cluster spec: