FOCUS #317: BillingAccountType and SubAccountType

[flanakin]

Suggesting adding BillingAccountType and SubAccountType to include the provider-specific labels for the BillingAccountId/Name and SubAccountId/Name. This is similar to ResourceType and CommitmentDiscountType for their respective ID and Name columns.

[rupagcp]

Can you share some examples of "labels"? Thanks!

[flanakin]

Can you share some examples of "labels"? Thanks!

Examples are in the supporting content: https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/pull/287/files#diff-1a657454b35fbf6f129f8110ebe3a78a1514483cac3fe86b7a772d38edaaafef

[TDubovchenko]

It's probably advisable to provide provider-specific labels for the columns in the metadata rather than in additional columns.

[cnharris10]

The next obvious column addition after this is something like "ParentAccount{ID,Name}" or "GroupingAccount{ID,Name}" to denote:

AWS --> Organizational Units
Azure --> Management Groups and/or Resource Groups?
GCP --> Folders

I'll add this issue/proposal and link to this as well.

[flanakin]

It's probably advisable to provide provider-specific labels for the columns in the metadata rather than in additional columns.

BillingAccountType can change across billing accounts from the same provider.
SubAccountType can change across providers.

If we put it in metadata, then we won't have it available to explain datasets aggregated across providers.

[flanakin]

Can you share some examples of "labels"? Thanks!

See the supporting content: https://github.com/FinOps-Open-Cost-and-Usage-Spec/FOCUS_Spec/pull/287/files#diff-4660da431689f69fb2f3e849c945ba9aac12542a8d2156c0f3b71513554344a3

For SubAccount for instance, examples are "Member Account", "Project", and "Subscription".

[rupagcp]

I think this should be reviewed and discussed, not to be included in v1.0 GA without alignment

[udam-f2]

This is being discussed as a possible metadata column that can later be added explicitly by providers to the dataset OR post-processed by consumers if they find this valuable. Leaving the PR open in case there's traction for still adding as a column but the maintainer group was leaning towards adding as a metadata field first.

[ijurica]

Discussion Topics:

• Do practitioners find this information relevant?

  • Do we require clear, out-of-the-box understanding of what information is provided in SubAccountId and BillingAccountId?

• Should these be provided as columns or in metadata?

  • it's important to determine if all providers will consistently provide the same values in all charge records. For example, in case of Oracle, this might not apply to the SubAccountType, i.e. we might expect one of two values depending on a charge Tenancy or Child-Tenancy. (@arrarama Is this assumption correct?)
  • Even if the same values are provided in all charge records the question is whether practitioners prefer ease of access or reduced data size.

• If provided as columns, what feature level should we require?

  • Considering that BillingAccountId and SubAccountId are already mandatory, providers should be able to provide this additional information as well. Therefore, the decision hinges on practitioners: Assuming practitioners find this info valuable for inclusion do they require consistency across all billing data sets from various providers?

I vote for including them as mandatory columns.

[arrarama]

@ijurica - From an OCI perspective we intend to map SubAccountType to tenant id. This will contain either parent or child tenancy id depending on where usage was incurred.

[jpradocueva]

Presented on April 18th meeting:
Important feedback:

• Some members don't consider these columns critical for v1.0
• It would be good to have the support from other cloud service providers

[mlohmeijer]

Presented on April 18th meeting: Important feedback:

• Some members don't consider these columns critical for v1.0
• It would be good to have the support from other cloud service providers

Realizing this is just my viewpoint as a new joiner to the project:
Having followed the discussion in this meeting: as a practitioner the ID's are more important than having the Type attached to the ID if the Type is only a different name as a result of the type of contract (in the given Microsoft example). I don't see the Type as a field that would get actively used in cost/billing analyses or showback/chargeback scenarios.

[AWS-ZachErdman]

Are there any specific use cases these columns would help? I'm concerned whether the value of these columns are worth increasing the schema size.

[rupagcp]

I don't know if I understand the value of these fields to a practitioner