Add preview cluster-wide kubectl install for the operator - #46980

I think this warrants its own issue. It is staking out a middle ground we haven't yet talked about for cluster-wide mode - that is optionally (and possibly as unsupported) via non-olm mode. Please create an issue for this and we'll link it under #43955

As you can glean there hasn't been commitment yet on whether we are going to expose the simple cluster-wide mode. If you want to see this simple cluster wide mode supported in general please add comments about that to #43955 as well.

In part we're also waiting for results from #43954

cc @vmuzikar @mabartos

Thanks, that makes sense.
I opened #46981 for experimental cluster-wide installation via the non-OLM / kubectl path.

I've made a couple of refinements to this pr. The first was to minimize the amount of duplication there is between our normal artifacts and what was in the new overlay. The second was to broaden how we are using kustomize - what was initially shown here was only valid if you were in the checked out operator directory after building the operator. This is because the kustomize file referenced the target directory as a resource. Instead what I think we need is to be able to install the operator like this:

kubectl apply -k 'github.com/keycloak/keycloak-k8s-resources/kubernetes?ref=version'

Or (which defaults to keycloak-operator namespace instead)

kubectl apply -k 'github.com/keycloak/keycloak-k8s-resources/overlays/cluster-wide?ref=version'

Putting the operator into a different namespace can then be done with a kustomize file similar to what is in this pr for switching to the default namespace, or we can just leave the current instuctions for now

If we have this in place, then we'll be able to change the docs for all the places we are currently referencing the operator installation:

https://github.com/search?q=org%3Akeycloak%20keycloak-k8s-resources&type=code

to be just kubectl apply -k 'github.com/keycloak/keycloak-k8s-resources/kubernetes?ref=version' - and then we won't have to update all those places again each time we add a new CRD for client v2 work.

@vmuzikar where is the job defined for adding resources to keycloak-k8s-resources? It would need to add the overlay directory moving forward.

The final change was to remove the use of kustomize from within the test code. I believe a goal in the test logic was to not directly call out to kubectl if possible.

@vmuzikar are you good with docs here that refer to this as an experimental feature that is only mentioned in the community docs? We can of course also address this in follow-ups under #49037

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.forms.BruteForceTest#testNoFailureResetForPermanentLockout

Keycloak CI - Base IT (5)

org.opentest4j.AssertionFailedError: Expected error event ==> expected: <true> but was: <false>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
	at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
...

Report flaky test

@keycloak/cloud-native this should be complete. My underlying assumption here is that we want to keep the single namespace installation the default behavior. If that changes later (needs of the helm chart, or if we want the cluster-wide to be the default) we can revisit this.

@vmuzikar updated to the Preview term again, and needed to remove trying to share the crds. It violates the security model of kustomize to make parent references to anything other that other kustomize directories - which we don't want to do in this case as that puts us back into making this an overlay.

shawkins Thanks for the updates. The only thing missing is the release notes (specifically for Kustomize, all namespace mode will be covered in the other PR), and single namespace mode test.

specifically for Kustomize, all namespace mode will be covered in the other PR

I am assuming that would happen in which ever PR goes in last - in particular the current all namespace kubectl instructions in the other PR will need to be updated, and it contains a release note with a general cluster-wide heading under which kubectl installs for community should be called out as well.

and single namespace mode test

Added.