Consistent Tags resource handling #63
Description
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.