Skip to content

Conversation

TobyTheHutt
Copy link
Contributor

What does it do ?

  • Implements safe “type swap” handling in the Google provider: when a record’s type changes at the same name (e.g., A - CNAME), the provider emits a single dns.Change that deletes the old type first and adds the new type second.
  • Normalizes swap matching by DNS name using a lowercase, trailing-dot key to avoid case and dot variance.
  • Excludes TXT records from swap eligibility to preserve ownership.
  • Preserves the external-dns/owner label by copying it from the deleted record to the newly created record.
  • Refactors ApplyChanges to integrate swaps alongside existing create/update/delete flows, keeping behavior deterministic.
  • Adds unit tests for type-swap scenarios, TXT exclusion, case insensitivity, and multi-delete consumption behavior.
  • Minor cleanups: preallocations for remaining lists and strings import for key normalization.

Motivation

Fixes the Google Cloud DNS limitation where ExternalDNS could not change a record’s type at the same name without a manual delete.
It's issuing a delete-then-add, therefore atomically resolving API conflicts.

More

  • Yes, this PR title follows Conventional Commits
  • Yes, I added unit tests
  • Yes, I updated end user documentation accordingly

The change teaches the Google provider to bundle record-type swaps into
a single Cloud DNS change set. It also carries the ownership forward.

* Add new `extractTypeSwaps` helper to pair create/delete endpoints by
  name
* Modify `extractTypeSwaps` to skip TXT records
* Modify `extractTypeSwaps` to copy owner label of the prior RRset onto
  the new record before both ends of the swap are appended to the change
* Modify `ApplyChanges` to receive the new `extractTypeSwaps` helper's
  result for one astomic delete+add per type change
* Add `TestGoogleApplyChangesTypeSwap` to set up A to CNAME transition
* Add tests
  * Assert helper finds a swap
  * Verify that zone holds the CNAME
  * Verify that create endpoint retains original owner label

Signed-off-by: Tobias Harnickell <[email protected]>
* Maintain TXT ownership by skipping TXT in type swaps
* Carry owner label forward when swapping record types
* Add tests for swap logic
* Refactor swap extraction for clarity

Signed-off-by: Tobias Harnickell <[email protected]>
…-preserve-gcp-txt-ownership

Signed-off-by: Tobias Harnickell <[email protected]>
* Fix `TestGoogleExtractTypeSwapsConsumesSingleDelete` flakiness by
  asserting A-record as the chosen swap source
* Remove unused `matchedType` variable
* Initialize `remainingDeletes` with `make([]*endpoint.Endpoint, 0,
  len(deleteEndpoints))` so "no swaps" mirrors the preallocation used
  for `remainingCreates`
* Document invariants and rationale for `extractTypeSwaps` in code
  comment
* Evaluate buckets deterministically by `typeSwapTypePriority`,
  owner-label preference and stable tie-preakters (leftover deletions
  also deterministically emitted)

Signed-off-by: Tobias Harnickell <[email protected]>
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign szuecs for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

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

@k8s-ci-robot k8s-ci-robot added the provider Issues or PRs related to a provider label Sep 21, 2025
@k8s-ci-robot k8s-ci-robot requested a review from szuecs September 21, 2025 10:26
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Sep 21, 2025
@k8s-ci-robot
Copy link
Contributor

Hi @TobyTheHutt. 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.

@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Sep 21, 2025
Split unnecessarily long lines.

Signed-off-by: Tobias Harnickell <[email protected]>
@ivankatliarchuk
Copy link
Contributor

I was working once or twice with GCP, same time AWS and Azure follow same principle record type is immutable.

I'm not too sure how exactly this was resolved, but assuming this is not a case for AWS for example, which means, two records with only different record type, actually two distinct records. So if we have RecordA of type A, changes it's type to type AAAA, we currently have

  • Deleted RecordA (example.com) of type A
  • Created RecordB (example.com) of type AAAA

Few questions;

  1. Is the problem still reproducible?
  2. How exactly this case is managed on AWS or Azure?
  3. Why not to ensure the order of changes - first Create or Delete, then Update? I'm not exactly sure how batching behaves

@ivankatliarchuk
Copy link
Contributor

How this was resolved for AWS #1867

We may need to introduce a principle or best practice for providers add to contributor docs if we could not force a common interface, on what is the correct order of changes to avoid such cases

@ivankatliarchuk
Copy link
Contributor

In cases where a record type changes, resulting in a DELETE + CREATE, retaining the TXT record could be considered an improvement that can be applied across all providers. However, implementing changes to TXT records is not straightforward, as it carries multiple risks and quite often project owners involved with final decision.

@mloiseleur mloiseleur changed the title feat(provider/google): preserve gcp txt ownership (kubernetes-sigs/external-dns#433) feat(provider/google): preserve gcp txt ownership Sep 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. provider Issues or PRs related to a provider size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

external-dns cannot automatically change record type in Google DNS

3 participants