-
Notifications
You must be signed in to change notification settings - Fork 588
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
Send observability related configmaps to destination namespaces #1758
Comments
A general solution to this problem could be a controller that watches specific configmaps and replicates them to other namespaces. Then we don't need to setup unsual cross-namespace RBAC, and pods can get new config without restarting. |
I like the idea of having a generic controller for replicating configmaps. In the future, it will then be easy to extend this controller for instance to support namespace-scoped configuration by merging the |
/project Observability To do |
/assign @capri-xiyue |
I've written a design doc describing a general ConfigMap propagation solution that solves this problem for Knative Eventing and other projects with this need. It suggests creating a namespaced CRD kind: ConfigMapPropagation
metadata:
name: knative-eventing
namespace: default
spec:
originalNamespace: knative-eventing
selector:
knative.dev/config-category: eventing More details in https://docs.google.com/document/d/19kubGE8RQWlPFxz38G7hAtcqfihHosXCr6zXnWWOfOI/edit. There are certainly other solutions, but this one seems cleanest to me (so far). Please comment either here or in the doc. |
Second thought: for now let the in-memory dispatcher using the system configmaps (doing the same as brokers). I'll get back to this issue later on. /unassign |
/assign @grac3gao |
From a multi-tenancy perspective, Instead of "when a namespace is created", it could be "when the first eventing resource is created". No need label the namespace.
|
Thanks @lionelvillard for thinking about this from a multi-tenant perspective! Let me know if I'm interpreting incorrectly, but it seems you're expecting that tenants would prefer to have the link between the original and the copy severed once the copy is made, because they'll have their own modifications. This is possible with ConfigMapPropagation if the tenant removes the |
I wonder if there is an easier way to do this by providing an
This could eliminate the need to explain to users what Regarding |
The auto mode seems similar to I don't agree it's easier than straight copying - it seems more difficult to implement correctly because there's field value comparisons involved, plus more complex messaging of persistent conflicts to both operator (modifier of the original) and user (modifier of the copy). It might be closer to the behavior users want though. Good question about what to do with the OwnerReference. Some points to consider:
The purpose of the OwnerReference is automatic deletion of copies when the CMP is deleted. If we don't want that behavior, then we probably shouldn't set OwnerReferences in the first place. Maybe this could be a flag on the CMP? |
I meant easier for users. After all they matter more than us :-) I would expect the OwnerReference to be removed when the label is not set to |
Currently, CMP will show error if user deletes/changes copy label in Copy ConfigMap
I will change to that. I am working on adding an array of copy configmap statuses under CMP (#2333 (comment)) so that user can know each copied configmap status under CMP status. If the copy configmap label is not set to |
Maybe a better alternative to configmap for overriding config values is to use annotations. |
ConfigMapPropagation does not belong in Eventing. |
/open This is still real broken. |
Problem
A short explanation of the problem, including relevant restrictions.
Right now, the
config-observability
andconfig-tracing
configmaps are watched by different broker filters/ingress deployments across namespaces. E.g. a broker is created in namespaceA
then the corresponding broker filters/ingresses watch the observability configmaps inknative-eventing
namespace while living in namespaceA
.Pros:
Cons:
The community and @n3wscott favored the other way where a copy of the configmaps are base64 encoded and pushed down to the final deployments. Here is a sample implementation.
Pros:
Cons:
Exit Criteria
A measurable (binary) test that would indicate that the problem has been resolved.
Following components should be using the 2nd approach
...
Time Estimate (optional):
How many developer-days do you think this may take to resolve?
Additional context (optional)
Add any other context about the feature request here.
The text was updated successfully, but these errors were encountered: