feat(chart): add TXT registry option values

[erdo-enes]

What does it do ?

• Adds dedicated Helm chart values for TXT registry wildcard replacement and TXT record encryption:
  • .txtWildcardReplacement
  • .txtEncryptEnabled
  • .txtEncryptAesKey
• Wires those values into charts/external-dns/templates/deployment.yaml so the chart renders:
  • --txt-wildcard-replacement
  • --txt-encrypt-enabled
  • --txt-encrypt-aes-key
• Updates the chart schema, values documentation, changelog, and Deployment flag unit tests.

Motivation

ExternalDNS supports these TXT registry flags, but the Helm chart only exposed txtOwnerId, txtPrefix, and txtSuffix as first-class TXT registry values. This adds the missing chart values next to the existing TXT registry options so users can configure them without falling back to extraArgs.

More

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

[k8s-ci-robot]

[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 stevehipwell for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• charts/OWNERS

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: erdo-enes / name: erdo-enes (7382508)

[k8s-ci-robot]

Hi @erdo-enes. 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.

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-sigs/prow repository.

[erdo-enes]

Thanks @mloiseleur, I applied both suggestions in 76a38b3.

[mloiseleur]

/ok-to-test

[coveralls]

Coverage Report for CI Build 27532569394

Coverage remained the same at 81.36%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	21132
Covered Lines:	17193
Line Coverage:	81.36%
Coverage Strength:	1475.41 hits per line

---

💛 - Coveralls

[ivankatliarchuk]

Why not to pass flags directly? I don't get that reason behind to have values for all arguments. This approach does not scale at all

[erdo-enes]

@ivankatliarchuk Yeah, fair point. I don't think we should add a value for every external-dns flag either.
I added these because they felt like part of the existing TXT registry config in the chart. We already have txtOwnerId, txtPrefix, and txtSuffix as values, so txtWildcardReplacement TXT encryption looked like the same bucket to me. From a user side it is also easier to discover these next to the other TXT options than having to know the exact extraArgs.
But if you think these should stay as extraArgs only, I can drop the PR or change it.

[ivankatliarchuk]

extraArgs already handles these flags today without any chart changes:

  extraArgs:
    txt-wildcard-replacement: "something"
    txt-encrypt-enabled: true
    txt-encrypt-aes-key: "..." <- I would most likely discourage someone to do that, as this is a key, and it should not be passed be plain AES key passed to helm chart

The chart currently exposes ~22 named values out of ~163 total flags - the ones essentially every user needs (source, provider, registry identity, intervals, filters), some may need to be dropped or added. The remaining long tail is intentionally left to extraArgs to avoid chart bloat and maintenance overhead as the binary evolves.

What's the use case that makes dedicated chart values necessary here rather than extraArgs? Without a concrete problem or use case that extraArgs can't already solve, this is hard to review

[erdo-enes]

extraArgs already handles these flags today without any chart changes:

  extraArgs:
    txt-wildcard-replacement: "something"
    txt-encrypt-enabled: true
    txt-encrypt-aes-key: "..." <- I would most likely discourage someone to do that, as this is a key, and it should not be passed be plain AES key passed to helm chart

The chart currently exposes ~22 named values out of ~163 total flags - the ones essentially every user needs (source, provider, registry identity, intervals, filters), some may need to be dropped or added. The remaining long tail is intentionally left to extraArgs to avoid chart bloat and maintenance overhead as the binary evolves.

What's the use case that makes dedicated chart values necessary here rather than extraArgs? Without a concrete problem or use case that extraArgs can't already solve, this is hard to review

Yeah, that makes sense. extraArgs can handle this today, so this is more about discoverability than a missing capability.
The use case I hit was configuring TXT registry with wildcard replacement / encrypted TXT records from the Helm chart. Since the chart already has first-class TXT registry values like txtOwnerId, txtPrefix, and txtSuffix, I expected the related TXT options to be in the same area of values.yaml. I missed that the supported way was extraArgs, so the chart looked like it did not support these options even though the binary does.
I agree with the concern about txtEncryptAesKey as a plain chart value. Passing that as a value/arg is not ideal; using env with a Secret is better
Would a smaller change make more sense here? For example:

• keep only non-secret TXT registry convenience values, or
• drop the value additions and instead add a README example showing txt-wildcard-replacement through extraArgs and EXTERNAL_DNS_TXT_ENCRYPT_AES_KEY through env.valueFrom.secretKeyRef.
  I’m fine changing the PR in that direction if that fits the chart’s approach better.