-
Notifications
You must be signed in to change notification settings - Fork 593
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
Moved the internal subscriptions delivery configuration to a config map #4832
Conversation
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #4832 +/- ##
==========================================
- Coverage 81.27% 81.23% -0.05%
==========================================
Files 292 293 +1
Lines 8309 8344 +35
==========================================
+ Hits 6753 6778 +25
- Misses 1146 1156 +10
Partials 410 410
Continue to review full report at Codecov.
|
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.
I'm a bit confused about introducing a configmap and all the other stuff, could you clarify a little bit for what reason. And also, I'm confused why this is tagged as a breaking change.
config/brokers/mt-channel-broker/300-config-mtbroker-delivery.yaml
Outdated
Show resolved
Hide resolved
@@ -163,7 +168,7 @@ func (r *Reconciler) subscribeToBrokerChannel(ctx context.Context, b *eventingv1 | |||
Name: b.Name, | |||
Namespace: b.Namespace, | |||
} | |||
expected := resources.NewSubscription(t, brokerTrigger, brokerObjRef, uri, b.Spec.Delivery) | |||
expected := resources.NewSubscription(t, brokerTrigger, brokerObjRef, uri, r.internalDeliveryConfigStore.Load()) |
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.
I'm little confused why we need to add the ConfigMap here. As discussed in the spec PR, I thought the logic here would simply be (something like this):
del := t.Spec.Delivery
if del == nil {
del = b.Spec.Delivery
}
expected := resources.NewSubscription(t, brokerTrigger, brokerObjRef, uri, del)
if (t.Spec.Delivery != nil
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 subscription is an internal subscription between broker components, the actual dispatch to the service is done by the filter handler.
Now, with #4654 we're saying BrokerSpec.Delivery
(same for TriggerSpec.Delivery
) configures the trigger delivery, hence the hop between the filter_handler and the actual service. On the other hand, this subscription is an internal hop between broker components.
I've added a config map for that to allow the user to continue to modify this internal delivery spec, because in another PR i'll actually implement in mtbroker the delivery spec as stated by #4654
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.
Look at the description of this issue: #4515
/assign |
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.
I think it'd be great if we can have a docs issue for this? also if the release note was more explaining, something like "before, we used this field for, but now it's changing to and instead use the config map"
also, is this a breaking change? it's a different behavior, but eventing will still work and nothing will really break. I'll leave it for @vaikas and you to align on that :)
so other from those NITs, that lgtm.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: devguyio, slinkydeveloper 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 |
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
The following is the coverage report on the affected files.
|
# Configure the internal channels subscription delivery spec | ||
delivery: | | ||
retry: 10 |
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.
IIUC, I think we should document or warn users what this means.
If I set this retry here retry: 10
and my trigger has retry: 10
we're actually retrying at most 10 * 10 = 100
times since each time the channel implementation retries due to the delivery in this ConfigMap, the filter deployment (once implemented) will retry 10 times.
Is my understanding correct?
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.
Exactly... Maybe we should use this "internal" configuration just for the ingress channel and then for the other channel we use the BrokerSpec.Delivery
/TriggerSpec.Delivery
?
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.
The problem with that approach is that retries (in trigger.spec.delivery.retry
or broker.spec.delivery.retry
) are ephemeral since the filter deployment might crash while it was retrying and in that case, we're not reaching the specified retries in trigger.spec.delivery.retry
or broker.spec.delivery.retry
before giving up.
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.
I see your point... I guess it makes sense, so maybe we need to just use this internal map for the first channel (the ingress one) and then use BrokerSpec.Delivery/TriggerSpec.Delivery for the filter channel?
/hold wip |
"knative.dev/pkg/configmap" | ||
"sigs.k8s.io/yaml" | ||
|
||
eventingduck "knative.dev/eventing/pkg/apis/duck/v1" |
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.
nit: Don't we use duckv1
everywhere else, like corev1
above?
|
||
eventingduck "knative.dev/eventing/pkg/apis/duck/v1" | ||
|
||
. "knative.dev/pkg/configmap/testing" |
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.
Wherever possible it would be nice to avoid .
imports. Even something short such as cmt
or cmtesting
helps with readability I think.
// Fake injection informers | ||
_ "knative.dev/eventing/pkg/client/injection/informers/eventing/v1/broker/fake" | ||
_ "knative.dev/eventing/pkg/client/injection/informers/eventing/v1/trigger/fake" | ||
_ "knative.dev/eventing/pkg/client/injection/informers/messaging/v1/subscription/fake" | ||
"knative.dev/eventing/pkg/reconciler/mtbroker" |
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 import should be relocated, it is not a "Fake injection informer" so future readers will be confused.
InternalDeliveryConfigMapName = "mt-broker-internal-delivery" | ||
internalDeliveryConfigMapDeliveryKey = "delivery" |
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.
Any reason for making the name public but the key private? Can't they both be private?
cmw := configmap.NewStaticWatcher(&corev1.ConfigMap{ | ||
ObjectMeta: metav1.ObjectMeta{ | ||
Name: mtbroker.InternalDeliveryConfigMapName, | ||
Namespace: system.Namespace(), | ||
}, |
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.
Good candidate for rectesting.NewConfigMap
I think.
} | ||
|
||
// InternalDeliveryConfigStore is a typed wrapper around configmap.Untyped store to handle our configmaps. | ||
// +k8s:deepcopy-gen=false |
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.
Is that annotation needed? As far as I can see we don't run deepcopy-gen on that package.
"channeldefaults", | ||
logger, | ||
configmap.Constructors{ | ||
InternalDeliveryConfigMapName: NewInternalDeliveryConfigFromConfigMap, |
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.
I see that NewInternalDeliveryConfigFromConfigMap
can return nil
but I don't see a check to fallback to a default when this is the case. Maybe I overlooked, just want to be sure you've ensured this can not cause a panic.
/close After reasoning about it and the #4832 (comment) comment, i believe this pr doesn't make sense |
@slinkydeveloper: Closed this PR. In response to this:
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. |
Signed-off-by: Francesco Guardiani francescoguard@gmail.com
Fixes #4821, for more details on why: #4654
Proposed Changes
Release Note