feat: add new flags to allow migration of OwnerID

[troll-os]

Description

This pull requests aims to complete the work initiated in these PR : #2466 and #3631

Most credits go to the creators of the initial work, as I mostly just rebased their work on the current state of master

Initial PR 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

As for me I've successfully managed records without any issue using the newly added flags on the OVH provider
If anyone is willing to try these changes on other providers I'd be happy to troubleshoot their issues

Regarding the documentation I'm not sure either in which category these changes are relevant, so taking any recommendations on that

Note: this is my first contribution to such a project and first time using Go aswell, I've went through the contribution guidelines but if I missed something please let me know so that I can fix it

Fixes #2036

Checklist

• Unit tests updated
• End user documentation updated

[k8s-ci-robot]

Welcome @troll-os!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @troll-os. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[mloiseleur]

Thanks @troll-os. It looks good.
Would you please add some documentation on it ?

[troll-os]

@mloiseleur Sure !

Where do you think it would fit the best? TXT registry ?

[mloiseleur]

With this PR, it works only with TXT registry, so yes.

[mloiseleur]

/ok-to-test

[mloiseleur]

/lgtm

/assign @Raffo

[Raffo]

@troll-os answered to your comments. Could you please also provide a way to test this manually with manifests and kubectl commands? I would be eager to verify myself that the migration works and then keep an end to end test around.

[mloiseleur]

/approve

[ivankatliarchuk]

I may do something incorrectly, but I'm not able to make it working. Could you double check

arguments

go run main.go \
    --provider=aws \
    --registry=txt \
    --source=service \
    --log-level=debug \
    --txt-owner-id=123-old

Kubernetes manifests

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    external-dns.alpha.kubernetes.io/hostname: helloworld.local.tld
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Record is created with external-dns/owner=123-old

So I'm trying to do an owner migration, without specifying an owner id yet

go run main.go \
    --provider=aws \
    --registry=txt \
    --source=service \
    --log-level=debug \
    --txt-owner-id=123-old-to-new \

I'm able to see a message

DEBU[0000] Skipping endpoint helloworld.local.tld 300 IN A  172.19.0.2;172.19.0.3 [] because owner id does not match (found: "123-old", required: "123-old-to-new")
DEBU[0000] Skipping endpoint helloworld.local.tld 0 IN A  172.19.0.2;172.19.0.3 [] because owner id does not match (found: "123-old", required: "123-old-to-new")

So I'm adding desired old owner id

go run main.go \
    --provider=aws \
    --registry=txt \
    --source=service \
    --log-level=debug \
    --txt-owner-id=123-old-to-new \
    --from-txt-owner=123-old

And nothing is happening. Debug message is no longer there, but resource is not migrated

I have tried to add --txt-prefix=%{record_type}-, same result

[troll-os]

Hi @ivankatliarchuk

You also need the --migrate-txt-owner flag to actually enable migration

[ivankatliarchuk]

Gotcha. Yeah it's working.

We may have discussed this before, but the additional --migrate-txt-owner flag seems confusing. My suggestion would be to either remove it, or simplify things by dropping the need for an extra flag and just renaming --from-txt-owner to --migrate-from-txt-owner=xxxx.

Right now, with flags like --dry-run and the rest, the overall UX isn’t very friendly.

At the moment this is how it looks to me

go run main.go \
    --provider=aws \
    --registry=txt \
    --source=service \
    --log-level=debug \
    --txt-owner-id=123-old-to-new-001 \
    --from-txt-owner=123-old-to-new \
    --are-you-shure-to-migate=yes \
    --are-you-absolutely-shure-to-migrate=yes-and-yes \
    ......more confirmations

So I would like to challenge the idea of having two flags to enable/disable this feature

• External-DNS already has a large number of flags. Introducing near-duplicates risks bloat and inconsistency.
• Having two flags that both require to trigger “TXT record migration” creates ambiguity for users.
• It adds technical debt and makes future refactoring more difficult.
• If the goal is to test migration behavior without applying changes, the existing --dry-run flag should be combined with --from-txt-owner, rather than introducing another flag.

[troll-os]

Removed the redundant flag as suggested, all tests run good, ran a live test on Minikube and Gandi again and migration worked there.

Updated docs to reflect the changes

[coveralls]

Pull Request Test Coverage Report for Build 18071083977

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 18 of 18 (100.0%) changed or added relevant lines in 5 files are covered.
• 76 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.09%) to 78.543%

---

Files with Coverage Reduction	New Missed Lines	%
source/service.go	32	92.58%
provider/cloudflare/cloudflare.go	44	90.55%

Totals
Change from base Build 17891767411:	0.09%
Covered Lines:	15780
Relevant Lines:	20091

---

💛 - Coveralls

[mloiseleur]

@ivankatliarchuk Anything left on your side ?

[ivankatliarchuk]

/lgtm

[mloiseleur]

/approve
Many thanks for this @troll-os
It will clearly help a lot of users 👍

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mloiseleur

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mloiseleur]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment