Allow templating of additional labels on resources

KingJ commented 8 months ago

What does this PR do?

This commit introduces two optional values in the Helm chart - additionalPodLabels and additionalLabels. The former will apply the supplied labels on to the templated pod only, whereas the latter will apply them to all resources - including the pod.

These labels are applied in addition to the existing labels that the chart supplies. This therefore allows users to supply their own additional labels without affecting the essential labels supplied by the chart.

This is useful for situations where a user needs to supply additional labels for audit/attribution purposes... including attributing cost within Cloudability itself!

The deployment template was changed to include all labels on the pod, rather than just the selectorLabels. This does not impact the Deployment's selector, as it only looks for a subset of labels - not complete equality. As a result, even if a user does not supply any additional labels, this change will result in their pod gaining the app.kubernetes.io/version and app.kubernetes.io/managed-by labels that are already present on all other resources.

I have not bumped the chart version in Chart.yaml, as I am unsure of what the release process is for this chart.

How should this be manually tested?

Template the chart using the default set of values (i.e. no additional labels), and then supply values for additionalPodLabels and additionalLabels. Observe that these are now included in the

Any background context you want to provide?

We attribute cost within Cloudability based on specific internal-use labels on pods - this allows for a finer-grained breakdown than namespace-labelling alone. However, this means that we need to be able to put this label on all pods, which we are currently unable to do with the existing chart. Hence, the Cloudability Metrics Agent is currently an unattributed cost within Cloudability itself.

We also use these internal-use labels also help to attribute general ownership of resources - hence we wish to put them on all resources, not just pods. It is common in many Helm charts to allow users to add additional labels to all resources, as well as add pod labels only.

What are the relevant Github Issues?

N/A

Developer Done List

[ ] Tests Added/Updated N/A - there are no chart tests
[ ] Updated README.md N/A - the README does not detail Helm values
[x] Verified backward compatible For existing users, this will only result in their pod gaining the app.kubernetes.io/version and app.kubernetes.io/managed-by labels that are already present on all other resources. Supplying additional labels is optional.
[ ] Verified database migrations will not be catastrophic N/A - This is only a change to the chart, not the agent itself and hence migrations do not come in to play.
[x] Considered Security, Availability and Confidentiality This change does not change any security properties of the agent or the Kubernetes resources

For the Reviewer:

By approving this PR, the reviewer acknowledges that they have checked all items in this done list.

Reviewer/Approval Done List

[ ] Tests Pass Locally
[ ] CI Build Passes
[ ] Verified README.md is updated
[ ] Verified changes are backward compatible
[ ] Reviewed impact to Security, Availability and Confidentiality (if issue found, add comments and request changes)

CLAassistant commented 8 months ago

All committers have signed the CLA.

KingJ commented 7 months ago

This PR is obsoleted by https://github.com/cloudability/metrics-agent/pull/251, which also allows for adding additional labels to all resources and/or pods. I've successfully pulled in v2.11.23 and confirmed that the functionality works as expected. Therefore, I will close this PR.

cloudability / metrics-agent