test-framework: allow running local tests in a predefined namespace

[hasbro17]

Currently the operator-sdk test command will create a new namespace for each test-case or context.
https://github.com/operator-framework/operator-sdk/blob/master/doc/sdk-cli-reference.md#test

We should allow users to specify a pre-defined namespace to use for running all their tests, e.g:

operator-sdk test --namespace=<namespace> -t ./test/e2e

This should restrict all contexts to use the specified namespace.

One use case for this is testing operators that require a ClusterRole and ClusterRoleBinding.
For a ClusterRoleBinding manifest you have to specify the namespace to bind to. Unlike a RoleBinding which is bound to the namespace it's created in.
Currently there is no way for a user to predict the namespace that each test context will generate (in the format TestName-Timestamp).

We can add the namespace flag to operator-sdk test local after the in-cluster command operator-sdk test cluster is merged #469

/cc @aravindhp @AlexNPavel

[fanminshi]

why can't this being done at the api lvl?
For instance, NewCtx() takes in some parameter to tell what to bind to this namespace?

[hasbro17]

NewCtx()takes in some parameter to tell what to bind to this namespace?

Not sure what you mean by that.

What I want is an optional way for the tests to use a predefined namespace instead of creating new ones. And that's via an optional flag passed to the test-framework.

[fanminshi]

For a ClusterRoleBinding manifest you have to specify the namespace to bind to.
Suppose that the NewTestCtx() takes in a ClusterRoleBinding manifest and binds it to the namespace that it is creating underneath. Will that solve the issue?

What I want is an optional way for the tests to use a predefined namespace instead of creating new ones.
I believe this can be done at API lvl tool. The user just needs to create a NewTestCtx() with a namespace which its name can be specified by user. Then user just pass the ctx around different tests if user wants to run all those test under one namespace.

Essentially, I am unsure if it is necessary to add new flags to the command to support a new functionality where a tweak in the API lvl can achieve the similar result.

[hasbro17]

ClusterRoleBinding is just one example of why you might need to restrict the tests to predefined namespace.

For example in the in-cluster case operator-sdk test cluster the tests run as a pod in a namespace that is setup beforehand. The test-framework doesn't have the permissions to create a new namespace so it has to be restricted to run all test cases in the existing namespace.
In that case there is no ClusterRoleBinding.

So the issue is not the ClusterRoleBinding but rather the ability to restrict all tests to a predefined namespace.

[AlexNPavel]

Solved by #546