Usage of Kustomize

[wtrocki]

When working with operators building controller is one of the first operations, however there are also some other concerns like adding extra metadata to CRD, creating bundle and deploying to operatorhub with OLM

One of the key tools used in operator SDK is kustomize.
Tool operates on YAML files and it is language independent. Would Java SDK use kustomizehttps://kustomize.io/ at some point? This will allow quite nice reuse of the existing tools for deployment of operators and automation.

I seen also dekorate that generates YAML from pojos, but it seems to be organized around some top level use cases rather than generic config tool.
https://github.com/dekorateio/dekorate

Ideally dekorate and kustomize would work nicely together

[metacosm]

Hi, @wtrocki

Could you elaborate on the use case you have in mind? How would things work for you, ideally?

[wtrocki]

@metacosm Since there is no documentation for java operator at the moment and CLI is in the progress I was curious if I can simply use exiting infrastructure from operator SDK and reuse some bits from the existing ecosystem to prove that you can get things done end to end and help java operator SDK with documentation, examples and making it usable for early adopters.

There are couple of things there: Operator-SDK, Kubebuilder (golang specific) template engine and kustoimize (generic) that can decorate CRDs.

So I was curious if I could use part of the existing infrastructure for operators and successfully deploy java operator to operatorhub as for today reusing already proven scripts/tools from Operator SDK that are not golang specific.

I created issue to get feedback if this is the way team is going to approach it in the future or there will be some java equivalent etc.

TL;DR - I really want to prove that you can use Java Operator SDK to deploy operator to production today and it can be used for some new projects. This way we can build some early community of adopters and get things tested much faster.

[iocanel]

I think that dekorate and kustomize can play nicely together.

dekorate is taking an app centric approach and is meant to generate the initial set of resources for the app, operator etc. It's goal is to extract as much information as possible from the code itself and align the generated manifests. Additionally it does provide a rich set of configuration options for further customization.

kustomize is mostly used for patching / customizing existing resources. So, it can be used to modify resources generated by dekorate in cases where changes are needed after the intial generation phase, or for users that prefer an alternative customization interface than the one that dekorate provides.

Currently, there is no direct integration available, so users that need to use kustomize have to manually apply it after the generation phase. But shouldn't be that hard to implement if we need to.

Personally I feel that both the pojo to crd functionality and the kustomize integration should be made part of the kubernetes-client.

[maxandersen]

@iocanel isn't users tha tuse kustomize used to apply manual anyways ?

i'm wondering when operator-java-sdk is used in quarkus context how much the existing kustomize integration in osdkcli does that wouldn't just be handled by current quarkus/dekorate/openshift integration?

[jmrodri]

@jmrodri consider this issue for https://github.com/operator-framework/java-operator-plugins/

[andreaTP]

I started collecting ideas about how to make the structure in target more easily integrated with a kustomize workflow, so far:

• copy all kubernetes resources from src/main/kubernetes to target/kubernetes
• generate the resources in subfolders of target/kubernetes, such as target/kubernetes/crds, target/kubernetes/deployment, target/kubernetes/rbac etc.

those will already make using kustomize much easier and with a better granularity.