ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOFFor an overview of OpenShift Serverless functionality, see About OpenShift Serverless.
|
OpenShift Serverless is based on the open source Knative project. For details about the latest Knative component releases, see the Knative blog. |
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.
OpenShift Serverless now uses Knative Serving 0.25.
OpenShift Serverless now uses Knative Eventing 0.25.
OpenShift Serverless now uses Kourier 0.25.
OpenShift Serverless now uses Knative kn CLI 0.25.
OpenShift Serverless now uses Knative Kafka 0.25.
The kn func CLI plug-in now uses func 0.19.
The KafkaBinding API is deprecated in OpenShift Serverless 1.19.0 and will be removed in a future release.
HTTPS redirection is now supported and can be configured either globally for a cluster or per each Knative service.
In previous releases, the Kafka channel dispatcher waited only for the local commit to succeed before responding, which might have caused lost events in the case of an Apache Kafka node failure. The Kafka channel dispatcher now waits for all in-sync replicas to commit before responding.
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": EOFThe following workaround exists for this issue:
Update the podman service by adding --time=0 to the service ExecStart definition:
ExecStart=/usr/bin/podman $LOGGING system service --time=0Restart the podman service by running the following commands:
$ systemctl --user daemon-reload$ systemctl restart --user podman.socketAlternatively, you can expose the podman API by using TCP:
$ podman system service --time=0 tcp:127.0.0.1:5534 &
export DOCKER_HOST=tcp://127.0.0.1:5534OpenShift Serverless now uses Knative Serving 0.24.0.
OpenShift Serverless now uses Knative Eventing 0.24.0.
OpenShift Serverless now uses Kourier 0.24.0.
OpenShift Serverless now uses Knative kn CLI 0.24.0.
OpenShift Serverless now uses Knative Kafka 0.24.7.
The kn func CLI plug-in now uses func 0.18.0.
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
...You can now use emptyDir volumes with OpenShift Serverless. See the OpenShift Serverless documentation about Knative Serving for details.
Rust templates are now available when you create a function using kn func.
The prior 1.4 version of Camel-K was not compatible with OpenShift Serverless 1.17.0. The issue in Camel-K has been fixed, and Camel-K version 1.4.1 can be used with OpenShift Serverless 1.17.0.
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.
OpenShift Serverless now uses Knative Serving 0.23.0.
OpenShift Serverless now uses Knative Eventing 0.23.0.
OpenShift Serverless now uses Kourier 0.23.0.
OpenShift Serverless now uses Knative kn CLI 0.23.0.
OpenShift Serverless now uses Knative Kafka 0.23.0.
The kn func CLI plug-in now uses func 0.17.0.
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"
...mTLS functionality is now Generally Available (GA).
TypeScript templates are now available when you create a function using kn func.
Changes to API versions in Knative Eventing 0.23.0:
The v1alpha1 version of the KafkaChannel API, which was deprecated in OpenShift Serverless version 1.14.0, has been removed. If the ChannelTemplateSpec parameters of your config maps contain references to this older version, you must update this part of the spec to use the correct API version.
If you try to use an older version of the Knative kn CLI with a newer OpenShift Serverless release, the API is not found and an error occurs.
For example, if you use the 1.16.0 release of the kn CLI, which uses version 0.22.0, with the 1.17.0 OpenShift Serverless release, which uses the 0.23.0 versions of the Knative Serving and Knative Eventing APIs, the CLI does not work because it continues to look for the outdated 0.22.0 API versions.
Ensure that you are using the latest kn CLI version for your OpenShift Serverless release to avoid issues.
Kafka channel metrics are not monitored or shown in the corresponding web console dashboard in this release. This is due to a breaking change in the Kafka dispatcher reconciling process.
If you create a new subscription for a Kafka channel, or a new Kafka source, there might be a delay in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reports a ready status.
As a result, messages that are sent during the time when the data plane is not reporting a ready status might not be delivered to the subscriber or sink.
For more information about this issue and possible workarounds, see Knowledge Article #6343981.
The Camel-K 1.4 release is not compatible with OpenShift Serverless version 1.17.0. This is because Camel-K 1.4 uses APIs that were removed in Knative version 0.23.0. There is currently no workaround available for this issue. If you need to use Camel-K 1.4 with OpenShift Serverless, do not upgrade to OpenShift Serverless version 1.17.0.
|
The issue has been fixed, and Camel-K version 1.4.1 is compatible with OpenShift Serverless 1.17.0. |
OpenShift Serverless now uses Knative Serving 0.22.0.
OpenShift Serverless now uses Knative Eventing 0.22.0.
OpenShift Serverless now uses Kourier 0.22.0.
OpenShift Serverless now uses Knative kn CLI 0.22.0.
OpenShift Serverless now uses Knative Kafka 0.22.0.
The kn func CLI plug-in now uses func 0.16.0.
The kn func emit command has been added to the functions kn plug-in. You can use this command to send events to test locally deployed functions.
You must upgrade OpenShift Container Platform to version 4.6.30, 4.7.11, or higher before upgrading to OpenShift Serverless 1.16.0.
The AMQ Streams Operator might prevent the installation or upgrade of the OpenShift Serverless Operator. If this happens, the following error is thrown by Operator Lifecycle Manager (OLM):
WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.You can fix this issue by uninstalling the AMQ Streams Operator before installing or upgrading the OpenShift Serverless Operator. You can then reinstall the AMQ Streams Operator.
If Service Mesh is enabled with mTLS, metrics for Knative Serving are disabled by default because Service Mesh prevents Prometheus from scraping metrics. For instructions on enabling Knative Serving metrics for use with Service Mesh and mTLS, see the "Integrating Service Mesh with OpenShift Serverless" section of the Serverless documentation.
If you deploy Service Mesh CRs with the Istio ingress enabled, you might see the following warning in the istio-ingressgateway pod:
2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 foundYour Knative services might also not be accessible.
You can use the following workaround to fix this issue by recreating the knative-local-gateway service:
Delete the existing knative-local-gateway service in the istio-system namespace:
$ oc delete services -n istio-system knative-local-gatewayCreate and apply a knative-local-gateway service that contains the following YAML:
apiVersion: v1
kind: Service
metadata:
name: knative-local-gateway
namespace: istio-system
labels:
experimental.istio.io/disable-gateway-port-translation: "true"
spec:
type: ClusterIP
selector:
istio: ingressgateway
ports:
- name: http2
port: 80
targetPort: 8081If you have 1000 Knative services on a cluster, and then perform a reinstall or upgrade of Knative Serving, there is a delay when you create the first new service after the KnativeServing custom resource (CR) becomes Ready.
The 3scale-kourier-control service reconciles all previously existing Knative services before processing the creation of a new service, which causes the new service to spend approximately 800 seconds in an IngressNotConfigured or Unknown state before the state updates to Ready.
If you create a new subscription for a Kafka channel, or a new Kafka source, there might be a delay in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reports a ready status.
As a result, messages that are sent during the time when the data plane is not reporting a ready status might not be delivered to the subscriber or sink.
For more information about this issue and possible workarounds, see Knowledge Article #6343981.