-
Notifications
You must be signed in to change notification settings - Fork 40
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 EventRecorder to Helper #320
Conversation
I don't have much context about events in k8s. I think it worth to create a doc where you propose what will be the use of the events in openstack-k8s-operators. I.e. what step during a reconciliation worth emitting an event. What information an event should always contain, etc. A bit similar to the definition of the condition usage https://github.com/openstack-k8s-operators/docs/blob/main/conditions.md |
I agree with @gibizer , I think we should not just create events, first we'd have to agree/define when there should be one and the content. |
I think this can help us to detect race conditions, we can sort events and see the chronological order things were added/updated in the cluster |
0b59b50
to
b23188e
Compare
5c1988f
to
5271d47
Compare
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
c7345be
to
ab9c8a7
Compare
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
https://www.cncf.io/blog/2023/03/13/how-to-use-kubernetes-events-for-effective-alerting-and-monitoring/ https://www.cncf.io/blog/2021/12/21/extracting-value-from-the-kubernetes-events-feed/ https://www.atlassian.com/engineering/how-to-export-kubernetes-events-for-observability-and-alerting Signed-off-by: Fabricio Aguiar <[email protected]>
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
Depends-On: openstack-k8s-operators/lib-common#320 Signed-off-by: Fabricio Aguiar <[email protected]>
@@ -105,8 +105,12 @@ func createOrPatchConfigMap( | |||
return nil | |||
}) | |||
if err != nil { | |||
h.GetRecorder().Event(obj, corev1.EventTypeWarning, "ConfigMapError", fmt.Sprintf("error create/updating configmap: %s", cm.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.
re ConfigMapError
and other events, its probably good that we create a central reason collection which then gets used in all the operators. similar to how we do it with the conditions. Otherwise I guess if events are used in the service operators, we'll see different reasons used. I could see two ways. Either we create an events pkg and have the consts for reasons in there, or they are part of the already existing pkgs, like ConfigMap reason in configmap. but then how to handle reasons for stuff we do not yet have. create extra pkgs, or better the one events pkg. thoughts?
return ctrl.Result{}, err | ||
} | ||
if op == controllerutil.OperationResultCreated { | ||
h.GetRecorder().Event(h.GetBeforeObject(), corev1.EventTypeNormal, "DaemonSetCreated", fmt.Sprintf("daemonset %s created", d.daemonset.Name)) | ||
} | ||
if op != controllerutil.OperationResultNone { | ||
util.LogForObject(h, fmt.Sprintf("DaemonSet: %s", op), daemonset) |
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.
should there be an updated event when the object got updated?
I'm worried that this PR is moving forward without agreeing on the scope of it. |
agreed, @fao89 do you plan to work on some definition doc as we have for conditions? |
yes, I started it here: openstack-k8s-operators/dev-docs#105 |
Actually, after sorting the events on must-gather(openstack-k8s-operators/openstack-must-gather#47), I can see the events I was interested in are already there (pod/job creation and job completion):
|
by the community guide:
I think we can close this PR |
https://www.cncf.io/blog/2023/03/13/how-to-use-kubernetes-events-for-effective-alerting-and-monitoring/
https://www.cncf.io/blog/2021/12/21/extracting-value-from-the-kubernetes-events-feed/
https://www.atlassian.com/engineering/how-to-export-kubernetes-events-for-observability-and-alerting
Events: https://gist.githubusercontent.com/fao89/f25d02317adfebee8943055be23a4553/raw/cf40e9197b6507a67722f334722ac5fa6c382270/events.log