# Andrea's Knowledge transfer
---
## Relevant people / contacts:

- Andrea Peruffo https://github.com/andreaTP [e-mail]
- Chris Laprun -> Quarkus SDK / CRD generator https://github.com/metacosm [e-mail]
- Attila Meszaros -> JOSDK / WebHooks https://github.com/csviri [e-mail]
- Marc Nuri San Felix -> Fabric8 Kubernetes client https://github.com/manusa [e-mail]
(alternatively Steven Hawkins https://github.com/shawkins [e-mail])
- Ioannis Canellos -> Sundrio / CRD generator https://github.com/iocanel [e-mail]

## Topics
---
### CRD Generator

`SchemaSwap` ->
Rationale, we are currently using `SchemaFrom` to break cyclic references that are unrepresentable in OpenAPI v3.
Currently we break the cycles by not the cyclic fields at all, but the original plan was to limit the level of nesting up to N(to be decided), this was imlpemented but not merged:
https://github.com/keycloak/keycloak/pull/12783
`SchemaFrom` needs to be applied on the specific class and since we are re-using `keycloak-core` Java files we need to patch them with an ugly Maven workaround:
https://github.com/keycloak/keycloak/pull/9759/files
I implemented `SchemaSwap` but the feedback cycle on it was not great, and it turns out that the implementation is not complete.
https://github.com/fabric8io/kubernetes-client/pull/3797 // original PR
https://github.com/keycloak/keycloak/issues/10736 // missing Repeatable
This is my (very much) WIP branch to fix it:
https://github.com/andreaTP/kubernetes-client/commit/f1a4132a180a994623968fc6591ac3255041eb1d
where I found that there might be other bugs/ issues to be sorted out.

`limitations` ->
Those are the all of the supported knobs:
https://github.com/fabric8io/kubernetes-client/blob/master/doc/CRD-generator.md
There are a bunch of known bugs when using `enum`s e.g.:
https://github.com/fabric8io/kubernetes-client/issues/4225
And limitations/missing stuffs regarding validation:
https://github.com/fabric8io/kubernetes-client/issues/4224

### OLM

`Quarkus Operator SDK CSV generator` ->
When I started the effort on OLM the built in CSV generator was not supporting:
https://github.com/quarkiverse/quarkus-operator-sdk/issues/273
I haven't attempted to integrate it after the fix landed.

`OLM` ->
Is now based on bash scripts: https://github.com/keycloak/keycloak/tree/main/operator/scripts
The core "feature" of this approach is that it comes from a "template": https://github.com/keycloak/keycloak/tree/main/operator/olm-base
And there are a bunch of things that got injected: https://github.com/keycloak/keycloak/blob/b80731decfdff56219015b6e182a340ae0be1fe0/operator/scripts/create-olm-bundle.sh#L20
The most interesting one is that RBAC is picked up automatically.
The testing setup is aggregated in a single command: https://github.com/keycloak/keycloak/blob/b80731decfdff56219015b6e182a340ae0be1fe0/.github/workflows/operator-ci.yml#L181
I prototyped some fully automatic release for OLM: https://github.com/andreaTP/keycloak-k8s-release-poc/blob/main/.github/workflows/k8s-resources-ci.yml#L116

### Operator SDKs

`SharedInformers underlying crashes` ->
Upstream traking issue: https://github.com/java-operator-sdk/java-operator-sdk/issues/1170
Basically a `SharedInformer` can crash(in case of bugs/unexpected behavior) in background and there is no notification to user(operator) code.
Has been discussed in Google Chat with Attila, Chris and Luca Burgazzoli.
Agreement was to have an hook for the user to implement a reaction to those issues.

`Junit extension JOSDK` ->
I contributed the necessary code to execute tests in `local` and `remote` as we do for the operator: https://github.com/java-operator-sdk/java-operator-sdk/blob/a8c7fee0191e32d42f1d87f3dab8262e2cc75d42/sample-operators/tomcat-operator/src/test/java/io/javaoperatorsdk/operator/sample/TomcatOperatorE2E.java#L43-L52
This doesn't work with Quarkus at all: https://github.com/quarkiverse/quarkus-operator-sdk/issues/328
Work in progress is in those 2 PRs:
https://github.com/quarkusio/quarkus/pull/25938
https://github.com/quarkusio/quarkus/pull/25905

`Kubernetes client version` ->
In the operator we use the following transitive dependencies:
JOSDK -> https://github.com/java-operator-sdk/java-operator-sdk/blob/6a1eddf081dc7ae6a020a1ebbfe1604005324d04/pom.xml#L46
Quarkus extension -> https://github.com/quarkiverse/quarkus-operator-sdk/blob/d2e530675fc86ffab0172136a95f7d56a06b8333/pom.xml#L17
Quarkus -> https://github.com/quarkusio/quarkus/blob/b01ec42571eb15461a66a30c19d5bac0305acaf6/bom/application/pom.xml#L154
Those 3 needs to stay in-sync, at best of my knowledge they are going to merge Quarkus SDK with JOSDK so that we remove one moving element.

## Re-augmentation

`Re-augmentation` ->
I did some POCs -> https://github.com/andreaTP/poc-operator-mutable-jar
Quarkus discussion: https://github.com/quarkusio/quarkus/discussions/23056
There are a ton of tradeoffs to be considered, last idea with Stuart (Quarkus), was to do a POC using JIB and actually re-building the image in the operator.

## Clustering

`Keycloak clustering` ->
Since we finally closed the discussion regarding `StatefulSet` the next optimization we can try would be to use `KUBE_PING` instead of `DNS_PING`:
https://github.com/keycloak/keycloak/issues/12554#issuecomment-1162771681
Which is reportedly better on Kubernetes environment according to issues in the (codecentric?) Keycloak Helm Chart

---
### Next steps:

- Operator internals ->
Meeting: Operator KT - Friday, July 15⋅2:00 – 4:00pm
- `imagePullPolicy` pair with someone?