wmedvede commented on code in PR #2042:
URL:
https://github.com/apache/incubator-kie-kogito-examples/pull/2042#discussion_r1914515225
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/README.md:
##########
@@ -0,0 +1,64 @@
+# {product_name} Operator - Get Random Cat Fact Example
+
+## Description
+
+The goal of this example is to showcase use of [{product_name} plugin for
Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
for local development and subsequent deployment of finished {product_name}
application.
+
+### Use Case
+
+This example is doing basic decision based on input provided to the workflow.
If the input matches a string, workflow will query a specific endpoint and
store the result, otherwise it uses a static string.
+The example contains workflow definition, necessary application.properties and
an openAPI spec file to be able to query external service.
+
+### Prerequisites
+
+1. Install [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
+2. Install the
[Operator](https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/cloud/operator/install-serverless-operator.html)
+3. Checkout this example locally
+
+### Run the example in local environment
+
+In order to ensure the developed workflows does what it is meant to do, `run`
command allows users to spin up a container in development mode on localhost. A
[management
console](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/quarkus-dev-ui-extension/quarkus-dev-ui-overview.html)
is available for users to play with the workflows.
+
+1. Navigate to the root directory of the example
+2. Execute `kn workflow run`
+3. Navigate to
`http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
to access the management console
+4. You can modify the project, any changes will be detected and the container
will update
+
+### Deploy the example to cluster
+
+Once the workflow is stable and working, `deploy` command allows users to
create deployments of the workflow on the targetted cluster. To deploy a
workflow application, [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
relies on configuration in `<home_directory>/.kube/config`. If you cluster has
managed access, users need to login prior to the use of CLI.
+
+1. Create a namespace for your deployment `oc create namespace catfactexample`
+2. Navigate to the root directory of the example
+3. Execute `kn workflow deploy -n catfactexample`
+4. Access your cluster, you should see new deployment in `catfactexample`
namespace
+5. Management console can be accessed on the
`<WORKFLOW_GENERATED_ROUTE_URL>/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
+
+### Undeploy the example from cluster
+
+In order to get rid of the deployment, `undeploy` command allows user to
cleanup the deployed resources.
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow undeploy -n catfactexample`
+3. The namespace is now clean and without any resources.
+
+### Deploy the example to cluster with different configuration
+
+By default, `deploy` command generates the Kubernetes definitions during the
deployment. In order to customize these files, use
`--custom-generated-manifests-dir=./manifests` parameter to store the generated
Kubernetes manifests. Once modified, use `--custom-manifests-dir=./manifests`
to use the already generated manifests.
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow deploy -n catfactexample
--custom-generated-manifests-dir=./manifests`
+3. Navigate to the `/.manifests` folder and modify the files.
+4. Navigate to root directory of the example.
+5. Execute `kn workflow deploy -n catfactexample
--custom-manifests-dir=./manifests`
+
+Another option is to use `gen-manifest` to create the Kubernetes manifests,
run `kn workflow gen-manifest --help` to see the documentation for this
command. The procedure to deploy is as follows:
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow gen-manifest -n catfactexample --profile=preview
--custom-generated-manifests-dir=./manifests`
+3. Execute `kn workflow deploy -n catfactexample
--custom-manifests-dir=./manifests`
+4. The workflow is now deployed with `sonataflow.org/profile: preview`
annotation.
Review Comment:
:muscle:
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/README.md:
##########
@@ -0,0 +1,64 @@
+# {product_name} Operator - Get Random Cat Fact Example
+
+## Description
+
+The goal of this example is to showcase use of [{product_name} plugin for
Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
for local development and subsequent deployment of finished {product_name}
application.
+
+### Use Case
+
+This example is doing basic decision based on input provided to the workflow.
If the input matches a string, workflow will query a specific endpoint and
store the result, otherwise it uses a static string.
+The example contains workflow definition, necessary application.properties and
an openAPI spec file to be able to query external service.
+
+### Prerequisites
+
+1. Install [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
Review Comment:
I went to the installation page
https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html
I clicked on the suggested link for getting the binary, but the Kn WF CLI
binary is not there:
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/README.md:
##########
@@ -0,0 +1,64 @@
+# {product_name} Operator - Get Random Cat Fact Example
+
+## Description
+
+The goal of this example is to showcase use of [{product_name} plugin for
Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
for local development and subsequent deployment of finished {product_name}
application.
+
+### Use Case
+
+This example is doing basic decision based on input provided to the workflow.
If the input matches a string, workflow will query a specific endpoint and
store the result, otherwise it uses a static string.
+The example contains workflow definition, necessary application.properties and
an openAPI spec file to be able to query external service.
+
+### Prerequisites
+
+1. Install [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
+2. Install the
[Operator](https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/cloud/operator/install-serverless-operator.html)
+3. Checkout this example locally
+
+### Run the example in local environment
+
+In order to ensure the developed workflows does what it is meant to do, `run`
command allows users to spin up a container in development mode on localhost. A
[management
console](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/quarkus-dev-ui-extension/quarkus-dev-ui-overview.html)
is available for users to play with the workflows.
+
+1. Navigate to the root directory of the example
+2. Execute `kn workflow run`
+3. Navigate to
`http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
to access the management console
+4. You can modify the project, any changes will be detected and the container
will update
+
+### Deploy the example to cluster
+
+Once the workflow is stable and working, `deploy` command allows users to
create deployments of the workflow on the targetted cluster. To deploy a
workflow application, [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
relies on configuration in `<home_directory>/.kube/config`. If you cluster has
managed access, users need to login prior to the use of CLI.
Review Comment:
Sorry for being pick, but I think it's important. When we do kn workflow
deploy, the workflow is still deployed in dev mode. But I think that when we
say "Once the workflow is stable and working..." users might get the feeling
that the deploy command will make the workflow deployment in kind of production
mode.
I believe that this example could somehow introduce the concept of `dev`,
`preview` and `gitops` profiles, or point to a proper documentation page, and
clarify that this deployment, as is, is still done in `dev` profile, which
brings the same development features as doing kn workflow run, but giving the
chance of executing the workflow in the k8s cluster.
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/README.md:
##########
@@ -0,0 +1,64 @@
+# {product_name} Operator - Get Random Cat Fact Example
+
+## Description
+
+The goal of this example is to showcase use of [{product_name} plugin for
Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
for local development and subsequent deployment of finished {product_name}
application.
+
+### Use Case
+
+This example is doing basic decision based on input provided to the workflow.
If the input matches a string, workflow will query a specific endpoint and
store the result, otherwise it uses a static string.
+The example contains workflow definition, necessary application.properties and
an openAPI spec file to be able to query external service.
+
+### Prerequisites
+
+1. Install [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
+2. Install the
[Operator](https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/cloud/operator/install-serverless-operator.html)
+3. Checkout this example locally
+
+### Run the example in local environment
+
+In order to ensure the developed workflows does what it is meant to do, `run`
command allows users to spin up a container in development mode on localhost. A
[management
console](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/quarkus-dev-ui-extension/quarkus-dev-ui-overview.html)
is available for users to play with the workflows.
+
+1. Navigate to the root directory of the example
+2. Execute `kn workflow run`
+3. Navigate to
`http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
to access the management console
+4. You can modify the project, any changes will be detected and the container
will update
+
+### Deploy the example to cluster
+
+Once the workflow is stable and working, `deploy` command allows users to
create deployments of the workflow on the targetted cluster. To deploy a
workflow application, [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
relies on configuration in `<home_directory>/.kube/config`. If you cluster has
managed access, users need to login prior to the use of CLI.
+
+1. Create a namespace for your deployment `oc create namespace catfactexample`
+2. Navigate to the root directory of the example
+3. Execute `kn workflow deploy -n catfactexample`
+4. Access your cluster, you should see new deployment in `catfactexample`
namespace
+5. Management console can be accessed on the
`<WORKFLOW_GENERATED_ROUTE_URL>/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
+
+### Undeploy the example from cluster
+
+In order to get rid of the deployment, `undeploy` command allows user to
cleanup the deployed resources.
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow undeploy -n catfactexample`
+3. The namespace is now clean and without any resources.
+
+### Deploy the example to cluster with different configuration
+
+By default, `deploy` command generates the Kubernetes definitions during the
deployment. In order to customize these files, use
`--custom-generated-manifests-dir=./manifests` parameter to store the generated
Kubernetes manifests. Once modified, use `--custom-manifests-dir=./manifests`
to use the already generated manifests.
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow deploy -n catfactexample
--custom-generated-manifests-dir=./manifests`
+3. Navigate to the `/.manifests` folder and modify the files.
+4. Navigate to root directory of the example.
+5. Execute `kn workflow deploy -n catfactexample
--custom-manifests-dir=./manifests`
+
+Another option is to use `gen-manifest` to create the Kubernetes manifests,
run `kn workflow gen-manifest --help` to see the documentation for this
command. The procedure to deploy is as follows:
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow gen-manifest -n catfactexample --profile=preview
--custom-generated-manifests-dir=./manifests`
+3. Execute `kn workflow deploy -n catfactexample
--custom-manifests-dir=./manifests`
+4. The workflow is now deployed with `sonataflow.org/profile: preview`
annotation.
+
+
+Once the application is deployed, you can trigger the workflows. This is as
simple as sending a
+HTTP POST request to the endpoint of your workflow application. For example
`curl -X POST -H 'Content-Type: application/json' -H 'Accept: application/json'
-d '{"fact":"random"}' http://<URL_TO_HOST>/getcatfactinformation` where
`URL_TO_HOST` depends on the environment you are in.
Review Comment:
In the `preview` profile, no route is created.
Maybe we can help the user on how to get the url, just an idea
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/README.md:
##########
@@ -0,0 +1,64 @@
+# {product_name} Operator - Get Random Cat Fact Example
+
+## Description
+
+The goal of this example is to showcase use of [{product_name} plugin for
Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
for local development and subsequent deployment of finished {product_name}
application.
+
+### Use Case
+
+This example is doing basic decision based on input provided to the workflow.
If the input matches a string, workflow will query a specific endpoint and
store the result, otherwise it uses a static string.
+The example contains workflow defintion, necesarry application.properties and
an openAPI spec file to be able to query external service.
+
+### Prerequisites
+
+1. Install [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
+2. Install the
[Operator](https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/cloud/operator/install-serverless-operator.html)
+3. Checkout this example locally
+
+### Run the example in local environment
+
+In order to ensure the developed workflows does what it is meant to do, `run`
command allows users to spin up a container in development mode on localhost. A
[management
console](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/quarkus-dev-ui-extension/quarkus-dev-ui-overview.html)
is available for users to play with the workflows.
+
+1. Navigate to the root directory of the example
+2. Execute `kn workflow run`
+3. Navigate to
`http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
to access the management console
+4. You can modify the project, any changes will be detected and the container
will update
+
+### Deploy the example to cluster
+
+Once the workflow is stable and working, `deploy` command allows users to
create deployments of the workflow on the targetted cluster. To deploy a
workflow application, [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
relies on configuration in `<home_directory>/.kube/config`. If you cluster has
managed access, users need to login prior to the use of CLI.
+
+1. Create a namespace for your deployment `oc create namespace catfactexample`
+2. Navigate to the root directory of the example
+3. Execute `kn workflow deploy -n catfactexample`
+4. Access your cluster, you should see new deployment in `catfactexample`
namespace
+5. Management console can be accessed on the
`<WORKFLOW_GENERATED_ROUTE_URL>/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
Review Comment:
I think we should elaborate a bit more how to obtain the url to the workflow.
If we are in OpenShift, good, we have a route that is created only for the
`dev` profile, if we are in kind/minikube no route is created.
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/README.md:
##########
@@ -0,0 +1,64 @@
+# {product_name} Operator - Get Random Cat Fact Example
+
+## Description
+
+The goal of this example is to showcase use of [{product_name} plugin for
Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
for local development and subsequent deployment of finished {product_name}
application.
+
+### Use Case
+
+This example is doing basic decision based on input provided to the workflow.
If the input matches a string, workflow will query a specific endpoint and
store the result, otherwise it uses a static string.
+The example contains workflow definition, necessary application.properties and
an openAPI spec file to be able to query external service.
+
+### Prerequisites
+
+1. Install [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
+2. Install the
[Operator](https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/cloud/operator/install-serverless-operator.html)
+3. Checkout this example locally
+
+### Run the example in local environment
+
+In order to ensure the developed workflows does what it is meant to do, `run`
command allows users to spin up a container in development mode on localhost. A
[management
console](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/quarkus-dev-ui-extension/quarkus-dev-ui-overview.html)
is available for users to play with the workflows.
+
+1. Navigate to the root directory of the example
+2. Execute `kn workflow run`
+3. Navigate to
`http://localhost:8080/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
to access the management console
+4. You can modify the project, any changes will be detected and the container
will update
+
+### Deploy the example to cluster
+
+Once the workflow is stable and working, `deploy` command allows users to
create deployments of the workflow on the targetted cluster. To deploy a
workflow application, [{product_name} plugin for Knative
CLI](https://sonataflow.org/serverlessworkflow/main/testing-and-troubleshooting/kn-plugin-workflow-overview.html)
relies on configuration in `<home_directory>/.kube/config`. If you cluster has
managed access, users need to login prior to the use of CLI.
+
+1. Create a namespace for your deployment `oc create namespace catfactexample`
+2. Navigate to the root directory of the example
+3. Execute `kn workflow deploy -n catfactexample`
+4. Access your cluster, you should see new deployment in `catfactexample`
namespace
+5. Management console can be accessed on the
`<WORKFLOW_GENERATED_ROUTE_URL>/q/dev-ui/org.apache.kie.sonataflow.sonataflow-quarkus-devui/workflows`
+
+### Undeploy the example from cluster
+
+In order to get rid of the deployment, `undeploy` command allows user to
cleanup the deployed resources.
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow undeploy -n catfactexample`
+3. The namespace is now clean and without any resources.
+
+### Deploy the example to cluster with different configuration
+
+By default, `deploy` command generates the Kubernetes definitions during the
deployment. In order to customize these files, use
`--custom-generated-manifests-dir=./manifests` parameter to store the generated
Kubernetes manifests. Once modified, use `--custom-manifests-dir=./manifests`
to use the already generated manifests.
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow deploy -n catfactexample
--custom-generated-manifests-dir=./manifests`
+3. Navigate to the `/.manifests` folder and modify the files.
+4. Navigate to root directory of the example.
+5. Execute `kn workflow deploy -n catfactexample
--custom-manifests-dir=./manifests`
+
+Another option is to use `gen-manifest` to create the Kubernetes manifests,
run `kn workflow gen-manifest --help` to see the documentation for this
command. The procedure to deploy is as follows:
+
+1. Navigate to the root directory of the example.
+2. Execute `kn workflow gen-manifest -n catfactexample --profile=preview
--custom-generated-manifests-dir=./manifests`
Review Comment:
Here things are clear that we are generating for the `preview` profile.
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/workflow.sw.json:
##########
@@ -0,0 +1,79 @@
+{
+ "id": "getCatFactInformation",
+ "version": "1.0",
+ "specVersion": "0.8.0",
+ "name": "Get cat fact",
+ "description": "Description",
+ "start": "GreetOrCatFact",
+ "functions": [
+ {
+ "name": "getCatFact",
+ "operation": "specs/catfacts.json#getRandomFact"
+ },
+ {
+ "name": "sysOutFunction",
+ "type": "custom",
+ "operation": "sysout"
+ }
+ ],
+ "states": [
+ {
+ "name": "GreetOrCatFact",
+ "type": "switch",
+ "dataConditions": [
+ {
+ "condition": "${ .fact == \"random\"}",
+ "transition": "GetRandomFact"
+ }
+ ],
+ "timeouts": {
Review Comment:
Timeouts are only implemented when we have a `switch` state based on
`"eventConditions"`. I think we can remove timeouts to not confuse a potential
user.
##########
serverless-operator-examples/serverless-workflow-get-random-catfact/workflow.sw.json:
##########
@@ -0,0 +1,79 @@
+{
+ "id": "getCatFactInformation",
+ "version": "1.0",
+ "specVersion": "0.8.0",
+ "name": "Get cat fact",
+ "description": "Description",
+ "start": "GreetOrCatFact",
+ "functions": [
+ {
+ "name": "getCatFact",
+ "operation": "specs/catfacts.json#getRandomFact"
+ },
+ {
+ "name": "sysOutFunction",
+ "type": "custom",
+ "operation": "sysout"
+ }
+ ],
+ "states": [
+ {
+ "name": "GreetOrCatFact",
+ "type": "switch",
+ "dataConditions": [
+ {
+ "condition": "${ .fact == \"random\"}",
+ "transition": "GetRandomFact"
+ }
+ ],
+ "timeouts": {
+ "stateExecTimeout": "P4D",
+ "eventTimeout" : "P4D"
+ },
+ "defaultCondition": {
+ "transition": "GetOneStaticFact"
+ }
+ },
+ {
+ "name": "GetOneStaticFact",
+ "type": "inject",
+ "data": {
+ "message": "Cats are very cute"
+ },
+ "transition": "PrintTheFact"
+ },
+ {
+ "name": "GetRandomFact",
+ "type": "operation",
+ "actions": [
+ {
+ "name": "getRandomFact",
+ "functionRef": {
+ "refName": "getCatFact"
+ }
+ }
+ ],
+ "transition": "PrintTheFact",
+ "timeouts": {
Review Comment:
For the state type `operation` we are not implementing the timeouts yet. I
think we can remove timeouts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
