Open cmoulliard opened 3 months ago
@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
the folders
target/generated-sources/open-api-stream
This folder is empty after executing mvn clean package
under serverless-workflow-examples/escalation
To get something generated, it is needed that the OpenAPI spec files are moved under src/main/openapi
folder
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"
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
...
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 ?
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
@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.
kube_yaml
Do you created the src/main/resources/specs/kube.yaml
file manually ?
@ricardozanini
@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
@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.
@cmoulliard you can also look at this option to share the same API specs and reuse it in multiple workflows: Using URI alias
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 undersrc/main/openapi
Can you explain what you did to generate the YAML file of kube and if you generated also some java client classes ?