DigitalOcean: support multiple targets per endpoint

[tdyas]

This PR teaches the DigialOcean provider how to support multiple targets per endpoint. (The DigitalOcean provider currently only supports one endpoint per target which other providers do support.)

The Problem

I am running nginx-ingress in DaemonSet mode with host networking enabled on my Kubernetes cluster. I want the IPs for every node running nginx-ingress to appear as A records in DNS. First, because the DigitalOcean provider only supports one endpoint per ingress currently, only one of the A records is created which means the additional nginx-ingress pods will not receive traffic.

Moreover, because external-dns believes that there should be multiple A records for the endpoint in question, the reconciliation loop never converges and external-dns continually sends update API calls every minute. This is not how external-dns seems intended to operate. (Indeed, with this PR, the reconciliation loop does converge and avoids sending an update every minute.)

Solution

If the DigitalOcean API were like the AWS or GCP APIs, then the API representation of a DNS record would have an attribute that is a list of RR datas, and supporting multiple targets per endpoint would be as simple as setting that attribute to the list of targets. The DigitalOcean API is not like that though because it represents multiple A records as multiple "domain record" instances.

This representation is actually quite similar to the Linode API. The Linode provider models updates by expanding an endpoint with multiple targets into multiple domain records to be sent to the Linode API. I have taken that approach with this PR: The DigitalOcean provider now expands an endpoint with multiple targets into multiple godo.DomainRecord instances.

Overview of the changes:

1. The provider's Records method uses the new mergeEndpointsByNameType function to combine multiple godo.DomainRecords for the same DNS name into a single endpoint.Endpoint with multiple targets. This maps the DigitalOcean representation to the external-dns data model

2. The provider's ApplyChanges method has been rewritten to compute a set of digitalOceanChangeCreate, digitalOceanChangeUpdate, and digitalOceanChangeDelete instances representing how to modify the godo.DomainRecord instances associated with a godo.Domain. Computation of each type of change has been put into the processCreateActions, processUpdateActions, and processDeleteActions functions.

3. Tests: Lots more testing of individual functions. I added go-cmp to the project so I could use its Equal and Diff functions. These handle structs with nested pointers to other structs much better than the testify package. I did that so I could actually compare the *godo.DomainRecordEditRequest struct contained in the change structs. (Added a TODO to try and see if testify would be willing to allow custom matching functions.)

4. Upgraded godo to the latest just to keep it current. go bumped the version of two other packages in the go.mod as well, not sure why it did that.

This is currently in production for my cluster. Seems to be working nicely. I did some basic tests against production by deleting and adding some records and external-dns figures out what changed and fixes it. And the reconciliation loop actually converges.

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

Details

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. I understand the commands that are listed here.

[k8s-ci-robot]

Welcome @tdyas!

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. 😃

[tdyas]

/assign @hjacobs
(the k8s-ci-robot said to assign)

[tdyas]

/assign @Raffo

[tdyas]

cc @andrewsomething: Just a heads up in case anyone at DigitalOcean has an interest in external-dns or Kubernetes stuff.

[Raffo]

Thank you for this PR @tdyas especially for the great explanation of what this is doing, I really enjoyed reading it.
I added a few minor comments, but overall the code looks okay.

[Raffo]

Should we have this done before merging this PR or do you want to keep it like this? What are the consequences?

[tdyas]

Not implementing this TODO would leave the status quo in place which is that we would just retrieve all of the records that Records retrieves, just as the existing version of the provider does. (--domain-filter would still be applied to limit the provider to only those zones where external-dns is managing records.)

My concern here was for avoiding having to retrieve all of the records if the zone had potentially many records. #1429 was on my mind as it flagged too many API calls as a potential hazard in such cases.

This TODO is a nice to have but should not block landing this PR.

[Raffo]

@andrewsomething should you be willing to maintain the DO provider, feel free to ping me here or on slack, we are trying to scale how we maintain providers and we would definitely be happy to have someone from DO maintain the DO provider 😄

[Raffo]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Raffo, tdyas

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Raffo]

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