-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
nodePortAccess, experimental spec override flag #3336
Conversation
This will allow us to set CIDRs for nodeport access, which in turn will allow e2e tests that require nodeport access to pass. Then add a feature-flagged flag to `kops create cluster` to allow arbitrary setting of spec values; currently the only value supported is cluster.spec.nodePortAccess
17587a4
to
9d31ed1
Compare
/retest |
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.
Looks great. Just naming stuff and user ux. This is under a feature flag, so most of the suggestions can be in a follow-up. The only sticker that I have is the API value name. Need some feedback.
case "cluster.spec.nodePortAccess": | ||
cluster.Spec.NodePortAccess = append(cluster.Spec.NodePortAccess, kv[1]) | ||
default: | ||
return fmt.Errorf("unhandled override: %q", override) |
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 would probably not understand this error.
How about:
Only cluster.Spec.NodePortAccess is supported, and %s was set More support is planned for the future.
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.
Right - hopefully this won't be a permanent state of affairs - and I certainly don't intend to hard-code every field :-)
@@ -92,6 +92,8 @@ type ClusterSpec struct { | |||
NonMasqueradeCIDR string `json:"nonMasqueradeCIDR,omitempty"` | |||
// SSHAccess is a list of the CIDRs that can access SSH. | |||
SSHAccess []string `json:"sshAccess,omitempty"` | |||
// NodePortAccess is a list of the CIDRs that can access the node ports range (30000-32767). | |||
NodePortAccess []string `json:"nodePortAccess,omitempty"` |
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.
nit pick, but the name does not make sense to me ... It is an API value so we need to have it named well. @blakebarnett / @alrs / @KashifSaadat thoughts? NodePortAccess sounds like a true / false. Not a list of CIDRS
NodePortSecGroupRanges?
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.
It is supposed to be a parallel to kubernetesApiAccess and sshAccess, but open to better ideas.
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.
That makes sense.
@@ -109,9 +109,11 @@ type ClusterSpec struct { | |||
NonMasqueradeCIDR string `json:"nonMasqueradeCIDR,omitempty"` | |||
|
|||
// SSHAccess determines the permitted access to SSH | |||
// Currently only a single CIDR is supported (though a richer grammar could be added in future) |
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.
It this changing in this PR?
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.
No, but I spotted that this comment was wrong and I figured it wasn't entirely unrelated ;-)
for _, override := range overrides { | ||
kv := strings.SplitN(override, "=", 2) | ||
if len(kv) != 2 { | ||
return fmt.Errorf("unhandled override: %q", override) |
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.
unhandled override
Is this actually override is in the wrong format? How about
--override must be in key=value format. For example cluster.spec.nodePortAccess=0.0.0.0/0
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.
TBH I'm not yet sure what the overrides should look like. They could be JSON, for example.
I figured I would guard it behind a feature flag, we can start using it to get test coverage, and we can see what "feels" right.
@@ -284,6 +287,10 @@ 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'") | |||
|
|||
if featureflag.SpecOverrideFlag.Enabled() { | |||
cmd.Flags().StringSliceVar(&options.Overrides, "override", options.Overrides, "Directly configure values in the spec") |
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.
nit pick. Are these overrides
? Plural?
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 idea is that you pass the flag repeatedly. So there are many overrides, but only one per flag.
@justinsb did you want to update the |
Let's do a follow-up - I'm hoping to find a trick to make it easy to set those, and it is guarded behind a feature flag for now. |
/lgtm please file an issue for the follow-up PR |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chrislovecnm, 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] |
Certain irony about an enhancement that is meant to help e2e to fail when we cannot create loadbalancers, and while the enhancement is not enabled, e2e fails because of a flake. /retest |
/retest |
/test pull-kops-e2e-kubernetes-aws |
1 similar comment
/test pull-kops-e2e-kubernetes-aws |
whoops - kops-k8s presubmit goes less smoothly than k8s-kops I'll need to take another look |
/test pull-kops-e2e-kubernetes-aws |
(that looks like some legit ❄️ ) |
/test pull-kops-e2e-kubernetes-aws
…On Thu, Sep 7, 2017 at 5:34 PM, Sen Lu ***@***.***> wrote:
(that looks like some legit ❄️ )
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3336 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABva_bowzoKuNDdwShGm3nQ5sdxJxBGks5sgIuYgaJpZM4PMKcM>
.
|
/retest |
/retest (Fixed test, I believe) |
Grrr... I'm debugging with kubernetes/test-infra#4461 |
/retest |
/retest |
/test all [submit-queue is verifying that this PR is safe to merge] |
hey it works :-) |
Automatic merge from submit-queue |
This will allow us to set CIDRs for nodeport access, which in turn will
allow e2e tests that require nodeport access to pass.
Then add a feature-flagged flag to
kops create cluster
to allowarbitrary setting of spec values; currently the only value supported is
cluster.spec.nodePortAccess