About OpenShift Serverless

API versions are an important measure of the development status of certain features and custom resources in OpenShift Serverless. Creating resources on your cluster that do not use the correct API version can cause issues in your deployment.

The OpenShift Serverless Operator automatically upgrades older resources that use deprecated versions of APIs to use the latest version. For example, if you have created resources on your cluster that use older versions of the ApiServerSource API, such as v1beta1, the OpenShift Serverless Operator automatically updates these resources to use the v1 version of the API when this is available and the v1beta1 version is deprecated.

After they have been deprecated, older versions of APIs might be removed in any upcoming release. Using deprecated versions of APIs does not cause resources to fail. However, if you try to use a version of an API that has been removed, it will cause resources to fail. Ensure that your manifests are updated to use the latest version to avoid issues.

Features that are Generally Available (GA) are fully supported and are suitable for production use. Technology Preview (TP) features are experimental features and are not intended for production use. See the Technology Preview scope of support on the Red Hat Customer Portal for more information about TP features.

The following table provides information about which OpenShift Serverless features are GA and which are TP:

Some features that were Generally Available (GA) or a Technology Preview (TP) in previous releases have been deprecated or removed. Deprecated functionality is still included in OpenShift Serverless and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments.

For the most recent list of major functionality deprecated and removed within OpenShift Serverless, refer to the following table:

OpenShift Serverless 1.36.1 is now available. This release of OpenShift Serverless addresses identified Common Vulnerabilities and Exposures (CVEs) to enhance security and reliability. Fixed issues and known issues that pertain to OpenShift Serverless on OpenShift Container Platform are included in the following notes:

OpenShift Serverless 1.36 is now available. New features, updates, fixed issues, and known issues that pertain to OpenShift Serverless on OpenShift Container Platform are included in the following notes:

Knative Serving builds on Kubernetes to support deploying and serving of applications and functions as serverless containers. Serving simplifies the application deployment, dynamically scales based on in incoming traffic, and supports custom rollout strategies with traffic splitting.

Knative Serving includes the following features:

Knative Eventing provides a platform that offers composable primitives to enable late-binding event sources and event consumers.

Knative Eventing supports the following architectural cloud-native concepts:

You can write OpenShift Serverless Functions and deploy them as Knative Services, using Knative Serving and Eventing.

OpenShift Serverless Functions includes the following features:

With OpenShift Serverless Logic, you define declarative workflow models by using YAML or JSON files to orchestrate event-driven, serverless applications. You can visualize workflow execution to simplify debugging and optimization. Built-in error handling and fault tolerance help you manage errors and exceptions during workflow execution.

OpenShift Serverless Logic implements the Cloud Native Computing Foundation (CNCF) Serverless Workflow specification.

You can use the Knative (kn) CLI to create Knative resources from the command line or within shell scripts. Its extensive help pages and autocompletion reduce the need to memorize detailed Knative resource schemas.

The Knative (kn) CLI includes the following features:

Knative Serving defines a set of resources that manage the lifecycle, configuration, and traffic routing of serverless applications on a Kubernetes cluster.

Knative Eventing supports common event-driven use cases, including publishing and consuming events independently. It also introduces generic resource interfaces that define how components receive and process, and routed events within the system.

Knative Eventing supports the following use cases:

To enable delivery to many types of sinks, Knative Eventing defines the following generic interfaces that many Kubernetes resources can implement:

The Knative broker implementation for Apache Kafka provides integration options for you to use supported versions of the Apache Kafka message streaming platform with OpenShift Serverless. Kafka provides options for event source, channel, broker, and event sink capabilities.

Knative broker for Apache Kafka provides additional options, such as:

An event state includes one or more event definitions that specify the CloudEvent types the state listens to. You can use an event state to start a new workflow instance when it receives a designated CloudEvent, or pause an existing workflow instance until it receives one.

