Determining ConfigMapPropagation lifecycle

[lionelvillard]

Problem
ConfigMapProgragation objects are automatically created by the namespace controller, along with the default broker. However, it is possible to manually create brokers, event sources, channels, and all these components potentially need access to the namespace configmaps.

Should the namespace label be automatically added by each eventing controller (eg. InMemory, ScheduledSource, etc..)? The downside is the default broker will be automatically created.

One possible solution:

• each controller check if label on namespace is present.
  • If yes, do nothing
  • otherwise add label with special value enabled-no-broker, or add 2 labels, the one we have today and another one controlling which default objects to create.

Another solution is to prevent any eventing objects to be created when the namespace label is not set. It could be done in the validation webhook I believe. Not great user-experience though.

For now I'm more in favor of having 2 labels.

@grantr @grac3gao any thoughts?

[lionelvillard]

/milestone v0.13.0-M1

[knative-prow-robot]

@lionelvillard: You must be a member of the knative/knative-milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility.

Details

In response to this:

/milestone v0.13.0-M1

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[lionelvillard]

/label proposal/0.13

[grac3gao-zz]

• otherwise add label with special value enabled-no-broker, or add 2 labels, the one we have today and another one controlling which default objects to create.

Could you explain more about this scenario? Especially for the 2 labels, ‘the one we have today’ means the namespace’s knative-eventing-injection=enabled label?

Trigger reconciler has a check for namespace label (it will label the namespace to enable a default broker if trigger is created #2034, this is only for default broker) I think the solution of this issue may also benefit #1837 for simple broker creation.

For other resource (like source, channel), I am curious about the usage of ConfigMaps. If we use the cmp in those scenarios, I am thinking about:
1. When creating cmp in namepace reconciler for resources other than broker, should we create the default cmp eventing or use other cmp (one resource one cmp? one namespace one cmp?)
2. cmp has a label selector, how to leverage it with different resources.

[lionelvillard]

‘the one we have today’ means the namespace’s knative-eventing-injection=enabled label?

yes

Trigger reconciler has a check for namespace label (it will label the namespace to enable a default broker if trigger is created #2034, this is only for default broker) I think the solution of this issue may also benefit #1837 for simple broker creation.

Great! This could be generalized to other resources. However when creating a source, I wouldn't expect to see a Broker being automatically created. Thus the idea of having two labels.

I don't have answers yet to your other questions.