This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Infrastructure

1 - Simple Escalation

Simple escalation workflow

An escalation workflow integrated with Atlassian JIRA using SonataFlow.

Prerequisite

  • Access to a Jira server (URL, user and API token)
  • Access to an OpenShift cluster with admin Role

Workflow diagram

Escalation workflow diagram

Note: The value of the .jiraIssue.fields.status.statusCategory.key field is the one to be used to identify when the done status is reached, all the other similar fields are subject to translation to the configured language and cannot be used for a consistent check.

Application configuration

Application properties can be initialized from environment variables before running the application:

Environment variableDescriptionMandatoryDefault value
JIRA_URLThe Jira server URL
JIRA_USERNAMEThe Jira server username
JIRA_API_TOKENThe Jira API Token
JIRA_PROJECTThe key of the Jira project where the escalation issue is createdTEST
JIRA_ISSUE_TYPEThe ID of the Jira issue type to be created
OCP_API_SERVER_URLThe OpensShift API Server URL
OCP_API_SERVER_TOKENThe OpensShift API Server Token
ESCALATION_TIMEOUT_SECONDSThe number of seconds to wait before triggering the escalation request, after the issue has been created60
POLLING_PERIODICITY(1)The polling periodicity of the issue state checker, according to ISO 8601 duration formatPT6S

(1) This is still hardcoded as PT5S while waiting for a fix to KOGITO-9811

How to run

mvn clean quarkus:dev

Example of POST to trigger the flow (see input schema in ocp-onboarding-schema.json):

curl -XPOST -H "Content-Type: application/json" http://localhost:8080/ticket-escalation -d '{"namespace": "_YOUR_NAMESPACE_"}'

Tips:

  • Visit Workflow Instances
  • Visit (Data Index Query Service)[http://localhost:8080/q/graphql-ui/]

2 - Move2Kube

Move2kube (m2k) workflow

Context

This workflow is using https://move2kube.konveyor.io/ to migrate the existing code contained in a git repository to a K8s/OCP platform.

Once the transformation is over, move2kube provides a zip file containing the transformed repo.

Design diagram

sequence_diagram.svg design.svg

Workflow

m2k.svg

Note that if an error occurs during the migration planning there is no feedback given by the move2kube instance API. To overcome this, we defined a maximum amount of retries (move2kube_get_plan_max_retries) to execute while getting the planning before exiting with an error. By default the value is set to 10 and it can be overridden with the environment variable MOVE2KUBE_GET_PLAN_MAX_RETRIES.

Workflow application configuration

Move2kube workflow

Application properties can be initialized from environment variables before running the application:

Environment variableDescriptionMandatoryDefault value
MOVE2KUBE_URLThe move2kube instance server URL
BACKSTAGE_NOTIFICATIONS_URLThe backstage server URL for notifications
NOTIFICATIONS_BEARER_TOKENThe authorization bearer token to use to send notifications
MOVE2KUBE_GET_PLAN_MAX_RETRIESThe amount of retries to get the plan before failing the workflow10

m2k-func serverless function

Application properties can be initialized from environment variables before running the application:

Environment variableDescriptionMandatoryDefault value
MOVE2KUBE_APIThe move2kube instance server URL
SSH_PRIV_KEY_PATHThe absolute path to the SSH private key
BROKER_URLThe knative broker URL
LOG_LEVELThe log levelINFO

Components

The use case has the following components:

  1. m2k: the Sonataflow resource representing the workflow. A matching Deployment is created by the sonataflow operator..
  2. m2k-save-transformation-func: the Knative Service resource that holds the service retrieving the move2kube instance output and saving it to the git repository. A matching Deployment is created by the Knative deployment.
  3. move2kube instance: the Deployment running the move2kube instance
  4. Knative Trigger:
    1. m2k-save-transformation-event: event sent by the m2k workflow that will trigger the execution of m2k-save-transformation-func.
    2. transformation-saved-trigger-m2k: event sent by m2k-save-transformation-func if/once the move2kube output is successfully saved to the git repository.
    3. error-trigger-m2k: event sent by m2k-save-transformation-func if an error while saving the move2kube output to the git repository.
  5. The Knative Broker named default which link the components together.

Installation

See official installation guide

Usage

  1. Create a workspace and a project under it in your move2kube instance
    • you can reach your move2kube instance by running
    oc -n sonataflow-infra get routes
    
    Sample output:
    NAME                                   HOST/PORT                                                                                             PATH   SERVICES                                 PORT    TERMINATION   WILDCARD
    move2kube-route                        move2kube-route-sonataflow-infra.apps.cluster-c68jb.dynamic.redhatworkshops.io                               move2kube-svc                            <all>   edge          None
    
  2. Go to the backstage instance.

To get it, you can run

oc -n rhdh-operator get routes

Sample output:

NAME                  HOST/PORT                                                                            PATH   SERVICES              PORT           TERMINATION     WILDCARD
backstage-backstage   backstage-backstage-rhdh-operator.apps.cluster-c68jb.dynamic.redhatworkshops.io   /      backstage-backstage   http-backend   edge/Redirect   None
  1. Go to the Orchestrator page.

  2. Click on Move2Kube workflow and then click the run button on the top right of the page.

  3. In the repositoryURL field, put the URL of your git project

  4. In the sourceBranch field, put the name of the branch holding the project you want to transform

    • ie: main
  5. In the targetBranch field, put the name of the branch in which you want the move2kube output to be persisted. If the branch exists, the workflow will fail

    • ie: move2kube-output
  6. In the workspaceId field, put the ID of the move2kube instance workspace to use for the transformation. Use the ID of the workspace created at the 1st step.

    • ie: a46b802d-511c-4097-a5cb-76c892b48d71
  7. In the projectId field, put the ID of the move2kube instance project under the previous workspace to use for the transformation. Use the ID of the project created at the 1st step.

    • ie: 9c7f8914-0b63-4985-8696-d46c17ba4ebe
  8. Then click on nextStep

  9. Click on run to trigger the execution

  10. Once a new transformation has started and is waiting for your input, you will receive a notification with a link to the Q&A

  11. Once you completed the Q&A, the process will continue and the output of the transformation will be saved in your git repository, you will receive a notification to inform you of the completion of the workflow.

    • You can now clone the repository and checkout the output branch to deploy your manifests to your cluster! You can check the move2kube documention if you need guidance on how to deploy the generated artifacts.