In an event state definition, the onEvents property groups CloudEvent types that trigger the same set of actions. The exclusive property determines how the system matches events. If exclusive is false, the system requires all CloudEvent types in the eventRefs array to match. Otherwise, any referenced CloudEvent type can trigger a match.

The following example shows event definitions, consisting of two CloudEvent types, including noisy and silent and you get an output similar to the following examples:

"events": [
    {
      "name": "noisyEvent",
      "source": "",
      "type": "noisy",
      "dataOnly" : "false"
    },
    {
      "name": "silentEvent",
      "source": "",
      "type": "silent"
    }
  ]

You can define an event state with separate onEvent items for noisy and silent CloudEvent types, and set the exclusive property to false to run different actions when both events occur.

{
    "name": "waitForEvent",
    "type": "event",
    "onEvents": [
      {
        "eventRefs": [
          "noisyEvent"
         ],
         "actions": [
           {
             "functionRef": "letsGetLoud"
           }
         ]
      },
      {
        "eventRefs": [
           "silentEvent"
        ],
        "actions": [
          {
            "functionRef": "beQuiet"
          }
        ]
      }
    ]
    ,
    "exclusive": false
  }

The Callback state performs an action and waits for an event that the action produces before it resumes the workflow. It invokes an asynchronous external service, making it suitable for fire&wait-for-result operations.

From a workflow perspective, an asynchronous service returns control to the caller immediately without waiting for the action to complete. After the action completes, the system publishes a CloudEvent to resume the workflow.

{
        "name": "CheckCredit",
        "type": "callback",
        "action": {
            "functionRef": {
                "refName": "callCreditCheckMicroservice",
                "arguments": {
                    "customer": "${ .customer }"
                }
            }
        },
        "eventRef": "CreditCheckCompletedEvent",
        "timeouts": {
          "stateExecTimeout": "PT15M"
        },
        "transition": "EvaluateDecision"
}

name: CheckCredit
type: callback
action:
  functionRef:
    refName: callCreditCheckMicroservice
    arguments:
      customer: "${ .customer }"
eventRef: CreditCheckCompletedEvent
timeouts:
  stateExecTimeout: PT15M
transition: EvaluateDecision

The action property defines a function call that triggers an external activity or service. After the action executes, the Callback state waits for a CloudEvent, which indicates the completion of the manual decision by the called service.

After the completion callback event is received, the Callback state completes its execution and transitions to the next defined workflow state or completes workflow execution if it is an end state.

Each workflow instance uses a data model. The data model consists of a JSON object, regardless of whether the workflow file uses YAML or JSON. The initial content of the JSON object depends on how you start the workflow. If you start the workflow by using a CloudEvent, the workflow reads content from the data property. If you start the workflow through an HTTP POST request, the workflow reads content from the request body.

JSON Query (JQ) expressions interact with the data model. The system supports JsonPath and JQ expression languages, and JQ serves as the default. You can change the expression language to JsonPath by using the expressionLang property.

{
      "name": "max",
      "type": "expression",
      "operation": "{max: .numbers | max_by(.x), min: .numbers | min_by(.y)}"
    }

With OpenShift Serverless Logic, you define explicit error handling in your workflow model instead of relying on generic mechanisms. Explicit error handling helps you manage errors that occur during interactions between the workflow and external systems. When an error occurs, it changes the normal workflow sequence. The workflow transitions to an alternative state that can handle the error instead of moving to the predefined state.

Each workflow state defines its own error handling for issues that occur during its execution. Error handling in one state does not handle errors that occur in another state during workflow execution.

If the workflow encounters an unknown error that the definition does not handle explicitly, the runtime reports the error and stops workflow execution.

{
  "errors": "file://documents/reusable/errors.json"
}

errors: file://documents/reusable/errors.yaml

{
  "errors": [
    {
      "name": "Service not found error",
      "code": "404",
      "description": "Server has not found anything matching the provided service endpoint information"
    }
  ]
}

