Installation

Since the Orchestrator plugin for Red Hat Developer Hub relies on Serverless Workflow, it requires the OpenShift Serverless Workflow Operator to provide the primitives it relies on.

This Operator provides the necessary SonataFlow Custom Resources that Orchestrator uses to facilitate the execution of custom workflows.

Install Serverless Workflow Operator

Confirm the operator is installed by visiting the Installed Operators section of the OpenShift Web Console.

You must login as {openshift_admin_user} using the password {openshift_admin_password} to manage operators.

install operators

If the Operator is not installed, use Operator Hub to install it with Automatic Approval enabled:

  1. Visit Operator Hub and view the Red Hat OpenShift Serverless Operators - use this link to jump right there!

    serverless operators
  2. Select the OpenShift Serverless Logic Operator, select version 1.36.0, and click Install.

  3. On the install form, keep the default settings and click Install a final time.

  4. Wait for the installation to complete.

Add the Orchestrator Plugins to Red Hat Developer Hub

Your environment has been pre-configured with the necessary dynamic plugins, but they’re disabled by default.

The Setup Red Hat Developer Hub module provides an in-depth overview of Red Hat Developer Hub’s dynamic plugins feature. Visit that module if you’d like a deep-dive on deployment and configuration for Red Hat Developer Hub and the dynamic plugins feature.

Verify that the dynamic plugins have been configured correctly:

  1. Visit the ConfigMaps screen in the tssc-dh project. Login using:

    • Username: {openshift_admin_user}

    • Password: {openshift_admin_password}

  2. Select and view the YAML for the tssc-developer-hub-dynamic-plugins ConfigMap.

  3. Verify that the following plugins are listed in the plugins array:

    • @redhat/backstage-plugin-orchestrator

    • @redhat/backstage-plugin-orchestrator-backend-dynamic

    • @redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic

    • @redhat/backstage-plugin-orchestrator-form-widgets

  4. Inspect the @redhat/backstage-plugin-orchestrator-backend-dynamic - note that it has an additional dependencies property:

    dependencies:
      - ref: sonataflow
  5. Inspect the pluginConfig associated with the @redhat/backstage-plugin-scaffolder-backend-module-orchestrator-dynamic. Notice that it specifies a dataIndexService.url property? This is the URL to a component of the SonataFlow Platform that will be deployed in the same namespace as Red Hat Developer Hub.

    pluginConfig:
        orchestrator:
          dataIndexService:
            url: http://sonataflow-platform-data-index-service
  6. Before proceeding, edit the ConfigMap by changing disabled: true to disabled: false for the listed plugins, and clicking Save.

So, why are these additional keys provided to the plugins? In the case of dependencies.ref, it tells the Red Hat Developer Hub Operator to provision the SonataFlow components, specifically a SonataFlowPlatform CR. The dataIndexService.url instructs the plugin to fetch available Workflows from the SonataFlowPlatform deployed in the same namespace as Red Hat Developer Hub - you can opt to host and install the SonataFlowPlatform elsewhere if required.

Verify the SonataFlowPlatform

You’ve confirmed that the Orchestrator plugins are configured correctly - now you’ll confirm that the SonataFlowPlatform was created and the Pods are healthy.

  1. Return to the Topology View for the tssc-dh namespace and wait for the SonataFlowPlatform pods to become ready (dark blue circle). It might take a few minutes for both the Red Hat Developer Hub and SonataFlowPlatform pods to become ready and stabilise, since the SonataFlow pods depend on the new instance of Red Hat Developer Hub to initialise with the newly enabled plugins.

  2. Once ready, you should see the SonataFlowPlatform (or SFP for short) - click the three dots next to its name (sonataflow-platform) and select Edit SonataFlowPlatform to view the CR created as a result of the dependencies.ref you saw earlier.

    sonataflow platform topology
  3. Confirm that ownerReferences in the YAML view shows that the Red Hat Developer Hub instance is managing this SonataFlowPlatform.

  4. Additionally, you should notice that spec.services is connecting SonataFlow to the Red Hat Developer Hub PostgreSQL database - this is to manage and track workflow state.

    sonataflow db connection

Conclusion

Now that you’re familiar with the installation and configuration of the Orchestrator plugins, Operators, and backing SonataFlowPlatform, it’s time to learn about building and managing workflows.