search

FinOps-Open-Cost-and-Usage-Spec / FOCUS_Spec

The Unifying Specification for Cloud Billing Data
https://focus.finops.org
Other
183 stars 39 forks source link

[Proposal] Separation of Tags and Labels #356

Open ahullah opened 8 months ago

ahullah commented 8 months ago

Description

Depending on your CSP you will have one of these mechanisms for adding metadata to resources:

-Tags are provided as key value pairs. -Labels are provided as simply a key.

Should we be attempting to merge these two constructs on behalf of the practitioner ?

In the Current version of the spec they are consolidated under one entity in: https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/blob/working_draft/specification/columns/tags.md

Proposed approach

We should separate these fields into 2 distinct entities representing Tag and Label, it is then at the practitioners discretion on how these elements should be merged in the event consolidated reporting on these fields is required.

Github issue or Reference

https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/blob/working_draft/specification/columns/tags.md

Context

Merge approaches for this have been discussed on the weekly team call and how NULLs are handled for labels has proved a sticky issue E.g

Example Tag Key, Value Name, BobServer

Example Label Key, Value BobServer, NULL OR NULL, BobServer OR BobServer, BobServer

thecloudman commented 6 months ago

My thoughts on this: In our data we use both Label and Tag. As our primary cloud provider was Azure, the tag terminology is what is used across our org. Since bringing on GCP, we started using labels which are also Key: Value pairs. For terminology we decided to keep our standards consistent and stay with the words tag and tagging, knowing that in google we have to use the Label service not the tag service.

We also went through limitations of each provider on tagging, such as special characters, case, character length, etc. and landed on a standardised structure to allow tags to be uniform across providers and in code bases for deployment.

Labels can only be applied at a project level and have a similar function to Tags in Azure, everything under the project inherits the label. There is no way to label individual resources in a google project that I know of. Tags in google can be used to define types of policy that should be applied to a resource and other sort of functions like that and I believe are billable items

Separating out tags and labels would create two column types, Tags, Labels, practitioners would then need to go through each column to find the right values for their tags. Having one Tags column combining all types of tags and labels allows practitioners to search a singular table for key: value pairs. We do that, we use Power BI with queries to search the tags column and populate additional columns with each tag type, for example CostCentre - we have a calculated column called TagCostCentre and function that searches the tags column for all variations of costcentre and adds the values to the new column we can then use that to filter all cost centre values. If there is a better way, I'm open to suggestions.

SonalGarg-SG commented 6 months ago

At this point in our discussion, let's see the real problem we are trying to solve by separating out the tags and labels. Any use case the tags are used for, technically apply to labels too so in my personal opinion, we should not have to separate out the tags versus the labels.

In Alex's example above, I would want to confirm if "NULL, BobServer" is a real use case. ( Not sure which provider allows that. ) All other scenarios, we can already handle the data by key-value pairing. I believe we should be able to close this issue.

@ahullah Am I missing anything?