Enable eventing when a Trigger is created for first time

[akashrv]

Problem
Today, users have to enable eventing on the namespace using the label:knative-eventing-injection: enabled, and then create triggers that target default broker. Labelling the namespace creates the default broker and necessary roles and sets things up for the default user experience.
To improve UX, can trigger reconciler label the namespace if needed (if no default broker present, and namespace is not labelled) ?

This way, for default user experience, users can directly create a Trigger.

Persona:
Which persona is this feature for?
Developer

Exit Criteria
A measurable (binary) test that would indicate that the problem has been resolved.

• Create a trigger in a new namespace that is not labelled, knative-eventing-injection: enabled or doesn't have default broker. Trigger should get created and point to the default broker and start working.

Time Estimate (optional):
How many developer-days do you think this may take to resolve?
5

Additional context (optional)
Add any other context about the feature request here.

[Harwayne]

My preference would be to do #1837. Then we could solve this by having the Trigger optionally create the Broker, if the Trigger's spec.broker is default.

[grantr]

I think this is the same as what you're saying @Harwayne, but just to be clear: Broker autocreation should probably only happen for the default Broker, not for any other Broker.

[grac3gao-zz]

/assign @grac3gao

[n3wscott]

I think this is a red flag feature. The broker is not free, it is really quite expensive to start depending on the channel type.

Just making a trigger is not enough for us to understand what the user is intending. If you want a feature like this, I would recommend adding an annotation to the trigger allowing for auto-creation of the broker specified in that trigger.

[grantr]

The broker is not free, it is really quite expensive to start depending on the channel type.

This is true, but the feature only ever creates a single Broker per namespace.

Just making a trigger is not enough for us to understand what the user is intending.

If a user creates a Trigger, that seems like a strong signal that they want a Broker to exist. I think your argument is that we don't know what the user's intended Broker spec looks like, and if the user differs from what we expect, this feature introduces a race condition.

Consider the scenario of applying a yaml file creating a default Broker backed by a KafkaChannel and a Trigger owned by that Broker, in a cluster where KafkaChannel is not the default channel. Depending on the order of creation, the Broker may be created with the default channel or KafkaChannel. Since channelTemplate is immutable, this divergence cannot be reconciled without manual intervention, and can only be avoided by a two-stage create.

Due to this race condition, I think I agree with @n3wscott that this should be be explicitly enabled by annotation.

[akashrv]

Thats a good catch @grantr and @n3wscott esp the race condition, and I totally agree with doing this for "default" broker only. For everything else we expect the user to know what they are doing.
Do you see issues with annotations too or does that seem to be okay? Trying to make sure that there aren't more corner cases.

[grantr]

The race condition is still there with the annotation, but we expect that users adding the annotation are more likely to "know what they are doing". To guard against users who cargo cult without reading the manual, we might want to choose an annotation name and value that makes clear this feature will clash with manually created default Brokers.