-
Notifications
You must be signed in to change notification settings - Fork 2
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
EIP operator should look for annotations, not labels #224
Comments
yep! that sounds right, some prior art here include |
Can you filter by annotations? We use labels so that we only watch pods with those labels, not all pods. AFAIK, there isn't a way to filter by annotations in a controller's watch.
The eip-operator never writes these labels. It only reads them to know that it needs to care about that pod. The owner of the pod is already the only one writing these labels. From the docs at https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ :
We're using |
@pH14 suggests that the EIP operator should use annotations rather than labels to identify the pods that need EIPs:
I think the idea (@pH14 please correct me) is that this better fits with the Kubernetes models. External systems that act on a resource should store their metadata in annotations; only the object's one true owner should set its labels. Context: https://materializeinc.slack.com/archives/CL68GT3AT/p1658153578418489?thread_ts=1658150176.284539&cid=CL68GT3AT
If we make this change, we should take the opportunity to rename
autocreate_eip
toautocreate-eip
to match Kubernetes convention.The text was updated successfully, but these errors were encountered: