-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Metrics service is not garbage collected #459
Comments
I can work on this if any of the proposed way makes sense. |
Maybe an owner reference for the metrics service could help? The owner reference should point to the operator deployment. |
I agree with the ownerref, but not sure about marking the deployment as the owner because it's not necessarily a deployment that creates the operator. What about looking up the operator pod's ownerref and setting it to whatever has been set there? |
I do think this is a change that we will want. I'll defer to @hasbro17 to make sure. I think that for now, using the downward API, and setting the owner reference as the pod makes sense for now. |
We turned off the metrics service creation in v0.1.0 as we're currently reworking how to expose both the controller specific metrics(queue length, number of reconciles) and app specific metrics via separate registries and ports #715 But yes we should have the service be owned by the operator so it's garbage collected. Note that the metrics service selects all operator pods. I imagine we could have the following workflow:
@lilic Thoughts. We can probably address this alongside #715 |
Will do this as soon as the initial metrics PR is merged! #786 |
I think it would make sense to set an ownerreference to the metrics service to be garbage collected when the operator is gone. One idea I have in mind is to use the downwardAPI to pass the pod name and set the ownerreference directly to it, since it will recreate it anyways. The other idea I have is to create the service from the yaml and just update it if needed from the operator. This way users can know that there is a resource that needs to be removed (helm takes care of it for example).
The text was updated successfully, but these errors were encountered: