Consistent Tags resource handling

[jaypipes]

Different AWS service API use different data types to represent pretty much the exact same thing: a set of Key:Value pairs ("tags") for the resource. For instance, some APIs use a map[string]string as the underlying data type in API payloads. Some use a []struct{string, string}. Some use map[string]struct{}`, etc etc.

In addition to inconsistent data type representation of tags, the APIs also have inconsistent methods of adding, removing, replacing, and querying for tags on a resource. For example, some APIs have a TagResource and UntagResource API call. Others have an AddTag or RemoveTag call. Some APIs allow tagging a resource at create time. Others only allow updating tags after creation.

We want to make the experience of tagging and untagging resources consistent across all AWS APIs -- both from a data type representation as well as the behaviour of set/unset methods.

For all CRDs exposed by an ACK service controller, we want to have a consistent Spec.Tags field:

type {Resource}Spec struct {
    // Tags are a collection of string key/value pairs indicating the AWS
    // Tags that should be associated with the resource
    Tags map[string]string
    // Rest of Spec fields...
}

There will, of course, be no TagResource or UntagResource Kubernetes API call, since Kubernetes API is declarative and any changes to the desired state of a resource are simply handled by kubectl apply'ing the new desired resource state (as the CR's Spec struct).

So, the ACK service controller will need to have logic embedded in it that essentially instructs the service controller to handle tag information set/unset/add/remove logic in the way that the AWS service API for that controller expects. So, if the AWS service API has a TagResources API call and the only thing about a resource's desired state that has changed is the tags collection, then the service controller would call the TagResources API call, etc.

[mhausenblas]

Makes sense, yes. Came to a somewhat similar conclusion when I looked into the tagging across AWS services topic.

[nithu0115]

@jaypipes, Make sense to use TagResources API call. Just a comment, TagResources API call does require additional permissions apart from service permissions which we need to document:

tag:GetResources
tag:TagResources
tag:UntagResources
tag:GetTagKeys
tag:GetTagValues

[mhausenblas]

We should make sure it's aligned with AWS Resource Groups.

[ack-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Provide feedback via https://github.com/aws-controllers-k8s/community. /lifecycle stale

[a-hilaly]

/lifecycle frozen

[haarchri]

any updates here ?

[jaypipes]

any updates here ?

Hi @haarchri! Yes, we're making progress in this effort. The first part of the progress is here:

https://github.com/aws-controllers-k8s/runtime/pull/91 https://github.com/aws-controllers-k8s/runtime/pull/90 https://github.com/aws-controllers-k8s/runtime/pull/89 https://github.com/aws-controllers-k8s/runtime/pull/88 https://github.com/aws-controllers-k8s/runtime/pull/87 https://github.com/aws-controllers-k8s/code-generator/pull/335

We're slowly defining what next steps are for standardizing existing controller's Tag representations.

[vijtrip2]

Hi @haarchri , this work will be unblocked once we have multi version support. https://github.com/aws-controllers-k8s/community/issues/835

Since some ACK controllers are GA now, we do not want to change the CRD's tag type (for consistent tag representation) without support for multi version.