external-dns
external-dns copied to clipboard
New features: migrate txt-owner
Description
When changing --txt-owner-id on an existing external-dns resource, it does not update the existing TXT records it owns, therefore losing ownership. Meaning that we have to manually delete the records in order to have external-dns take ownership again. To solve this problem, I added the ability to update the original txt-owner by setting -- migrate-txt-owner to overwrite the old txt-owner. I have successfully modified thousands of pieces of data using this code, so far without any bugs.
Fixes #ISSUE https://github.com/kubernetes-sigs/external-dns/issues/2036
The committers are authorized under a signed CLA.
- :white_check_mark: Inorysky (2c3bb01f1b090b8ae95122475c5316636ca6f5a2)
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Inorysky
To complete the pull request process, please assign raffo after the PR has been reviewed.
You can assign the PR to them by writing /assign @raffo
in a comment when ready.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment
Unknown CLA label state. Rechecking for CLA labels.
Send feedback to sig-contributor-experience at kubernetes/community.
/check-cla
@Inorysky
The idea of having such a switch is great!
As far as I understand the code, it will overwrite any txt-owner it finds in DNS records. I believe that there are many users outside running multiple external-dns deployments in several clusters but each of them operating probably within the same DNS zone. There would be clashes if one of them does a txt-owner migration!
You could extend your current code with a from-txt-owner
(holding the old txt-owner value) to play it safe.
@Inorysky The idea of having such a switch is great! As far as I understand the code, it will overwrite any txt-owner it finds in DNS records. I believe that there are many users outside running multiple external-dns deployments in several clusters but each of them operating probably within the same DNS zone. There would be clashes if one of them does a txt-owner migration! You could extend your current code with a
from-txt-owner
(holding the old txt-owner value) to play it safe.
Thank you for your suggestion, I have now made a change according to your suggestion: the from-txt-owner tag has been added to support modifying the old txt-owner specified. :)
@Inorysky I like it 👍 Thanks. I'm not a maintainer thus you need to wait for others to review this PR.
@Inorysky I like it 👍 Thanks. I'm not a maintainer thus you need to wait for others to review this PR.
Thank you very much!(・ω・)ノ
cc @Raffo, could help review this? we adopt this feature in 30 of our clusters, it helps a lot
@runzexia Same here. I have about 400 domains that need to be updated. Doing it by hand would be a huge pain in the rear. ;)
@Inorysky: PR needs rebase.
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.
+1
We at @swisspost would really apreciate this feature since we are already in such a scenario where migration of the owner is needed.
Also waiting for this MR to be merged!
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
Not stale. 😢
We @swisspost still wait for this feature.
/remove-lifecycle stale
Wish this was merged
@seanmalloy @njuettner @Raffo @szuecs How can we push this further?
This PR needs:
- A rebase
- some unit tests
I suggest pinging someone on #external-dns on kubernetes slack, so they can provide some feedback on it :)
Thanks!
@rikatz we are seeing this here, too. I see all GH notifications, but if the PR is not green I won't review, because use the time elsewhere is more efficient for the project.
Yes agreed. Let's wait some return of the author here
Hi took this PR changes and built docker image and used that, i could see those migrate-txt-owner --from-txt-owner option , but still it is skipping the updation of record saying owner id does not match, found: default and resquired: abc,
can you confirm if this works, or am i missing something,?
i ran the external-dns with below options
external-dns --dry-run --metrics-address=":7979" --log-level=debug --log-format=text --interval=30m --source=service --source=ingress --source=istio-virtualservice --source=istio-gateway --policy=upsert-only --registry=txt --domain-filter=example.com --provider=aws --aws-assume-role=arn:aws:iam::1234567890:role/route53role --txt-owner-id=abc --from-txt-owner=default --migrate-txt-owner
cc: @Inorysky
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages 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 PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale
- Close this PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
FYI: I tried to take over the work from here / @Inorysky and filed a new PR over there:
- https://github.com/kubernetes-sigs/external-dns/pull/3631
Rebased @Inorysky 's work and added some unit tests.
Since #3631 supersede this PR, I'm closing it. /close
@mloiseleur: Closed this PR.
In response to this:
Since #3631 supersede this PR, I'm closing it. /close
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.