---
# System prepended metadata

title: Andrea's Knowledge transfer

---

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

- Andrea Peruffo https://github.com/andreaTP aperuffo@redhat.com
- Chris Laprun -> Quarkus SDK / CRD generator https://github.com/metacosm claprun@redhat.com
- Attila Meszaros -> JOSDK / WebHooks https://github.com/csviri ameszaro@redhat.com
- Marc Nuri San Felix -> Fabric8 Kubernetes client https://github.com/manusa marc.nuri@redhat.com
   (alternatively Steven Hawkins https://github.com/shawkins shawkins@redhat.com)
- Ioannis Canellos -> Sundrio / CRD generator https://github.com/iocanel iocanel@redhat.com 

## 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?
