Chapter 10. OpenShift Serverless Release Notes

The KnativeServing object’s API group has changed in this release from serving.knative.dev to operator.knative.dev. You will need to adjust any of your scripts or applications that rely on the old API group to use the new API group. The OpenShift Serverless installation instructions have been updated to use the new API group.

When upgrading from OpenShift Serverless 1.3.0 to 1.4.0, the OpenShift Serverless Operator will create a KnativeServing custom resource (CR) in the new API group for you. This CR will be a mirror of the KnativeServing CR in the old group that was used in OpenShift Serverless 1.3.0.

If you need to keep using the old group temporarily, you can use the old CR as before. However, this CR is deprecated and will eventually be removed.

Once you have updated references to the new API group, you can remove any older CR versions and use the newly deployed KnativeServing CR instead. To safely do this without downtime, remove the owner reference from the newly deployed KnativeServing CR using:

 $ oc edit knativeserving.operator.knative.dev knative-serving -n knative-serving

After the owner reference has been removed, you can safely remove any older CR versions and start using the new one.

Unqualified usage of knativeserving in oc commands no longer works because of the migration to a new API group. For example, this command will not work:

$ oc get knativeserving -n knative-serving

Use the explicit fully-qualified format instead. For example:

$ oc get knativeserving.operator.knative.dev -n knative-serving

In version 1.2.0, the OpenShift Serverless Operator inspects network policies for namespaces.

If no network policy exists, the Operator automatically creates a wide open policy, to ensure that traffic can flow in and out of the namespace and OpenShift routes can be used.

If there is an existing network policy, OpenShift Serverless will not create a new policy. The Operator expects the user to continue managing their own network policies as needed for their applications. For example, the user must set policies that allow traffic to flow in and out of the namespace, and allow OpenShift routes to still be used after the namespace is added to a ServiceMeshMemberRoll.

If you are upgrading the OpenShift Serverless from version 1.1.0 to version 1.2.0 and you have set up a ServiceMeshControlPlane and ServiceMeshMemberRoll to work with your Knative Serving instance, you must remove the knative-serving namespace and any other namespaces that contain Knative Services from the ServiceMeshMemberRoll in istio-system.

You can also delete the ServiceMeshControlPlane from the namespace entirely if it is not required for other applications.

Once the upgrade starts, existing services will continue to work as before, but new Services will never become ready. Once you unblock the release by removing the knative-serving and any other relevant namespaces from the ServiceMeshMemberRoll, there will be a brief outage to all active Services. This will fix itself. Make sure that you remove all namespaces containing Knative Services from the original ServiceMeshMemberRoll.

Users who were not project administrators would previously see the following error when using OpenShift Serverless:

revisions.serving.knative.dev: User "sounds" cannot list resource "revisions

This issue has now been fixed with the addition of new RBAC rules.