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

update NetworkPolicy e2e test for v1 semantics #46630

Merged

Conversation

danwinship
Copy link
Contributor

This makes the NetworkPolicy test at least correct for v1, although ideally we'll eventually add a few more tests... (So this covers about half of #46625.)

I've tested that this compiles, but not that it passes, since I don't have a v1-compatible NetworkPolicy implementation yet...

@caseydavenport @ozdanborne, maybe you're closer to having a testable plugin than I am?

Release note:

NONE

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label May 30, 2017
@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. release-note-none Denotes a PR that doesn't merit a release note. labels May 30, 2017
@caseydavenport
Copy link
Member

@danwinship yeah we've got an implementation in the works but not 100% complete yet. Will try this PR out this week hopefully.

CC @gunjan5

testCannotConnect(f, ns, "client-a", service, 80)
testCanConnect(f, ns, "client-b", service, 81)
})

It("shouldn't enforce policy when isolation is off [Feature:NetworkPolicy]", func() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we rehash this and test that It("shouldn't enforce policy when no networkpolicy is defined")? At that point it's sort of a basic network test, but could still serve as a useful base case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that's covered well enough by other tests? Eg, the first test checks that it can connect to the server before adding a default-deny policy, and can't connect after.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, fair enough. This LGTM, looking forward to trying this with a testable plugin.

@mikedanese mikedanese assigned bowei and unassigned soltysh Jun 1, 2017
@mikedanese
Copy link
Member

/approve

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 1, 2017
@bowei
Copy link
Member

bowei commented Jun 2, 2017

We have cross version e2e tests -- will this work with the previous release?

@bowei
Copy link
Member

bowei commented Jun 2, 2017

May want to skip the test cases if they are running against a <1.7 cluster?

@danwinship
Copy link
Contributor Author

The tests aren't run automatically as part of any standard test run (they all still have "[Feature:NetworkPolicy]"), because they require a third-party network plugin. So I don't think the cross-version concerns matter? (At any rate, it depends on the plugin version as much as the kubernetes version, so we wouldn't be able to automatically determine what to do anyway.)

@danwinship
Copy link
Contributor Author

What needs to happen 1.7-wise on this PR? I think we need the milestone set, and maybe cherrypick-candidate? (I am told that because it only affects tests it's not blocked by the code freeze.)

@danwinship
Copy link
Contributor Author

@caseydavenport @ozdanborne FWIW I've tested this against my v1-semantics OpenShift branch now, and it passes, but that doesn't necessarily mean a lot since I could have just implemented the wrong behavior in both places :)

@caseydavenport
Copy link
Member

@danwinship we're investigating some e2e failures we're seeing with Calico using this PR - not clear yet if it's on our side or something with the tests :)

@gunjan5
Copy link
Contributor

gunjan5 commented Jun 6, 2017

@danwinship the tests worked with Calico implementation as well (they were failing due to a DNS error and lack of coffee) :)

framework.Failf("unable to cleanup svc %v: %v", service.Name, err)
}
}()
defer cleanupServerPodAndService(f, podServer, service)
framework.Logf("Waiting for Server to come up.")
err := framework.WaitForPodRunningInNamespace(f.ClientSet, podServer)
Expect(err).NotTo(HaveOccurred())

// Create a pod with name 'client-a', which should be able to communicate with server.
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: the comment says pod 'client-a' but it's 'client-can-connect' in reality (same for a few other comments)

@danwinship
Copy link
Contributor Author

fixed comments (I only found two incorrect ones) and repushed

@danwinship
Copy link
Contributor Author

@k8s-bot pull-kubernetes-e2e-gce-etcd3 test this

@caseydavenport
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jun 7, 2017
@caseydavenport
Copy link
Member

@thockin can we add this to the v1.7 milestone?

@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: caseydavenport, danwinship, mikedanese

Associated issue: 46625

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

@thockin thockin added this to the v1.7 milestone Jun 7, 2017
@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 45877, 46846, 46630, 46087, 47003)

@k8s-github-robot k8s-github-robot merged commit 551d01c into kubernetes:master Jun 8, 2017
@danwinship danwinship deleted the networkpolicy-test-v1 branch June 10, 2017 15:03
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. release-note-none Denotes a PR that doesn't merit a release note. 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.

None yet

10 participants