Chapter 1. Release notes

OpenShift Serverless Logic is now generally available (GA). This release includes an overview of OpenShift Serverless Logic; instructions on creating, running, and deploying workflows; and guidelines for the installation and uninstallation of OpenShift Serverless Logic Operator. Additionally, it includes steps for configuring OpenAPI services and endpoints, and techniques for troubleshooting the services. For more information, see OpenShift Serverless Logic overview.

You can also refer to the additional documentation. For more details, see the Serverless Logic documentation.

Building and deploying a function using Podman version 4.6 fails with the invalid pull policy "1" error.

To work around this issue, use Podman version 4.5.

Serverless Logic, which is available as a Technology Preview (TP) feature, has been updated.

See the Serverless Logic documentation for usage instructions.

Building and deploying a function using Podman version 4.6 fails with the invalid pull policy "1" error.

To work around this issue, use Podman version 4.5.

Serverless Logic, which is available as a Technology Preview (TP) feature, has been updated.

See the Serverless Logic documentation for usage instructions.

Integrating Red Hat OpenShift Service Mesh with Serverless when Kourier is enabled is now deprecated. Use net-istio instead of net-kourier for Service Mesh integration.

See the "Integrating Red Hat OpenShift Service Mesh with Serverless" section for details.

The PodDistruptionBudget and HorizontalPodAutoscaler objects have been added for the 3scale-kourier-gateway deployment.

Previously, when deploying Knative Eventing with full Red Hat OpenShift Service Mesh integration and with STRICT peer authentication, the PingSource adapter metrics were unavailable.

This has been fixed, and the PingSource adapter metrics are now collected using a different job and service label value. The previous value was pingsource-mt-adapter, the new value is pingsource-mt-adapter-sm-service.

Serverless Logic is now available as a Technology Preview (TP) feature.

See the Serverless Logic documentation for details.

Beginning with OpenShift Serverless 1.30.0, the following runtime environments are supported on IBM zSystems using the s2i builder:

Eventing integration with Red Hat OpenShift Service Mesh is now available as a Technology Preview (TP) feature.

The integration includes the following:

OpenShift Serverless Functions users now have the ability to override the readiness and liveness probe values in the func.yaml file for individual Quarkus functions.

See "Functions development reference guide" for guidance on Quarkus, TypeScript, and Node.js functions.

Beginning with OpenShift Serverless 1.30.0, Kourier controller and gateway manifests have the following limits and requests by default:

Previously, the 3scale-kourier-gateway pod was sending thousands of net-kourier-controller DNS queries daily. New queries were being sent for each NXDOMAIN reply. This continued until the correct DNS query was produced.

The query now has the net-kourier-controller.knative-serving-ingress.svc.<cluster domain>. fully-qualified domain name (FQDN) by default, which solves the problem.

Building and deploying a function using Podman version 4.6 fails with the invalid pull policy "1" error.

To work around this issue, use Podman version 4.5.

Beginning with OpenShift Serverless 1.29, the different product versions are available as follows:

In OpenShift Serverless 1.29 or later, the following components of Knative Eventing will be scaled down from two pods to one:

The serverless.openshift.io/enable-secret-informer-filtering annotation for the Serving CR is now deprecated. The annotation is valid only for Istio, and not for Kourier.

With OpenShift Serverless 1.28, the OpenShift Serverless Operator allows injecting the environment variable ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID for both net-istio and net-kourier.

If you enable secret filtering, all of your secrets need to be labeled with networking.internal.knative.dev/certificate-uid: "<id>". Otherwise, Knative Serving does not detect them, which leads to failures. You must label both new and existing secrets.

In one of the following OpenShift Serverless releases, secret filtering will become enabled by default. To prevent failures, label your secrets in advance.

Currently, runtimes for Python are not supported for OpenShift Serverless Functions on IBM Power, IBM zSystems, and IBM® LinuxONE.

Node.js, TypeScript, and Quarkus functions are supported on these architectures.

On the Windows platform, Python functions cannot be locally built, run, or deployed using the Source-to-Image builder due to the app.sh file permissions.

To work around this problem, use the Windows Subsystem for Linux.

Namespace-scoped brokers might leave ClusterRoleBindings in the user namespace even after deletion of namespace-scoped brokers.

If this happens, delete the ClusterRoleBinding named rbac-proxy-reviews-prom-rb-knative-kafka-broker-data-plane-{{.Namespace}} in the user namespace.

The new trigger filters feature is now available as a Developer Preview. It allows users to specify a set of filter expressions, where each expression evaluates to either true or false for each event.

To enable new trigger filters, add the new-trigger-filters: enabled entry in the section of the KnativeEventing type in the operator config map:

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
...
...
spec:
  config:
    features:
      new-trigger-filters: enabled
...

Knative Operator 1.3 adds the updated v1beta1 version of the API for operator.knative.dev.

To update from v1alpha1 to v1beta1 in your KnativeServing and KnativeEventing custom resource config maps, edit the apiVersion key:

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
...

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
...

Knative Kafka broker is now GA. Knative Kafka broker is a highly performant implementation of the Knative broker API, directly targeting Apache Kafka.

It is recommended to not use the MT-Channel-Broker, but the Knative Kafka broker instead.

The Knative Serving Controller pod adds a new informer to watch secrets in the cluster. The informer includes the secrets in the cache, which increases memory consumption of the controller pod.

If the pod runs out of memory, you can work around the issue by increasing the memory limit for the deployment.

