Update Netpol e2e tests to use framework CreateNamespace

[antoninbas]

The main purpose of this change is to update the e2e Netpol tests to use
the srandard CreateNamespace function from the Framework. Before this
change, a custom Namespace creation function was used, with the
following consequences:

• Pod security admission settings had to be enforced locally (not using
  the centralized mechanism)
• the custom function was brittle, not waiting for default Namespace
  ServiceAccount creation, causing tests to fail in some infrastructures
• tests were not benefiting from standard framework capabilities:
  Namespace name generation, automatic Namespace deletion, etc.

As part of this change, we also do the following:

• clearly decouple responsibilities between the Model, which defines the
  K8s objects to be created, and the KubeManager, which has access to
  runtime information (actual Namespace names after their creation by
  the framework, Service IPs, etc.)
• simplify / clean-up tests and remove as much unneeded logic / funtions
  as possible for easier long-term maintenance
• remove the useFixedNamespaces compile-time constant switch, which
  aimed at re-using existing K8s resources across test cases. The
  reasons: a) it is currently broken as setting it to true causes most
  tests to panic on the master branch, b) it is not a good idea to have
  some switch like this which changes the behavior of the tests and is
  never exercised in CI, c) it cannot possibly work as different test
  cases have different Model requirements (e.g., the protocols list can
  differ) and hence different K8s resource requirements.

For #108298

Signed-off-by: Antonin Bas abas@vmware.com

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Which issue(s) this PR fixes:

For #108298

It only addresses the issue for Netpol tests. Some other e2e tests may still be using a custom Namespace creation function instead of the Framework one.

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Please note that we're already in Test Freeze for the release-1.25 branch. This means every merged PR will be automatically fast-forwarded via the periodic ci-fast-forward job to the release branch of the upcoming v1.25.0 release.

Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Wed Aug 10 13:31:11 UTC 2022.

[k8s-ci-robot]

@antoninbas: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[k8s-ci-robot]

Hi @antoninbas. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[antoninbas]

Ran the test suite manually (with Antrea as CNI provider):

------------------------------
[ReportAfterSuite] PASSED [0.000 seconds]
[ReportAfterSuite] Kubernetes e2e suite report
test/e2e/e2e_test.go:146

  Begin Captured GinkgoWriter Output >>
    [ReportAfterSuite] TOP-LEVEL
      test/e2e/e2e_test.go:146
  << End Captured GinkgoWriter Output
------------------------------

Ran 51 of 7067 Specs in 1173.822 seconds
SUCCESS! -- 51 Passed | 0 Failed | 0 Pending | 7016 Skipped
PASS

[antoninbas]

/cc @s-urbaniak @danwinship

[tnqn]

/ok-to-test

[astoycos]

cc @jayunit100 @stlaz

[mattfenwick]

+1 nice one Antonin ! 🚀

[aojea]

/assign

Let's try to get this early in the cycle, release is tomorrow

[jayunit100]

I just saw this! Thanks

[jayunit100]

B) I actually like the use fixed names paces switch for certain test hacking but there's an e2e flag that u can use that persists the names paces instead so... ok makes sense

[jayunit100]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: antoninbas, jayunit100

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• test/e2e/network/netpol/OWNERS [jayunit100]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jayunit100]

everyone else ok with this one ?

[knabben]

/lgtm

[antoninbas]

@jayunit100

I actually like the use fixed names paces switch for certain test hacking but there's an e2e flag that u can use that persists the names paces instead so... ok makes sense

I do see the appeal as well. It was actually one of the initial selling points for the updated netpol framework: create a set of Namespaces / Pods / Services once and run a bunch of tests with different NetworkPolicies to validate a CNI implementation. However, the ability to do that was lost over time after upstreaming the framework and making it work with the standard upstream e2e framework. Before removing the flag, I tried to run it locally and confirmed it was broken. I tried to fix it to keep the functionality, but couldn't find a good way to do it. One of the reasons is that different test cases within the test suite have different protocols requirements, and that requires test Pods to be re-created. Even if it's fixed somehow, it will probably break again within a couple of months as folks make additional changes to these files, given that this way of running tests would not be exercised in CI. When doing local development, I find that a common pattern is running an individual test case, in which case the ability to use the same K8s resources is not super useful.