Summary

We could add a beacon endpoint that could by the UI to track usage of the UI

<TrackEvent event='viewNodeSummary'/>

This just makes a HTTP request to /api/v1/collect?t=trackEvent&event=viewNodeSummary, similar to:

https://developers.google.com/analytics/devguides/collection/protocol/v1/reference

This event could be logged, with the SSO subject/email so Splunk

What version of Knative?

v1.0 at least

Expected Behavior

When creating a Revision with a pod which exits immediately, the Revision should (fairly quickly) report that Ready is False and terminate the Pods.

Actual Behavior

The pods stick around

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]
Add a sample of MMS using a custom model server similar to sklearn and triton that will reside [in

Describe the bug
There are broken links in documentation markdown files.

Expected behavior
No broken link in documentation

To Reproduce
https://gist.github.com/ahuret/4529b7c50eeff488d4e06b2a1bfdf644

Knative release version

Additional context
Add any other context about the problem here such as proposed priority

Once an integration is built and the kit is available, kamel run --dev should start up really fast, in the order of seconds. E2E test should cover this scenario.

Description
https://openfunction.dev/docs/user-guide/use-events/use-event-bus-and-trigger/#create-an-eventbus-and-an-eventsource
Using EventBus to build EventSource according to the official documentation causes openfunction-controller-manager to exit with an exception.

Environmental
+------------------+---------+
| COMPONENT | VERSION |
+------------------+---------+
| Ope

Currently, the source for Azure Service Bus Topics always manages its own Subscription to the selected Topic.

Similarly to the Google Pub/Sub source, we should allow users to manage the Subscription themselves if they prefer to, and simply give us the name of that Subscription so we can consume messages from it without reconciling it:

https://github.com/triggermesh/triggermesh/blob/c13be0932

The javadocs for the Java API are missing. The API methods reflect the same logic as in the Python API, such that much text can be borrowed from there.

Currently, ctriface/ doesn't pick up environment variables from the knative manifests. Firecracker-containerd supports it at a the container creation time as a runtime argument to the corresponding API call.

Example:

	container, err := o.client.NewContainer(
		ctx,
		vmID,
		containerd.WithSnapshotter(o.snapshotter),
		containerd.WithNewSnapshot(vmID, *vm.Image),
		containerd.With