-
Notifications
You must be signed in to change notification settings - Fork 601
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
Reconcile event policies for mt-broker #8090
Reconcile event policies for mt-broker #8090
Conversation
Signed-off-by: rahulii <[email protected]>
Skipping CI for Draft Pull Request. |
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.
nice start @rahulii - I left a few comments on what you have so far (I know it's a draft, but hopefully they help!)
… per review comments Signed-off-by: rahulii <[email protected]>
Signed-off-by: rahulii <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8090 +/- ##
==========================================
+ Coverage 67.80% 67.84% +0.04%
==========================================
Files 367 368 +1
Lines 17373 17505 +132
==========================================
+ Hits 11779 11877 +98
- Misses 4859 4885 +26
- Partials 735 743 +8 ☔ View full report in Codecov by Sentry. |
Signed-off-by: rahulii <[email protected]>
Signed-off-by: rahulii <[email protected]>
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.
Hey @rahulii thanks for this great PR! I've left a few comments (one asking for clarification, the rest with tips on how to improve the code), but once we work through those I think we will be good to merge this - great work!!
}, | ||
From: []eventingv1alpha1.EventPolicySpecFrom{ | ||
{ | ||
Sub: toStrPtr(OIDCBrokerSub), |
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.
Instead of using our own implementation here, we normally use the k8s ptr
package, so this would become ptr.To(OIDCBrokerSub)
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.
done, PTAL!
return &eventingv1alpha1.EventPolicy{ | ||
ObjectMeta: metav1.ObjectMeta{ | ||
Namespace: backingChannel.Namespace, | ||
Name: b.Name + "-event-policy", |
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.
There is a bit more complexity here than just adding the suffix to the name of the broker, since we might run into scenarios where the resulting name exceeds the allowed name length in k8s. Instead, we use kmeta.ChildName(parent, suffix)
to generate the names normally. See here: https://pkg.go.dev/knative.dev/pkg/kmeta#ChildName
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.
done, PTAL!
BackingChannelEventPolicyLabelPrefix + "broker-group": brokerGroup, | ||
BackingChannelEventPolicyLabelPrefix + "broker-version": version, | ||
BackingChannelEventPolicyLabelPrefix + "broker-kind": brokerKind, | ||
BackingChannelEventPolicyLabelPrefix + "broker-name": broker.Name, |
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 curious if we actually need all of these labels for the EventPolicies, what exactly are you using them all for?
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.
@Cali0707 I took reference from channel - https://github.com/knative/eventing/blob/main/pkg/reconciler/channel/resources/eventpolicy.go#L69
Hence, thought of adding the same here. LMK if you think it shouldn't be there, I will remove it !
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 looking there it seems like those labels are used to correctly select the EventPolicies which were created by the channel. We should also use the labels to make a label selector when checking which EventPolicies are owned by the broker. See here for how it is used in the channel:
eventing/pkg/reconciler/channel/channel.go
Lines 142 to 166 in bb2e0a3
applyingEventPoliciesForBackingChannel, err := auth.GetEventPoliciesForResource(r.eventPolicyLister, backingChannel.GroupVersionKind(), backingChannel.ObjectMeta) | |
if err != nil { | |
return fmt.Errorf("could not get applying EventPolicies for for backing channel %s/%s: %w", channel.Namespace, channel.Name, err) | |
} | |
selector, err := labels.ValidatedSelectorFromSet(resources.LabelsForBackingChannelsEventPolicy(backingChannel)) | |
if err != nil { | |
return fmt.Errorf("could not get valid selector for backing channels EventPolicy %s/%s: %w", backingChannel.Namespace, backingChannel.Name, err) | |
} | |
existingEventPoliciesForBackingChannel, err := r.eventPolicyLister.EventPolicies(backingChannel.Namespace).List(selector) | |
if err != nil { | |
return fmt.Errorf("could not get existing EventPolicies in backing channels namespace %q: %w", backingChannel.Namespace, err) | |
} | |
for _, policy := range existingEventPoliciesForBackingChannel { | |
if !r.containsPolicy(policy.Name, applyingEventPoliciesForBackingChannel) { | |
// the existing policy is not in the list of applying policies anymore --> is outdated --> delete it | |
err := r.eventingClientSet.EventingV1alpha1().EventPolicies(policy.Namespace).Delete(ctx, policy.Name, metav1.DeleteOptions{}) | |
if err != nil && apierrs.IsNotFound(err) { | |
return fmt.Errorf("could not delete old EventPolicy %s/%s: %w", policy.Namespace, policy.Name, err) | |
} | |
} | |
} |
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.
gotcha. So just to clarify: currently we are filtering EventPolicies based on the Owner References of broker, instead filter out based on the labels, right ?
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.
No, filtering the eventpolicies by ownerreference is good, but when we list the eventpolicies, we should use a label selector with these labels (see line 152 in the code I linked above). So, to summarize what we would do is:
- List the EventPolicy resources using a label selector to only retrieve relevant ones
- Filter the EventPolicy resources by owner reference
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.
done, PTAL!
pkg/reconciler/broker/broker.go
Outdated
foundEP, err := r.eventPolicyLister.EventPolicies(expected.Namespace).Get(expected.Name) | ||
if apierrs.IsNotFound(err) { | ||
// create the EventPolicy if it doesn't exists. | ||
logging.FromContext(ctx).Info("Creating EventPolicy for Broker %s", expected.Name) |
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 adding a comment here, but it applies to all of the logging in this function:
I don't think these need to be logged at the Info
level, it generally seems to be Debug
logs. Additionally, if we are going to be using the logger everywhere, it seems to make sense to create the logger once at the start of the function and then re-use it throughout, instead of fetching it from the context every time we want to log something
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.
sure, will change from Info -> Debug.
On the other point, I was trying to be consistent with the rest of the code base!
So, should I keep it as it is for change to create a single logger object?
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 would create a single logger object for this function if you are going to have this many log statements. In other places, since there isn't a ton of logging it might be fine to just fetch the logger everytime. But, normally we fetch the logger once when we have this much logging to do in a function
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.
done, PTAL!
pkg/reconciler/broker/broker.go
Outdated
_, err = r.eventingClientSet.EventingV1alpha1().EventPolicies(expected.Namespace).Create(ctx, expected, metav1.CreateOptions{}) | ||
if err != nil { | ||
return fmt.Errorf("failed to create EventPolicy for Broker %s: %w", expected.Name, err) | ||
} | ||
} else if err != nil { | ||
return fmt.Errorf("failed to get EventPolicy for Broker %s: %w", expected.Name, err) | ||
} else if r.policyNeedsUpdate(foundEP, expected) { | ||
// update the EventPolicy if it exists and needs update. | ||
logging.FromContext(ctx).Info("Updating EventPolicy for Broker %s", expected.Name) | ||
expected.SetResourceVersion(foundEP.GetResourceVersion()) | ||
_, err = r.eventingClientSet.EventingV1alpha1().EventPolicies(expected.Namespace).Update(ctx, expected, metav1.UpdateOptions{}) | ||
if err != nil { | ||
return fmt.Errorf("failed to update EventPolicy for Broker %s: %w", expected.Name, err) | ||
} | ||
} | ||
} else { |
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.
all of these if/else blocks can make it a little unclear what is going on, I might refactor this to return early in many of these cases. For example, if the EventPolicy is successfully created, we can return nil
. This gets rid of the need for the else if r.policyNeedsUpdate(...)
, which can be turned into a simpler if r.policyNeedsUpdate(...)
.
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 point, thanks for the feedback, I will make the changes!
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.
done, PTAL!
pkg/reconciler/broker/broker.go
Outdated
return nil | ||
} | ||
|
||
func (r *Reconciler) policyNeedsUpdate(foundEP, expected *eventingv1alpha1.EventPolicy) bool { |
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: this function doesn't really need to be a method on the Reconciler struct
func (r *Reconciler) policyNeedsUpdate(foundEP, expected *eventingv1alpha1.EventPolicy) bool { | |
func policyNeedsUpdate(foundEP, expected *eventingv1alpha1.EventPolicy) bool { |
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.
done, PTAL!
Signed-off-by: rahulii <[email protected]>
Signed-off-by: rahulii <[email protected]>
Signed-off-by: rahulii <[email protected]>
Signed-off-by: rahulii <[email protected]>
…ext and some minor fixes Signed-off-by: rahulii <[email protected]>
/ok-to-test |
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.
/lgtm
/approve
Thanks @rahulii !
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Cali0707, rahulii 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 |
Fixes #7982
Proposed Changes
Pre-review Checklist
Release Note
Docs