Need a way to allocate based on resource hierarchy

[flanakin]

Type

Dimension
Normalized: No

Description

Many practitioners use the resource hierarchy (e.g., resource groups, management groups or orgs or compartments, departments, invoice sections) for cost allocation, showback, and chargeback. These aren't available in the FOCUS dataset, which is a blocker for FOCUS adoption because they cannot use FOCUS for cost allocation.

FOCUS should include columns for a predetermined set of layers that make sense across providers to meet practitioners' allocation scenarios. Alternatively, FOCUS could include a single AccountHierarchy JSON column with an array of levels in the resource/billing hierarchy.

Definition of done

• Rationalize vendor-neutral, cross-cloud naming
• Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc.

Want this column in FOCUS 1.0 GA?

Give it a 👍 below ↴

If you can discuss and help finalize the change, add yourself as an assignee ↗

Comments are welcome and encouraged!

[kk09v]

I agree that losing Resource Group would be detrimental to our understanding of our Azure costs.

Since each CSP has a different structure of both real and logical hierarchy, I'm currently not in favor of adding an additional column to the spec just for an additional layer of the hierarchy. It could always be included as a custom provider column (or columns if a provider has a deeper structure). However, I did like the idea of a single AccountHierarchy column that would also be flexible enough for each vendor to reflect their hierarchy, regardless of depth.

If this isn't present in 1.0 and is not added as a custom provider column, I would work around this limitation by extracting the ResourceGroup from the ResourceId (which I already do when using certain feeds which don't contain ResourceGroup).

[flanakin]

@kk09v We provide x_ResourceGroupName, so you'll have that for Microsoft data. I think the main question right now is would you consider AccountHierarchy as a blocker to adoption? If so, we should push for it in 1.0. If not, we should table it for a post-1.0 discussion.

[udam-f2]

@kk09v We provide x_ResourceGroupName, so you'll have that for Microsoft data.

+1. Nothing is lost if it's available in the provider data.

[marc-perreaut]

I believe resource hierarchy is provider-specific, and there might be different possible resource hierarchies that can be used for allocation or reporting for a single provider, so it's not easy to find a common format/model in FOCUS, which can be fairly exploited.
At this stage, providing resource hierarchy with vendor x_ custom columns seems OK to me.

[flanakin]

Yes, resource hierarchy is provider specific. We would define a generic way to convey what the hierarchy is which would be provider-agnostic, making it easier to apply logic across providers. Or at least, that's the theory 🙂

[udam-f2]

Is this worthy of being a column that needs to be defined at a row level? Or is this metadata that could be at a billing account as it feels it's relatively static data?

[flanakin]

It's not static. It can change multiple times within an hour. So I suppose that depends on whether someone wants to track costs back to where they were when the charge happened or if they only care about the latest value. I've heard both. The only way to do it when the charge happened would be in this dataset.

[shawnalpay]

I came across this graphic relatively recently, and I think it helps tell the story of what needs to be made available. Not just the identifiers for them, but the tags they carry.

[shawnalpay]

@flanakin Given that we now have #618, can we now close this issue?

[jpradocueva]

Comments from Members' call on Oct 31:

Analysis: This issue on hierarchical allocation has been effectively covered by work item #618.
Agreements: Shawn will follow up with Michael to see if we can close #301 in favor of the ongoing work captured in #618.