DNSEndpoint definition ignored when annotation-filter is set.

[doonga]

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

[Ramblurr]

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.

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[kahirokunn]

keep

[onedr0p]

/remove-lifecycle stale

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[joryirving]

/remove-lifecycle stale

[jurgenweber]

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

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[kahirokunn]

keep

[kahirokunn]

/remove-lifecycle stale

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[onedr0p]

/remove-lifecycle stale

[ivankatliarchuk]

/lifecycle frozen
/help

[k8s-ci-robot]

@ivankatliarchuk:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/lifecycle frozen
/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

/assign

[ivankatliarchuk]

link #5079