Experimental features

In Knative we want to keep the innovation alive, experimenting and delivering new features without affecting the stability of the project.

In order to achieve that goal in Knative Eventing, we have a process to include new features. This allows users like you to try out new features and provide feedback back to the project.

This document explains how to enable experimental features and which ones are available today.

For more details about the process, the feature phases, quality requirements and guarantees, check out the Experimental features process documentation.

Warning

Depending on the feature stage, an experimental feature might be unstable and break your Knative setup or even your cluster setup, use them with caution. For more details about quality guarantees, check out the Feature stage definition.

Before you begin

You must have a Knative cluster running with the Eventing component installed. Learn more

Experimental features configuration

When installing Eventing, the config-features ConfigMap is added to your cluster in the knative-eventing namespace. In order to enable a feature, you just need to add it to the config map and set its value to enabled. For example, to enable new-cool-feature:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: config-features
  5.   namespace: knative-eventing
  6.   labels:
  7.     eventing.knative.dev/release: devel
  8.     knative.dev/config-propagation: original
  9.     knative.dev/config-category: eventing
  10. data:
  11.   new-cool-feature: enabled

In order to disable it, you can either remove the flag or set it to disabled:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: config-features
  5.   namespace: knative-eventing
  6.   labels:
  7.     eventing.knative.dev/release: devel
  8.     knative.dev/config-propagation: original
  9.     knative.dev/config-category: eventing
  10. data:
  11.   new-cool-feature: disabled

Features list

KReference.Group field

Flag name: kreference-group

Stage: Alpha, disabled by default

Tracking issue: #5086

When using the KReference type to refer to another Knative resource, you can just specify the API group of the resource, instead of the full APIVersion.

For example, in order to refer to an InMemoryChannel, instead of the following spec:

  1. apiVersion: messaging.knative.dev/v1
  2. kind: InMemoryChannel
  3. name: my-channel

You can use the following:

  1. group: messaging.knative.dev
  2. kind: InMemoryChannel
  3. name: my-channel

With this feature you can allow Knative to resolve the full APIVersion and further upgrades, deprecations and removals of the referred CRD without affecting existing resources.

Note

At the moment this feature is implemented only for Subscription.Spec.Subscriber.Ref and Subscription.Spec.Channel.

DeliverySpec.Timeout field

Flag name: delivery-timeout

Stage: Alpha, disabled by default

Tracking issue: #5148

When using the delivery spec to configure event delivery parameters, you can use timeout field to specify the timeout for each sent HTTP request. The duration of the timeout parameter is specified using the ISO 8601 format.

The following example shows a Subscription that retries sending an event 3 times, and on each retry the request timeout is going to be 5 seconds:

  1. apiVersion: messaging.knative.dev/v1
  2. kind: Subscription
  3. metadata:
  4.   name: example-subscription
  5.   namespace: example-namespace
  6. spec:
  7.   subscriber:
  8.     ref:
  9.       apiVersion: serving.knative.dev/v1
  10.       kind: Service
  11.       name: example-sink
  12.   delivery:
  13.     backoffDelay: PT2S
  14.     backoffPolicy: linear
  15.     retry: 3
  16.     timeout: PT5S

You can specify a delivery spec for Channels, Subscriptions, Brokers, Triggers, and any other resource spec that accepts the delivery field.