Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

justinsb
Copy link
Member

Big thing is that we need to tell the test scripts to open the firewall rules for NodePorts for e2e tests. This is in the test-specific bit of gce/gke utils.sh. I expect these should be moved so that the NodePort range is always opened for users (unless they directly ask otherwise), but I think that warrants more consideration, and I know we want to get e2e passing again.

WIP while I test myself with a full -down & -up.

The other issue is that I lost a line in my git-work that puts the NodePort to 0, which is required when changing from NodePort -> ClusterIP.

cc @dchen1107

@justinsb justinsb changed the title WIP: Nodeport GCE e2e fixes Nodeport GCE e2e fixes May 23, 2015
@justinsb
Copy link
Member Author

Just got this to work, so no need to manually open any NodePort ranges for e2e tests!

@roberthbailey
Copy link
Contributor

so no need to manually open any NodePort ranges for e2e tests

Does that mean we don't need the extra firewall rule?

@justinsb
Copy link
Member Author

Sorry, what I mean is that previously I had set up this rule manually (i.e. by running the commands directly), and I was concerned that this would be problematic for automated testing. I don't know that we're ready to have these ports be opened up for everyone that runs cluster/kube-up. However, it seems pretty safe to do it only for e2e testing.

Expect a follow up PR to open it for all users, but we'll want to think that one through pretty carefully. I don't think the security threshold needs to be as high for our e2e setup!

@thockin thockin added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 23, 2015
@thockin
Copy link
Member

thockin commented May 23, 2015

LGTM

@dchen1107 dchen1107 assigned dchen1107 and unassigned thockin May 23, 2015
@dchen1107
Copy link
Member

LGTM. @justinsb I am merging this one to run jenkin for tonight. Will let you know the result tomorrow.

dchen1107 added a commit that referenced this pull request May 23, 2015
@dchen1107 dchen1107 merged commit fe84643 into kubernetes:master May 23, 2015
@roberthbailey
Copy link
Contributor

Expect a follow up PR to open it for all users, but we'll want to think that one through pretty carefully.

Agreed that we'll need to consider this carefully. FYI, this is going to break GKE's e2e testing since these extra ports will not be opened on the GKE cluster where the e2e tests run.

@thockin
Copy link
Member

thockin commented May 23, 2015

I'm not at all sure that we want to open these ports in general. We
usually err on the side of caution regarding opening up firewalls.

On Fri, May 22, 2015 at 9:15 PM, Robert Bailey [email protected]
wrote:

Expect a follow up PR to open it for all users, but we'll want to think
that one through pretty carefully.

Agreed that we'll need to consider this carefully. FYI, this is going to
break GKE's e2e testing since these extra ports will not be opened on the
GKE cluster where the e2e tests run.


Reply to this email directly or view it on GitHub
#8728 (comment)
.

@thockin
Copy link
Member

thockin commented May 23, 2015

Justin: Something we may want to change for more compat (short term): We
currently retain publicIPs but don't use it. Maybe we should reinstate the
kube-proxy support for public IPs, until we kill off that field along with
v1b3. Not sure how I missed that before.

On Fri, May 22, 2015 at 9:16 PM, Tim Hockin [email protected] wrote:

I'm not at all sure that we want to open these ports in general. We
usually err on the side of caution regarding opening up firewalls.

On Fri, May 22, 2015 at 9:15 PM, Robert Bailey [email protected]
wrote:

Expect a follow up PR to open it for all users, but we'll want to think
that one through pretty carefully.

Agreed that we'll need to consider this carefully. FYI, this is going to
break GKE's e2e testing since these extra ports will not be opened on the
GKE cluster where the e2e tests run.


Reply to this email directly or view it on GitHub
#8728 (comment)
.

@justinsb
Copy link
Member Author

@thockin OK, I can do that. I know some people would want the ability to totally prevent public IP specification, but if it is going away I will reinstate it until we are ready to remove support for it. Sorry for removing it!

@thockin
Copy link
Member

thockin commented May 23, 2015

As for the need for firewalls - can we do e2e to node ports without
traversing outside the GCE project? That should dodge the need for
firewalls.

On Fri, May 22, 2015 at 9:28 PM, Justin Santa Barbara <
[email protected]> wrote:

@thockin https://github.com/thockin OK, I can do that. I know some
people would want the ability to totally prevent public IP specification,
but if it is going away I will reinstate it until we are ready to remove
support for it. Sorry for removing it!


Reply to this email directly or view it on GitHub
#8728 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

5 participants