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

Allow additional SGs to be added to API loadbalancer #4036

Merged

Conversation

almariah
Copy link
Contributor

@almariah almariah commented Dec 11, 2017

Allow adding precreated additional security groups to the API loadbalancer using cluster spec:

spec:
  api:
    loadBalancer:
      type: Public
      additionalSecurityGroups:
      - sg-exampleid3
      - sg-exampleid4
  • Adding additionalSecurityGroups cluster spec
  • Adding validation for repeated security groups
  • Adding validation for API loadbalancer security groups
  • Integration test for API loadbalancer and its security groups
  • Update API docs and cluster.spec docs

@k8s-ci-robot
Copy link
Contributor

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.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
  • If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
  • If you have done the above and are still having issues with the CLA being reported as unsigned, please email the CNCF helpdesk: [email protected]

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.

@k8s-ci-robot k8s-ci-robot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 11, 2017
@almariah
Copy link
Contributor Author

I have signed CLA

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Dec 11, 2017
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Dec 11, 2017
@almariah
Copy link
Contributor Author

/assign @andrewsykim

@almariah
Copy link
Contributor Author

@gambol99 Can you check this pull request, or do I have to find specific reviewer?

Copy link
Contributor

@chrislovecnm chrislovecnm left a 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 {
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

Choose a reason for hiding this comment

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

I understand now. Excellent

@@ -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.")
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

@almariah almariah Dec 12, 2017

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.

@chrislovecnm
Copy link
Contributor

/ok-to-test

@k8s-ci-robot k8s-ci-robot removed the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Dec 11, 2017
@@ -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")
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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!

Copy link
Contributor

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 ;)

Copy link
Contributor

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.

@chrislovecnm
Copy link
Contributor

/assign

@chrislovecnm
Copy link
Contributor

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.
@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Dec 12, 2017
@k8s-ci-robot k8s-ci-robot removed the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Dec 13, 2017
@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Dec 13, 2017
@almariah
Copy link
Contributor Author

@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!

@@ -263,8 +263,9 @@ const (
)

type LoadBalancerAccessSpec struct {
Copy link
Contributor

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!!

@chrislovecnm
Copy link
Contributor

One last thing ... then lgtm

@almariah
Copy link
Contributor Author

@chrislovecnm The API docs has been updated.

@justinsb
Copy link
Member

Awesome contribution @almariah - thank you!

/lgtm

If you do want to add CLI capabiltiy, --override is a nice mechanism to do that, that keeps us close to the API. So the user-facing syntax would be --override cluster.spec.api.loadBalancer.additionalSecurityGroups=sg-12345 --override cluster.spec.api.loadBalancer.additionalSecurityGroups=sg-67890 or maybe --override cluster.spec.api.loadBalancer.additionalSecurityGroups=sg-12345,sg-67890

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:
https://github.com/kubernetes/kops/blob/master/cmd/kops/create_cluster.go#L1200

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.

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

[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 /approve in a comment
You can cancel your 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 Dec 14, 2017
@k8s-github-robot
Copy link

/test all [submit-queue is verifying that this PR is safe to merge]

@k8s-github-robot
Copy link

Automatic merge from submit-queue.

@k8s-github-robot k8s-github-robot merged commit d533714 into kubernetes:master Dec 14, 2017
@almariah almariah deleted the feature-api-elb-security-groups branch December 14, 2017 11:01
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. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants