Currently, we are using the “app.juju.is/created-by=” Juju label to find resources created by the NGINX charm. Accordingly to this discussion with the Juju team, there is no guarantee that this label will never be changed/removed.
Note: From the Juju team member Harry “the app name isn’t unique, so we need to add a model-uuid into it, since resources could be created outside the model managed namespace.”
Given this situation, we’ve studied options to deal with this:
Using the same label that juju currently does - app.juju.is/created-by
Adding a prefix to this of the charm name - nginx-ingress-integrator.app.juju.is/created-by or nginx-ingress-integrator.charm.juju.is/created-by
Something else altogether
Since we’d like to come up with a convention that could be used by other charms, and we need to make the changes in order to reliably determine what resources this charm has created so we can clean them up, we wanted to listen to your opinions regarding this matter.
It has more future extensibility, and we may want to add more labels to the resources created by the Nginx integrator. For example, using nginx-ingress-integrator.charm.juju.is/created-for to record the target charm, or using nginx-ingress-integrator.charm.juju.is/related-relation-id to record the relation id associated with this resource.
In addition, the second method can be applied to other charm without having to worry about collisions. For example, a charm called abc can label the resources it creates with abc.charm.juju.is/created-by, and it will not conflict with resources created by the Nginx ingress integrator charm.
Here is my understanding from the Juju side, though I’d ask @hpidcock to fact check me, and @benhoyt to consider it from a charming perspective.
I believe we have a general goal with Juju that if you deploy application A, which then generates resource Y, we would like juju to help track what is responsible for that resource, and ensure that it gets cleaned up when A goes away. So I wouldn’t use app.juju.is/created-by because I feel that Juju should be leveraging that more than we are today.
We talked about it a bit in our IS sync, and the use case for the charm is “I created a resource for this purpose, I need to make sure that if I need to change it, I have a label around its purpose so I know when to replace it vs create a new one”. That doesn’t feel like a ‘created-by’ label, so much as some form of nginx-ingress-integrator.charm.juju.is/purpose sort of tag.
Yeah, I’m with @jameinel in that using app.juju.is/created-by doesn’t seem right as that is Juju’s own label.
I like the idea in the PR of using app.kubernetes.io/managed-by – I don’t think that would conflict with Juju, because Juju always sets the value of the label to “juju” and checks for that value to determine ownership. So if the charm set it to app.kubernetes.io/managed-by=<charm-name> or whatever, it seems to me that would fit the K8s labelling practices (though I’m far from an expert).
nginx-ingress-integrator.charm.juju.is/purpose would work too. I guess it’s a question of semantics: are you using the label to determine management (to be able to clean up resources later, for example) or purpose (to find resources with a specific purpose)?
We considered app.kubernetes.io/managed-by but saw that it was referenced in juju’s labels file so thought we should avoid using it. Do you think that’s not a concern and something we should use in this case?
In our particular case we’re using the label to determine management (to be able to clean up resources as their definitions change due to relation or config changes), so I think if we were going to use something like the nginx-ingress-integrator.charm.juju.is prefix we’d go with nginx-ingress-integrator.charm.juju.is/managed-by.
Maybe @tlm can confirm, but I’ve scanned in the code how Juju uses that label, and it looks like we always assign the value of “value” to that key, and look it up by app.kubernetes.io/managed-by==juju. So if you guys set app.kubernetes.io/managed-by to something else, that should be fine, and seems the intended use case for that key.
If the charm wanted to label their own resources then it’s best to probably stick with a new label domain.
However in saying that we do have the model operator in Juju who’s job is to track resources created by the charms across the cluster. At the moment it’s only watching some basics in the cluster and will miss CRD’s etc.
We can however dust it off and make it track more to help in this case so Juju can do the hard work of cleaning up after it self. This is the purpose we made the ModelOperator for.
Are you able to provide a rough overview of the resources you are creating that need to get cleaned up?
The charm creates an ingress resource definition, and then changes that over time based on relation updates or configuration updates. In some cases this can mean a new ingress resource is defined (if the name changes, for instance), so we want to be able to track which one(s) the charm has created so it can remove older ones.
