Question: Is the quarkus openapi generator extension used for escalation ?

[cmoulliard]

Question

Is the quarkus openapi generator extension used by escalation example to generate the OpenAPI YAML file of kube ?

I'm confused as the properties file includes the following property quarkus.openapi-generator.kube_yaml.auth.BearerToken.bearer-token=${OCP_API_SERVER_TOKEN} - see:
https://github.com/parodos-dev/serverless-workflow-examples/blob/main/escalation/src/main/resources/application.properties
BUT I don't see anything generated under src/main/openapi

Can you explain what you did to generate the YAML file of kube and if you generated also some java client classes ?

[dmartinol]

@cmoulliard The openAPI-related code is generated by the Maven build, so please run mvn clean package and then look under the folders target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/api and target/generated-sources/kogito/org/kie/kogito/app

[cmoulliard]

the folders target/generated-sources/open-api-stream

This folder is empty after executing mvn clean package under serverless-workflow-examples/escalation

[cmoulliard]

To get something generated, it is needed that the OpenAPI spec files are moved under src/main/openapi folder

[dmartinol]

That move is not required, according to the SonataFlow specs and to all of our tests until today.
I just ran the mvn command on a freshly cloned repo, from the same folder and:

dmartino@dmartino-mac escalation % find target/generated-sources -name "*K8*.java"
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceSpec.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ObjectMetaOwnerReferencesInner.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceStatusConditionsInner.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ObjectMetaManagedFieldsInner.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ObjectMeta.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1Namespace.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceMetadata.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceStatus.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceCondition.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ListMeta.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceList.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1OwnerReference.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ManagedFieldsEntry.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceListItemsInner.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceListMetadata.java
(fastai) dmartino@dmartino-mac escalation % find target/generated-sources -name "*Kube*.java"
target/generated-sources/kogito/org/kie/kogito/app/Kube_listCoreV1Namespace.java
target/generated-sources/kogito/org/kie/kogito/app/Kube_createCoreV1Namespace.java

Let me add some env as well:

dmartino@dmartino-mac escalation % java -version
openjdk version "11.0.22" 2024-01-16
OpenJDK Runtime Environment Homebrew (build 11.0.22+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.22+0, mixed mode)

dmartino@dmartino-mac escalation % mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /opt/apache-maven-3.8.6
Java version: 11.0.22, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@11/11.0.22/libexec/openjdk.jdk/Contents/Home
Default locale: en_IT, platform encoding: UTF-8
OS name: "mac os x", version: "13.6.4", arch: "x86_64", family: "mac"

[cmoulliard]

That works :-). The issue was perhaps related to tree of folders under target not refreshed by IntelliJ

find target/generated-sources -name "*K8*.java"
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceSpec.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ObjectMetaOwnerReferencesInner.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApiCoreV1NamespaceStatusConditionsInner.java
target/generated-sources/open-api-stream/org/kie/kogito/openapi/kube/model/IoK8sApimachineryPkgApisMetaV1ObjectMetaManagedFieldsInner.java
...

[cmoulliard]

So the answer to my question is: The quarkus openapi generator is executed by "kogito-quarkus-serverless-workflow" and the following properties defined part of the application.properties file are not used for that purpose

# OpenShift API Server
quarkus.rest-client.kube_yaml.url=${OCP_API_SERVER_URL}
quarkus.openapi-generator.kube_yaml.auth.BearerToken.bearer-token=${OCP_API_SERVER_TOKEN}
quarkus.tls.trust-all=true
quarkus.kubernetes-client.trust-certs=true

So I suspect that the property quarkus.rest-client.kube_yaml.url=${OCP_API_SERVER_URL} is used when a sonataflow action like this one

  - name: CreateK8sNamespace
    type: operation
    actions:
      - functionRef:
          refName: createK8sNamespace
          arguments:
            apiVersion: v1
            kind: Namespace
            metadata:
              name: ".namespace"
        actionDataFilter:
          toStateData: .createdNamespace
    stateDataFilter:
      output: "{createdNamespace: .createdNamespace}"

will call the Kube API (using java generated classes) to request to the cluster to create a namespace - correct ?

Question: Will this property quarkus.openapi-generator.kube_yaml.auth.BearerToken.bearer-token=${OCP_API_SERVER_TOKEN} be used too to configure the Rest Kube Client to access the cluster as the user should be authenticated or at least have enough RBZC rights to issue requests ?

[dmartinol]

I think that all the OpenAPI clients are using these bearer tokens the same way, no matter the server is Kube or any other service.
So I assume that, depending on the configured security scheme type, it will implement the preliminary authentication step according to the associated protocol:

    securitySchemes:
      BearerToken:
        type: http
        scheme: bearer
        description: Bearer Token authentication

Adding @ricardozanini who can help in finding the right person to reply any further doubts

[ricardozanini]

@cmoulliard @dmartinol your assumptions are correct. The quarkus.openapi-generator.kube_yaml.* prefix is used to configure generated code from the OpenAPI gen extension. Since we generate Quarkus REST Client code, you can use quarkus.rest-client.kube_yaml.* prefix to configure runtime settings.

I'd recommend reading https://docs.quarkiverse.io/quarkus-openapi-generator/dev/client.html. If there's anything I can help or dubious in the docs, let me know so we can fix it.

[cmoulliard]

kube_yaml

Do you created the src/main/resources/specs/kube.yaml file manually ?
@ricardozanini

[dmartinol]

@cmoulliard IIRC @rgolangh created it initially, I think by reducing some published specs to reduce the size of the ConfigMap. Once he returns from the business trip I'm sure he can help

[ricardozanini]

@cmoulliard speaking about the general use case, users will have to make the files available in that path and then configure the application.properties file accordingly. If in this use case, you have a tool to generate the OpenAPI file automatically and put it in the dir, it should work too.

[dmartinol]

@cmoulliard you can also look at this option to share the same API specs and reuse it in multiple workflows: Using URI alias