Inconsistent Tagging Schema in ACK S3 Controller

[af-ilya]

Description:
The current schema for the ACK S3 controller allows setting tags under spec.tagging.tagSet, where each tag is defined as a key-value pair. However, according to the ACK documentation at https://aws-controllers-k8s.github.io/community/docs/user-docs/ack-tags/, tags should be specified under spec.tags.

The schema should be updated to reflect this structure to align with the documentation.
This inconsistency may confuse users attempting to apply tags based on the provided documentation, especially when building automation around this field.

Expected Schema:

spec:
  tags:
    - key: string
      value: string

Current Schema:

spec:
  tagging:
    tagSet:
    - key: string
      value: string

[github-actions]

Hello @af-ilya 👋 Thank you for opening an issue in ACK! A maintainer will triage this issue soon.

We encourage community contributions, so if you're interested in tackling this yourself or suggesting a solution, please check out our Contribution and Code of Conduct guidelines.

You can find more information about ACK on our website.

[michaelhtm]

Hi @af-ilya, I notice that the tags defined in the link you shared are for ECR Repository. Did you mean to share another link?

[af-ilya]

Hi @michaelhtm , thanks for your response.
I meant to share the link from the ACK docs, not a specific resource, repository is just an example there.
But, yeah, here is the link to a resource without the same tag schema as mentioned in the docs:
https://aws-controllers-k8s.github.io/community/reference/s3/v1alpha1/bucket/

[michaelhtm]

Thanks for the response @af-ilya. I understand your concern. Having taggig.tagset.key in S3 is not consistent with the other controllers. In ACK, we avoid changing the CRD to prevent introducing breaking changes. One solution under consideration is converting the CR labels to tags instead. Here is the thread #2091

[diversario]

Adding .spec.tags to the existing CR wouldn't be a breaking change, though. .spec.tagging could be marked as deprecated, but supported.

[michaelhtm]

That is true, I would not be opposed to that idea.
@a-hilaly @rushmash91 any thoughts on this?