Allow for tests to run in pre-created NS

[mgencur]

Problem:

In some environments it won't be possible for the testing infrastructure to easily create new namespaces at will, so it would be nice if there was a way to run the e2e tests all within a single, pre-created, namespace.

A similar issue was created for knative/eventing a long time ago: knative/eventing#2776. This comment includes possible solutions. I'm listing them below for completeness:

• Having namespace names generated based on the test name (without random suffix) - this was problematic because tests often have sub-tests and these subtests would share the same namespace unless the individual objects have random suffixes.
• Having just one common namespace and generate every object name for the tests with random suffixes so that all objects are unique even if they exist in the same namespace. This is a lot of work, and requires big changes in the test suite. Another problem is that some individual tests might require label knative-eventing-injection": "enabled" and some require "disabled" which makes it hard to run those in parallel in the same namespace.
• Have a numeric suffix in namespaces names.
  This solution is used in knative/client:
  https://github.com/knative/client/blob/main/lib/test/integration.go#L47
  It is pretty simple, each test has a unique namespace but the name of the namespace is predictable. Each test gets a namespace with a numeric suffix that is increasing. The suffix is a simple number so it's possible to pre-create them, apply some additional logic or/and create additional objects in them. In a specific environment, this can be done by a user with increased privileges (admin). The limitation is that individual tests should not require specific settings that would have to be done by admin user because it is not known in advance which NS the test will run in.

Persona:
Contributors/Devs

Exit Criteria
Ability to run e2e tests against a pre-created cluster and namespaces.

[mgencur]

I can work on that if we agree on a solution.

[lionelvillard]

+1. We currently cannot run any Knative tests in our environment for the exact same reason.

[matzew]

+1
and thanks for bringing this up @mgencur

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[mgencur]

/reopen

[knative-prow-robot]

@mgencur: Reopened this issue.

In response to this:

/reopen

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.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[pierDipi]

/reopen
/triage accepted
/remove-lifecycle stale

[knative-prow-robot]

@pierDipi: Reopened this issue.

In response to this:

/reopen
/triage accepted
/remove-lifecycle stale

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.