Integrating OpenShift Serverless with Red Hat OpenShift Service Mesh causes the net-istio-controller pod to run out of memory on startup when too many secrets are present on the cluster.

It is now possible to enable secret filtering, which causes net-istio-controller to consider only secrets with a networking.internal.knative.dev/certificate-uid label, thus reducing the amount of memory needed.

In OpenShift Serverless 1.23, support for KafkaBindings and the kafka-binding webhook were removed. However, an existing kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration might remain, pointing to the kafka-source-webhook service, which no longer exists.

For certain specifications of KafkaBindings on the cluster, kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration might be configured to pass any create and update events to various resources, such as Deployments, Knative Services, or Jobs, through the webhook, which would then fail.

To work around this issue, manually delete kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration from the cluster after upgrading to OpenShift Serverless 1.23:

$ oc delete mutatingwebhookconfiguration kafkabindings.webhook.kafka.sources.knative.dev

Running OpenShift Serverless with a large number of Knative services can cause Knative activator pods to run close to their default memory limits of 600MB. These pods might be restarted if memory consumption reaches this limit. Requests and limits for the activator deployment can be configured by modifying the KnativeServing custom resource:

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  deployments:
  - name: activator
    resources:
    - container: activator
      requests:
        cpu: 300m
        memory: 60Mi
      limits:
        cpu: 1000m
        memory: 1000Mi

Currently, the domain mapping controller cannot process the URI of a broker, which contains a path that is currently not supported.

This means that, if you want to use a DomainMapping custom resource (CR) to map a custom domain to a broker, you must configure the DomainMapping CR with the broker’s ingress service, and append the exact path of the broker to the custom domain:

apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
  name: <domain-name>
  namespace: knative-eventing
spec:
  ref:
    name: broker-ingress
    kind: Service
    apiVersion: v1

The URI for the broker is then <domain-name>/<broker-namespace>/<broker-name>.

The Kafka broker is now available as a Technology Preview.

OpenShift Serverless deploys Knative services with a default address that uses HTTPS. When sending an event to a resource inside the cluster, the sender does not have the cluster certificate authority (CA) configured. This causes event delivery to fail, unless the cluster uses globally accepted certificates.

For example, an event delivery to a publicly accessible address works:

$ kn event send --to-url https://ce-api.foo.example.com/

On the other hand, this delivery fails if the service uses a public address with an HTTPS certificate issued by a custom CA:

$ kn event send --to Service:serving.knative.dev/v1:event-display

Sending an event to other addressable objects, such as brokers or channels, is not affected by this issue and works as expected.

If you create a Springboot function project directory with the kn func create command, subsequent running of the kn func build command fails with this error message:

[analyzer] no stack metadata found at path ''
[analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycle

As a workaround, you can change the builder property to gcr.io/paketo-buildpacks/builder:base in the function configuration file func.yaml.

Deploying a function using the gcr.io registry fails with this error message:

Error: failed to get credentials: failed to verify credentials: status code: 404

As a workaround, use a different registry than gcr.io, such as quay.io or docker.io.

TypeScript functions created with the http template fail to deploy on the cluster.

As a workaround, in the func.yaml file, replace the following section:

buildEnvs: []

with this:

buildEnvs:
- name: BP_NODE_RUN_SCRIPTS
  value: build

In func version 0.20, some runtimes might be unable to build a function by using podman. You might see an error message similar to the following:

ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

In func version 0.19, some runtimes might be unable to build a function by using podman. You might see an error message similar to the following:

ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

In the upcoming OpenShift Serverless 1.19.0 release, the URL scheme of external routes will default to HTTPS for enhanced security.

If you do not want this change to apply for your workloads, you can override the default setting before upgrading to 1.19.0, by adding the following YAML to your KnativeServing custom resource (CR):

...
spec:
  config:
    network:
      defaultExternalScheme: "http"
...

If you want the change to apply in 1.18.0 already, add the following YAML:

...
spec:
  config:
    network:
      defaultExternalScheme: "https"
...

In the upcoming OpenShift Serverless 1.19.0 release, the default service type by which the Kourier Gateway is exposed will be ClusterIP and not LoadBalancer.

If you do not want this change to apply to your workloads, you can override the default setting before upgrading to 1.19.0, by adding the following YAML to your KnativeServing custom resource (CR):

...
spec:
  ingress:
    kourier:
      service-type: LoadBalancer
...

Previously, if you created a new subscription for a Kafka channel, or a new Kafka source, a delay was possible in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reported a ready status.

As a result, messages that were sent during the time when the data plane was not reporting a ready status, might not have been delivered to the subscriber or sink.

In OpenShift Serverless 1.18.0, the issue is fixed and the initial messages are no longer lost. For more information about the issue, see Knowledgebase Article #6343981.

Older versions of the Knative kn CLI might use older versions of the Knative Serving and Knative Eventing APIs. For example, version 0.23.2 of the kn CLI uses the v1alpha1 API version.

On the other hand, newer releases of OpenShift Serverless might no longer support older API versions. For example, OpenShift Serverless 1.18.0 no longer supports version v1alpha1 of the kafkasources.sources.knative.dev API.

Consequently, using an older version of the Knative kn CLI with a newer OpenShift Serverless might produce an error because the kn cannot find the outdated API. For example, version 0.23.2 of the kn CLI does not work with OpenShift Serverless 1.18.0.

To avoid issues, use the latest kn CLI version available for your OpenShift Serverless release. For OpenShift Serverless 1.18.0, use Knative kn CLI 0.24.0.