feat: introduce a Tags field to the Endpoint struct to support DNS record tags

[AndrewCharlesHay]

What does it do ?

Fixes #5442

Motivation

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 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:

• OWNERS

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]

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

[ivankatliarchuk]

/ok-to-test

[ivankatliarchuk]

I'm unsure here, what the right design should be. Tags are prodiver specific, so most likely it should be part of ProviderSpecific, unfortunately ProviderSpecific is Name,Value. We may need a better ProviderSpecific abstraction. But this will be a refactoring of current code, more effort then current solution.

This is just my 50 cents

@mloiseleur @7onn wdyt?

[ivankatliarchuk]

As well as at the moment not sure how many providers do support tags, it's a great feature by itself, but gcp or aws do not support tagging individual DNS resource records

[mloiseleur]

🤔 Rework correctly the abstraction would be simpler when we have multiple providers supporting tags. So, how about keep existing CRD and use it like that:

spec:
  endpoints:
    - dnsName: foo.com
      providerSpecific:
         name: "tags"
         value: "[\"taga:valuea\", \"tagb:valueb\"]"

ie: convert the providerSpecific value named tags as the expected array ?

And when we have multiple providers with tags, we can introduce a dedicated field to it, with better schema and CEL validation ?

[7onn]

I'm unsure here, what the right design should be. Tags are prodiver specific, so most likely it should be part of ProviderSpecific

Making this provider specific helps with decoupling the code but also foments redundancy. So unless the majority of the providers supports it, I'd argue for keeping it provider specific for the sake of implementation simplicity (even though increasing the amount of code).

Unfortunately, I had opened this before checking this notification and realizing tagging was to be handled in this PR, so we might have worked redundantly. Looking forward to coordinate how to proceed with this :)