Create/Delete loop

[klamkma]

What happened:
We are using Infoblox.
If we create 2 services with the same DNS record name, this dns entry is being created and removed in a loop.

What you expected to happen:
The same annotation for multiple services should not be deleting/creating the dns entry in a loop.

How to reproduce it (as minimally and precisely as possible):

kind: Service
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: some.cname.org
  name: test1
  namespace: default
spec:
  externalName: some.a.record.org
  sessionAffinity: None
  type: ExternalName
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: some.cname.org
  name: test2
  namespace: default
spec:
  externalName: some.a.record.org
  sessionAffinity: None
  type: ExternalName

Anything else we need to know?:

Environment:

• External-DNS version (use external-dns --version): v0.9.0
• DNS provider: Infoblox
• Others:

[alebedev87]

@klamkma : Can you test it with v0.12.0 of external-dns? There was a fix for the duplicate endpoints: #2755.

[klamkma]

@alebedev87, I tested the new v0.12.0 and the effect is worst than before.

We have multiple kubernetes clusters.
On each cluster we have external-dns where one cluster has --txt-owner-id=a and another one --txt-owner-id=b.

In the moment I applied the new service on cluster A with repeated DNS Record, we had a missive deletion/recreation of all DNS records, including records created by cluster B.

The missive removal/recreations of DNS records stopped as soon I removed the second service with duplicated dns entry.

[skalpin]

The infoblox provider queries for the object before deleting it so it can send the reference id. In our environment that query returned several other records. So deleting 1 record resulted in deleting several others. The fix was to add "name=" to the query so that it only deletes the 1 specific record.

Maybe in your case, it sounds like cluster A is deleting records from cluster B, which shouldn't be happening if you are using a registry.

PR #2890

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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/test-infra repository.