Test running without k8s api proxying.

[absoludity]

Signed-off-by: Michael Nelson minelson@vmware.com

Description of the change

Follows on from both the work on #3896 as well as @castelblanque 's work in the recent #4051 . Since the latter isn't yet landed, I've targeted a branch that I created which is just an updated master with Rafa's changes. I'll retarget to master once Rafa's PR lands. (Edit: done)

This PR updates the frontend config so that it no longer proxies to the k8s API server, unless operators are enabled.

It also updates ci so that the operator switch (and hence whether Kubeapps proxies to the k8s api server) can be configured via the env. I set it to disable operators and the k8s api proxying to verify that it passed, and am now updating it to re-enable the operators in CI for now.

Finally, it also updates the dashboard so that we no longer request api groups and api endpoints at all, when operators are not enabled.

Benefits

No more proxying of k8s api server! (unless operator support is enabled).

Possible drawbacks

Some yet-to-be discovered place where we still depend on the k8s API being accessible, that is not used in e2e, causing a failure (but should be easy to fix, if so)

Applicable issues

• fixes Replace remaining Dashboard calls to K8s API server #3896

Additional information

I've tested this IRL and haven't hit any issues. Let's see what CI says.

[absoludity]

Currently failing CI with:

./script/e2e-test.sh: line 398: testsToIgnore[@]: unbound variable

but I can't for the life of me see why that var is unbound on line 398. Neither can shellcheck :/ Let me know if you've any ideas.

[absoludity]

Nice, tests now running, but looks like a valid failure when creating a private app repo. I'll reproduce that one locally and fix tomorrow.

[castelblanque]

@absoludity #4051 is merged into master. Feel free to go ahead!

[absoludity]

Nice, tests now running, but looks like a valid failure when creating a private app repo. I'll reproduce that one locally and fix tomorrow.

Excellent, thanks Rafa. I'll rebase and take it out of draft once I find the culprit of the failure :)

[castelblanque]

Thanks for introducing the flag for CI.
Shouldn't we add another step where we test the operators?

[absoludity]

Oh - I'll be setting the value here to "1" before landing so that we continue to test with operators in CI. After landing I'll then look at whether to also run a job without operator support.

[absoludity]

OK, so I've verified that this PR passes CI when the operators and the k8s api proxying are disabled, and have now set the TEST_OPERATORS to true so that it's now testing operators (and proxying to the k8s api) again to land, until we're ready to switch CI.