[FR] Clarify guidance on including provider SKU price properties
Problem Statement
The following SkuPriceDetails normative requirement does not clearly define the precedence between FOCUS-defined and Provider-defined SKU Price properties:
SkuPriceDetails MUST include the FOCUS-defined SKU Price property when an equivalent property is included as a Provider-defined property.
The current wording implies that both the FOCUS-defined and Provider-defined properties must be included when an equivalent exists, rather than indicating a preference for the FOCUS-defined property over the Provider-defined one.
Additionally, the following requirement only covers FOCUS-defined properties and does not address Provider-defined properties or specify that all applicable properties (not just FOCUS-defined) should be included:
SkuPriceDetails SHOULD include all FOCUS-defined SKU Price properties listed below that are applicable to the corresponding SkuPriceId.
Use Case
- Related PR #910
Desired Outcome / Practitioner Impact
When generating SkuPriceDetails, providers need clear guidance on which properties must or should be included, and whether to retain Provider-defined properties alongside the equivalent FOCUS-defined properties, or include only the FOCUS-defined ones when equivalent properties exist.
Type of Request
- [x] Refinement of an existing FOCUS attribute
- [ ] Addition of a provider-supported field not yet in FOCUS
- [ ] Net-new concept (not currently supported by providers or FOCUS)
️Organizations Requesting or Supporting This Feature
- Neos
- Microsoft
FinOps Scope Alignment (Optional)
- [x] Public Cloud – e.g., AWS, Azure, GCP, OCI
- [x] Software-as-a-Service (SaaS) – e.g., Salesforce, Snowflake
- [x] Data Center – on-prem compute and infrastructure
- [ ] Licensing – subscription or usage-based licensing models (under development)
- [ ] AI – cost and usage for AI models and platforms (under development)
- [ ] Custom – internal tooling, specialized infra (under development)
Impacted Parties
- [x] FinOps Practitioner – end users who analyze or act on the data
- [x] FOCUS Data Generator – providers generating output aligned to the spec
- [x] Vendor Supporting FOCUS – vendors or tools ingesting the spec or using the spec language in their UI
- [ ] Other (please explain in comments)
Level of Ambiguity
How clearly defined is the request? Rate from 1 to 5:
- 1 = very well-defined, low complexity
- 3 = moderately scoped, some ambiguity
- 5 = vague, high complexity or conceptual
1
Supporting Documentation
The SKU Price Details normative requirements should clearly specify that:
- All applicable SKU Price properties (not just FOCUS-defined) should be included.
- FOCUS-defined properties are preferred over equivalent Provider-defined properties, and duplication must (or should) be avoided.
Proposed Solution / Approach
The SKU Price Details normative requirements should clearly specify that:
- All applicable SKU Price properties (not just FOCUS-defined) should be included.
- FOCUS-defined properties are preferred over equivalent Provider-defined properties, and duplication must (or should) be avoided.
Subset of existing requirements relevant to this discussion:
Note: Two highlighted requirements are proposed for revision.
- When SkuPriceDetails is not null, SkuPriceDetails adheres to the following additional requirements:
- SkuPriceDetails MUST be associated with a given SkuPriceId.
- SkuPriceDetails MUST NOT include properties that are not applicable to the corresponding SkuPriceId.
- SkuPriceDetails SHOULD include all FOCUS-defined SKU Price properties listed below that are applicable to the corresponding SkuPriceId.
- SkuPriceDetails MUST include the FOCUS-defined SKU Price property when an equivalent property is included as a Provider-defined property.
- SkuPriceDetails MAY include properties that are already captured in other dedicated columns.
Proposed revised version:
Note: Two revised requirements are highlighted.
- When SkuPriceDetails is not null, SkuPriceDetails adheres to the following additional requirements:
- SkuPriceDetails MUST be associated with a given SkuPriceId.
- SkuPriceDetails MUST NOT include properties that are not applicable to the corresponding SkuPriceId.
- SkuPriceDetails SHOULD include all applicable SKU Price properties for the corresponding SkuPriceId.
- SkuPriceDetails MUST include FOCUS-defined SKU Price properties instead of any equivalent Provider-defined properties.
- SkuPriceDetails MAY include properties that are already captured in other dedicated columns.
What these changes achieve:
-
"SkuPriceDetails SHOULD include all applicable SKU Price properties"— This requirement covers all relevant properties, regardless of whether they are FOCUS-defined or Provider-defined. -
"SkuPriceDetails MUST include FOCUS-defined SKU Price properties instead of any equivalent Provider-defined properties."— This makes it explicit that, when an equivalent FOCUS-defined property exists, it must be included instead of the Provider-defined one. This avoids duplication and establishes FOCUS-defined properties as the preferred.
Community Support (Add Your Voice)
If your organization supports this request or has a similar use case:
- Add a comment below including:
- Your organization
- A brief explanation of why this is important to you (e.g., use case, urgency) FOCUS Staff & Maintainers will aggregate supporting orgs over time.
@ijurica do we have organizational support to add here?
This feels like something someone should just submit a PR for. I don't think it's worth us having a big discussion. I do agree, but I'd rather spend TF time on more sticky topics. I gave it a 👍 for my support.
@Matt-Cowsert
-
Organizational support: FOCUS-defined properties were only just introduced in the 1.2 release, so I'm not sure the broader audience is even aware of this issue yet.
-
Proposed Approach section: I know we’re not technically supposed to provide solutions at this stage, but this one felt fairly straightforward (especially since a PR already exists). That said, if you feel this level of detail doesn’t belong in the FR, feel free to reduce it.
PR #910 was merged. Thus, we can close this FR as complete! 🎉