errors:
  - name: Service not found error
    code: '404'
    description: Server has not found anything matching the provided service endpoint information

OpenShift Serverless Logic supports two types of schema definitions: input schema definition and output schema definition.

"dataInputSchema": {
   "schema": "URL_to_json_schema",
   "failOnValidationErrors": false
}

"extensions" : [ {
      "extensionid": "workflow-output-schema",
      "outputSchema": {
         "schema" : "URL_to_json_schema",
          "failOnValidationErrors": false
     }
  } ]

OpenShift Serverless Logic supports the custom function type, which enables the implementation to extend the function definitions capability. By combining with the operation string, you can use a list of predefined function types.

{
  "functions": [
    {
      "name": "logInfo",
      "type": "custom",
      "operation": "sysout:INFO"
    }
  ]
}

{
  "states": [
    {
      "name": "myState",
      "type": "operation",
      "actions": [
        {
          "name": "printAction",
          "functionRef": {
            "refName": "logInfo",
            "arguments": {
              "message": "\"Workflow model is \\(.)\""
            }
          }
        }
      ]
    }
  ]
}

{
  "functions": [
    {
      "name": "myFunction",
      "type": "custom",
      "operation": "service:java:com.acme.MyInterfaceOrClass::myMethod"
    }
  ]
}

$ kn service list
NAME                              URL                                                                      LATEST                                  AGE     CONDITIONS   READY   REASON
custom-function-knative-service   http://custom-function-knative-service.default.10.109.169.193.sslip.io   custom-function-knative-service-00001   3h16m   3 OK / 3     True

  "functions": [
    {
      "name": "greet",
      "type": "custom",
      "operation": "knative:services.v1.serving.knative.dev/custom-function-knative-service?path=/plainJsonFunction",
    }
  ]

  {
  "functions": [
    {
      "name": "multiplyAllByAndSum",
      "type": "custom",
      "operation": "rest:post:/numbers/{multiplier}/multiplyByAndSum"
    }
  ]
}

OpenShift Serverless Logic defines several timeouts configurations that you can use to configure maximum times for the workflow execution in different scenarios. You can configure how long a workflow can wait for an event to arrive when it is in a given state or the maximum execution time for the workflow.

Regardless of where you define it, configure a timeout as a duration that starts when the referenced workflow element becomes active. Timeouts use the ISO 8601 date and time standard to specify durations and follow the format PnDTnHnMn.nS, where days equal exactly 24 hours. For example, PT15M sets a duration of 15 minutes, and P2DT3H4M sets a duration of 2 days, 3 hours, and 4 minutes.

  {
  "id": "workflow_timeouts",
  "version": "1.0",
  "name": "Workflow Timeouts",
  "description": "Simple workflow to show the workflowExecTimeout working",
  "start": "PrintStartMessage",
  "timeouts": {
    "workflowExecTimeout": "PT1H"
  } ...
}

{
 "name": "CallbackState",
 "type": "callback",
 "action": {
   "name": "callbackAction",
   "functionRef": {
     "refName": "callbackFunction",
     "arguments": {
       "input": "${\"callback-state-timeouts: \" + $WORKFLOW.instanceId + \" has executed the callbackFunction.\"}"
     }
   }
 },
 "eventRef": "callbackEvent",
 "transition": "CheckEventArrival",
 "onErrors": [
   {
     "errorRef": "callbackError",
     "transition": "FinalizeWithError"
   }
 ],
 "timeouts": {
   "eventTimeout": "PT30S"
 }
}

{
    "name": "ChooseOnEvent",
    "type": "switch",
    "eventConditions": [
    {
        "eventRef": "visaApprovedEvent",
        "transition": "ApprovedVisa"
    },
    {
        "eventRef": "visaDeniedEvent",
        "transition": "DeniedVisa"
    }
    ],
        "defaultCondition": {
        "transition": "HandleNoVisaDecision"
    },
        "timeouts": {
        "eventTimeout": "PT5S"
    }
}

