Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Delete generated PrometheusRule and rule files #39

Open
metalmatze opened this issue Oct 22, 2021 · 2 comments
Open

Delete generated PrometheusRule and rule files #39

metalmatze opened this issue Oct 22, 2021 · 2 comments
Labels
component/filesystem component/kubernetes

Comments

@metalmatze
Copy link
Member

Both for filesystem and Kubernetes we need to reconcile the generated files so that not only new ones are created or existing ones are updated, but no longer existing ones are deleted.

The tricky part is figuring out the difference of what's gone, but it should be doable nonetheless.
@metalmatze metalmatze mentioned this issue Oct 22, 2021
Open
@metalmatze metalmatze changed the title Deleted generated PrometheusRule and rule files Delete generated PrometheusRule and rule files Oct 22, 2021
@rlex
Copy link

rlex commented Oct 31, 2021

It seems there is semi-standard label

app.kubernetes.io/managed-by=

Something like

app.kubernetes.io/managed-by=pyrra
pyrra.dev/rule=nginx-api-errors

should work for managing k8s objects? This, however, doesn't cover case when pyrra is deployed multiple times into different namespaces (is that even supported?)

chlunde added a commit to chlunde/pyrra that referenced this issue Nov 11, 2021
@chlunde
Delete generate PrometheusRule by setting OwnerReferences
f328cef 
By setting owner references on the object we create, kubernetes will
handle deletion of the generated PrometheusRule when the corresponding
ServiceLevelObjective is deleted.

Example:

        k apply -f examples/pyrra-http-errors.yaml
        servicelevelobjective.pyrra.dev/pyrra-api-errors created

we see that the controller generates a prometheusrule object:

        k get prometheusrule,servicelevelobjective -n monitoring
        NAME                                                    AGE
        prometheusrule.monitoring.coreos.com/pyrra-api-errors   1s
        servicelevelobjective.pyrra.dev/pyrra-api-errors        1s

when we delete the SLO, the matching rule is deleted:

        k delete servicelevelobjective.pyrra.dev/pyrra-api-errors -n monitoring

        k get prometheusrule,servicelevelobjective -n monitoring
        No resources found in monitoring namespace.

Updates pyrra-dev#39
@chlunde chlunde mentioned this issue Nov 11, 2021
Merged
chlunde added a commit to chlunde/pyrra that referenced this issue Nov 23, 2021
@chlunde
Delete generate PrometheusRule by setting OwnerReferences
15e00d4 
By setting owner references on the object we create, kubernetes will
handle deletion of the generated PrometheusRule when the corresponding
ServiceLevelObjective is deleted.

Example:

        k apply -f examples/pyrra-http-errors.yaml
        servicelevelobjective.pyrra.dev/pyrra-api-errors created

we see that the controller generates a prometheusrule object:

        k get prometheusrule,servicelevelobjective -n monitoring
        NAME                                                    AGE
        prometheusrule.monitoring.coreos.com/pyrra-api-errors   1s
        servicelevelobjective.pyrra.dev/pyrra-api-errors        1s

when we delete the SLO, the matching rule is deleted:

        k delete servicelevelobjective.pyrra.dev/pyrra-api-errors -n monitoring

        k get prometheusrule,servicelevelobjective -n monitoring
        No resources found in monitoring namespace.

Updates pyrra-dev#39
@jmleddy
Copy link

jmleddy commented Jan 7, 2025

This should be closed. Setting OwnerReferences is indeed the right fix here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component/filesystem component/kubernetes
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rlex @metalmatze @jmleddy