-
Notifications
You must be signed in to change notification settings - Fork 592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a namespace controller for the MT Broker. #2778
Conversation
This adds a namespace controller that creates brokers per namespace without the additional components that are only needed by the single-tenant brokers (ConfigMapProp, RoleBindings, ServiceAccounts). Since the footprint of the MT Broker is effectively nothing, I've made this version of the controller opt-out vs. opt-in.
/retest |
The following is the coverage report on the affected files.
|
/lgtm |
return err | ||
} | ||
|
||
if original.Labels[resources.InjectionLabelKey] == resources.InjectionDisabledLabelValue { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this means that to opt-out, you have to create the namespace with this label in it which means you can't just do:
kubectl create ns foobar
but have to create the object (or is there a way to do this?)
I'm fine with getting this in as is for now, but perhaps we should use the configmap to control this behaviour for the opt-out as a follow on?
Also, could you add an issue for adding the docs for this feature?
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't see an option to label namespaces in kubectl create ns foo
. I think if we were going to go the ConfigMap route we'd want consistency with ST Broker. Env vars seem to be popular for configuring this.
How about making the default behavior configurable via DEFAULT_BROKER_INJECTION
and having the two reconcilers default it differently?
re: docs
I'm happy to follow up with a PR after this lands. I was thinking we'd fold the "enable" tab into the ST Broker instructions, and combine this with the MT Broker instructions. I'll start on that and we can discuss there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This work is happening here: knative/eventing#2778
/lgtm I'll clean up a few things in a followup. |
/unhold |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mattmoor, n3wscott, vaikas The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
/test pull-knative-eventing-integration-tests retrying after the #2786 went in. |
/test pull-knative-eventing-unit-tests |
Sorry, that I am late here, but ...
@mattmoor Is that really really needed ? Not sure 🤔 |
reminds me a bit of the sinkbinding webhook, that goes to all deployments etc, on all namespaces. IMO bad default ... |
I do feel the same |
Let's pick one place to discuss this, perhaps: knative/docs#2325? |
This adds a namespace controller that creates brokers per namespace without the additional components that are only needed by the single-tenant brokers (ConfigMapProp, RoleBindings, ServiceAccounts).
Since the footprint of the MT Broker is effectively nothing, I've made this version of the controller opt-out vs. opt-in.
/assign @vaikas
/hold