{
  "name": "WaitForEvent",
  "type": "event",
  "onEvents": [
    {
      "eventRefs": [
        "event1"
      ],
      "eventDataFilter": {
        "data": "${ \"The event1 was received.\" }",
        "toStateData": "${ .exitMessage }"
      },
      "actions": [
        {
          "name": "printAfterEvent1",
          "functionRef": {
            "refName": "systemOut",
            "arguments": {
              "message": "${\"event-state-timeouts: \" + $WORKFLOW.instanceId + \" executing actions for event1.\"}"
            }
          }
        }
      ]
    },
    {
      "eventRefs": [
        "event2"
      ],
      "eventDataFilter": {
        "data": "${ \"The event2 was received.\" }",
        "toStateData": "${ .exitMessage }"
      },
      "actions": [
        {
          "name": "printAfterEvent2",
          "functionRef": {
            "refName": "systemOut",
            "arguments": {
              "message": "${\"event-state-timeouts: \" + $WORKFLOW.instanceId + \" executing actions for event2.\"}"
            }
          }
        }
      ]
    }
  ],
  "timeouts": {
    "eventTimeout": "PT30S"
  },
  "transition": "PrintExitMessage"
}

OpenShift Serverless Logic serializes the execution of parallel tasks. The term parallel does not imply simultaneous execution; it means that branches have no logical dependency on each other. An inactive branch can start or resume a task without waiting for an active branch to complete if the active branch suspends its execution, for example, while waiting for an event.

A parallel state splits the current workflow execution path into many branches, each with its own path. The workflow executes these paths independently and then joins them back into a single path based on the completionType parameter.

The following example shows a parallel workflow in JSON format:

 {
     "name":"ParallelExec",
     "type":"parallel",
     "completionType": "allOf",
     "branches": [
        {
          "name": "Branch1",
          "actions": [
            {
                "functionRef": {
                    "refName": "functionNameOne",
                    "arguments": {
                        "order": "${ .someParam }"
                    }
                }
            }
        ]
        },
        {
          "name": "Branch2",
          "actions": [
              {
                  "functionRef": {
                      "refName": "functionNameTwo",
                      "arguments": {
                          "order": "${ .someParam }"
                      }
                  }
              }
          ]
        }
     ],
     "end": true
}

The following example shows a parallel workflow in YAML format:

name: ParallelExec
type: parallel
completionType: allOf
branches:
- name: Branch1
  actions:
  - functionRef:
      refName: functionNameOne
      arguments:
        order: "${ .someParam }"
- name: Branch2
  actions:
  - functionRef:
      refName: functionNameTwo
      arguments:
        order: "${ .someParam }"
end: true

In the earlier examples, the allOf defines all branches must complete execution before the state can change or end. This is the default value if this parameter is not set.

The Red Hat Knowledgebase provides rich content aimed at helping you make the most of Red Hat’s products and technologies. The Red Hat Knowledgebase consists of articles, product documentation, and videos outlining best practices on installing, configuring, and using Red Hat products. In addition, you can search for solutions to known issues, each providing concise root cause descriptions and remedial steps.

In case of an OpenShift Container Platform issue, you can perform an initial search to find if a solution already exists within the Red Hat Knowledgebase.

It is recommended to include data gathered using the oc adm must-gather command as a starting point, plus any issue specific data that is not collected by that command.

When you open a support case, share debugging information about your cluster with Red Hat Support. You can use the must-gather tool to collect diagnostic information about your OpenShift Container Platform cluster, including data related to OpenShift Serverless. For faster support, give diagnostic information for both OpenShift Container Platform and OpenShift Serverless.

You can use the oc adm must-gather CLI command to collect information about your cluster, including features and objects associated with OpenShift Serverless. To collect OpenShift Serverless data with must-gather, you must specify the OpenShift Serverless image and the image tag for your installed version of OpenShift Serverless.