Add capability to input a generic string field in the CR yaml for tags.
The input must be able to be a single tag, or a comma (or whatever) delimited list of tags.
The desired result is that on each Kube object generated by the operator will specify all those tags.
The motivation for this issue is that KCNS and Bridge and whatever services that inspect/discover resources in the hypervisors generally use specific tags in their discovery and/or filtering.
While it is humanly possible to add specific tags to our existing resources as needed, that becomes a pain when:
(a) the tag values for Kube objects will be overwritten by the Operator (aka, get back to the desired/deployed state) POINT A IS THE FOCUS OF THIS ISSUE.
(b) "we" (either CJOT or generic customers) might already have tags for similar purposes/meanings
(c) for cloud services, even if we manually add the tags, the tags might be lost at reprovisioning if someone forgot to also add the tag to the provisioning code/Terraform/whatever
On a separate thread: We are asking Bridge services, such at the Topology service, to have a capability to search/filter on any tag (ie, today Topology service specifically uses tag = "application"). However, we have no control over those other services, and there are several of them. We have no idea what tags they might additionally require in the future.
The point of this issue is that we are asking for the Operator to create the tags for us at the time of deployment, thereby including the tags as part of the Desired State.
Add capability to input a generic string field in the CR yaml for tags. The input must be able to be a single tag, or a comma (or whatever) delimited list of tags. The desired result is that on each Kube object generated by the operator will specify all those tags.
The motivation for this issue is that KCNS and Bridge and whatever services that inspect/discover resources in the hypervisors generally use specific tags in their discovery and/or filtering.
While it is humanly possible to add specific tags to our existing resources as needed, that becomes a pain when: (a) the tag values for Kube objects will be overwritten by the Operator (aka, get back to the desired/deployed state) POINT A IS THE FOCUS OF THIS ISSUE. (b) "we" (either CJOT or generic customers) might already have tags for similar purposes/meanings (c) for cloud services, even if we manually add the tags, the tags might be lost at reprovisioning if someone forgot to also add the tag to the provisioning code/Terraform/whatever
On a separate thread: We are asking Bridge services, such at the Topology service, to have a capability to search/filter on any tag (ie, today Topology service specifically uses tag = "application"). However, we have no control over those other services, and there are several of them. We have no idea what tags they might additionally require in the future.
The point of this issue is that we are asking for the Operator to create the tags for us at the time of deployment, thereby including the tags as part of the Desired State.