Skip to content

Commit

Permalink
Add Tags dimension (#227)
Browse files Browse the repository at this point in the history
  • Loading branch information
4 people authored Nov 7, 2023
1 parent 147250f commit baaca26
Show file tree
Hide file tree
Showing 3 changed files with 124 additions and 0 deletions.
1 change: 1 addition & 0 deletions specification/dimensions/dimensions.mdpp
Original file line number Diff line number Diff line change
Expand Up @@ -28,5 +28,6 @@ dimensions to categorize, filter, and reveal details in your data when grouped w
!INCLUDE "servicename.md",1
!INCLUDE "subaccountid.md",1
!INCLUDE "subaccountname.md",1
!INCLUDE "tags.md",1

[FODOFC]: https://www.finops.org/framework/capabilities/
77 changes: 77 additions & 0 deletions specification/dimensions/tags.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# Tags

The Tags column represents the set of tags assigned to Tag Sources that also account for potential provider-defined or user-defined tag evaluations. Tags are commonly used for scenarios like adding business context to billing data to identify and accurately allocate charges.

A tag becomes *finalized* when a single value is selected from a set of possible tag values assigned to the tag key. When supported by a Provider, this can occur when a tag value is set by provider-defined or user-defined rules.

The Tags column adheres to the following requirements:

* The Tags column MUST contain user-defined and/or provider-defined tags.
* The Tags column MUST only contain finalized tags.
* The Tags column MUST be in Key-Value Format.
* A Tag key without a specified value MUST have its tag value set to null.
* If Tag finalization is supported, providers MUST publish tag finalization methods and semantics within their respective documentation.
* Providers MUST NOT alter user-defined Tag keys or values.

Provider-defined Tags additionally adhere to the following requirements:

* Provider-defined tags MUST be prefixed with a provider-specified tag key prefix.
* Providers SHOULD publish all provider-specified tag key prefixes within their respective documentation.

## Provider-Defined vs. User-Defined Tags

The following is an example of one user-defined tag and one provider-defined tag, respectively, with tag key, `foo`. The first tag, which is user-defined, is not prefixed. The second tag is prefixed with marketplace/ which the provider has specified as a reserved tag key prefix.

```json
{
"foo":"bar",
"marketplace/foo": "bar"
}
```

## Finalized Tags

Within a provider, tag keys may be associated with multiple values, and potentially defined at different levels within the provider, such as accounts, folders, resources and other resource grouping constructs. When finalizing, providers must reduce these multiple levels of definition to a single value where each key is associated with exactly one value. The method by which this is done and the semantics are up to each provider, but must be documented within their respective documentation.

As a example, let's assume 1 sub account exists with 1 virtual machine with the following details, and tag inheritance favors Resources over Sub Accounts.

* Sub Account
* id: *my-sub-account*
* user-defined tags: *team:ops*, *env:prod*
* Virtual Machine
* id: *my-vm*
* user-defined tags: *team:web*

The table below represents a finalized cost and usage dataset with these resources. It also shows the finalized state after all resource-oriented, tag inheritance rules are processed.

| ResourceType | ResourceId | Tags |
| :---------------| :--------------| :-------------------------------------------|
| Sub Account | my-sub-account | { "team": "ops", "env": "prod" } |
| Virtual Machine | my-vm | { "team": "web", *"env": "prod"* } |

Because the the Virtual Machine Resource did not have an `env` tag, it inherited tag, `env:prod` (italicized), from its parent Sub Account. Conversely, because the Virtual Machine Resource already has a `team` tag (`team:web`), it did not inherit `team:ops` from its parent Sub Account.

## Column ID

Tags

## Display Name

Tags

## Description

The set of tags assigned to Tag Sources that also account for potential provider-defined or user-defined tag evaluations.

## Content Constraints

| Constraint | Value |
|:----------------|:-----------------|
| Column required | True |
| Data type | JSON |
| Allows nulls | True |
| Value format | Key-Value Format |

## Introduced (version)

1.0
46 changes: 46 additions & 0 deletions supporting_content/dimensions/tags.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Column: Tags

## Example provider mappings

Current resource types found or extracted from available data sets:

| Provider | Dataset | Column | Hierarchical Resources | Supports Inheritance?
| :-------- | :---------------------- | :-------------------------------------------| :-------------------------------------------| :----------
| AWS | CUR | resourceTags/user:\*, costCategories/\* | Organization, Organizational Unit(s), Account | No
| GCP | BigQuery Billing Export | tags, labels, system_labels, project.labels | Folder(s), Project | Yes
| Microsoft | Cost details | Tags | Billing Account, Billing Profile, Invoice Section, Department, Enrollment Account, Management Group, Subscription, Resource Group | Yes

## Discussion Topics

Discussion / Scratch space:
- Finalized section may or may not be necessary because providers would only provide finalized tags
- Remove 'finalized' from first sentence of Tags
- User-defined tags should not have a prefix
- Provider can create and account for a reserved prefix set
- Providers should publish known prefixes somewhere
- Refer to Numeric Attribute language around provider-publishing guidelines
- Separator poll?
- Double forward slash (Chris Harris)
- Pipe (Shawn Alpay)
- 2 columns: EffectiveTags and RawTags (better names to be decided)
- Tags
- Providers must account for collisions
- If inheritance exists for a set of tags, provide the “winning” tag
- If inheritance does not exist for a tag, provide all namespaced tags (i.e. costCategory/foo, resourceTags/user:foo)
- MUST adhere to the Key-Value attribute spec

- Questions:
- Inheritance (e.g., source)?
- Merging different datasets (e.g., source)?
- Do we split effective tags and raw tags or merge them together with a predefined key format (e.g., “<source>/<key>”)?
- Simple JSON key/value pair or array of JSON objects?
- What does it look like interpreting labels using Excel formulas only? Would users be required to dl a plugin, use vbscript, etc.
- Excel: https://support.microsoft.com/en-au/office/parse-text-as-json-or-xml-power-query-7436916b-210a-4299-83dd-8531a1d5e945 (supports {"foo": "bar"} approach)
- Sheets: Seems to require scripting
- How do we fit into the top 3 clouds?
- Should we give an opinion around requiring k/v tags?
- Create a poll around calling the dimension “Tags” or “Labels”?
- “Custom Tags/Labels”?
- One key/value pair for all tags “tags”: [ … ]
- Which raw format do we go with?

0 comments on commit baaca26

Please sign in to comment.