external-dns
external-dns copied to clipboard
kubernetes-sigs
DNSEndpoint definition ignored when annotation-filter is set.
What happened: I have the following command line args: --crd-source-apiversion=externaldns.k8s.io/v1alpha1 --crd-source-kind=DNSEndpoint --cloudflare-proxied --annotation-filter=external-dns.alpha.kubernetes.io/target
The issue is with the annotation-filter. When that is set, my DNSEndpoint definition is ignored unless it has an annotation that matches that filter.
What you expected to happen: I expected my DNSEndpoint definition to be processed and created.
How to reproduce it (as minimally and precisely as possible): When using the command line arguments listed above, create a DNSEndpoint without the annotation, it will be ignored. If the annotation is added then it will be processed.
Anything else we need to know?: I'm not 100% sure this is a bug, as this behavior might be intentional, but it does seem counter intuitive.
Environment:
- External-DNS version (use
external-dns --version): v20230327-v0.13.4 - DNS provider: Cloudflare
I'm also experiencing this bug. It's especially counterintuitive because the annotation usually only goes on Ingress resources , but in this case you have to put the annotation there with any 'ol value to make the DNSEndpoint visible to external-dns.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
I would expect it to honour the annotation? Why do you think it is counter intuitive?
The weird thing is, I was experiencing the exact opposite, I have the CLI options set, I have ingresses and services where it is making DNS successfully with the filter, but I added some DNSEndpoints with the annotation and it is being ignored!
And then I found this; https://kubernetes-sigs.github.io/external-dns/v0.13.2/contributing/crd-source/#usage
--crd-source-apiversion=externaldns.k8s.io/v1alpha1
--crd-source-kind=DNSEndpoint
--cloudflare-proxied
--annotation-filter=external-dns.alpha.kubernetes.io/target
--source=crd
you are missing the --source
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale