FOCUS #497: SkuPriceDetails column #503
Conversation
* Added immutability clause per conversation on 20240703. * Brought formatting in line with current draft of editorial guidelines
* Additional formatting changes per editorial guidelines
* Added immutability per discussion 20240709 * Updated formatting to align to current draft of editorial guidelines
More formatting per guidelines
|
OPEN ITEMS:
Action Items from TF-2 call on July 24:
Action Items from the Maintainer's call on August 5th:
Action Items from TF-2 call on August 7th:
Action Items from TF-2 on Aug 14 call:
Action Items, Members', Aug 15:[Maintainers-#503 ] Karl to address any final comments and maintainers to review and approve the PR. Action Items, Maintainers call, Aug 19:
|
|
Additional Discussion points:
|
SKU - SKU Price relationshipIs the following statement correct?
When we wrote the SkuPriceId specification, it seemed to be the case, but I now have doubts. It would be beneficial to examine sample cost records to verify or contradict this. Sample charge recordsKarl has already noted the need to include sample charge records (beyond sample SKU Details and SKU Price Details values). Here are some key use cases I believe we should address:
Note: It is very likely that the terms used are not the most appropriate (for internal use only). We should probably address those pricing strategies/models/vegetables 🙂 at some point in the glossary or appendix. |
Correct ConsumedUnit to ConsumedQuantity
Correct ConsumedUnit to ConsumedQuantity
|
Here are some of the use cases (phrased as questions I'd want to be able to easily answer) I had in my mind when I was creating these dimensions. I do reference specific CSP offerings in many of these because each CSP has a different approach to pricing/billing which may make it easier or harder to answer a question. How many cores of D-series (Azure) VMs do we have running in each region? Specific to SkuPriceDetails |
|
@kk09v I've noticed that you've started preparing sample dataset. I feel like we should prepare more sample records before we close this PR. We should probably choose a couple of records from each CSP. As mentioned before, here are some use case scenarios that I believe we should cover.
Not sure if this helps, but here it is - in this Google spreadsheet, I've extracted some Azure-EA sample records (focusing on a subset of FOCUS and Pricing columns). As mentioned before, I've used sample data provided in the azure-finops-toolkit. In one of the sheets, I've also provided a list of columns available in the FOCUS Dataset, EA-Pricing, and Public Azure Pricing. |
|
“…which are not captured in another FOCUS column.” Implies that “Region” in Irena’s example would not be in SKU Details. Are we losing some compatibility over time (constructing a query against multiple versions of FOCUS data in a single database would have to look in a column for new data, but parse SKU Details in older data), clarity (we recreate the problem we have today having to know what collection of columns and SKU Details makes up a unique SKU), and flexibility if we take some things out because they are in columns? As opposed to allowing each vendor to specify HOW THEY define their SKU fully (while still filling out the columns correctly also). If all of the SKU Details are in for any SKU, including the data that make that SKU unique, we know they are all always all the attributes. I see Udam's point about this being an easy button that might slow down column standardization, but it also does simplify reporting for practitioners in certain use cases wouldn't it? If I'm getting this all wrong, please let me know. Happy to take a call. |
Region (in particular) is tricky because Region could be a property of a SKU (in the Azure example, the SKU is D4v3/D4sv3 in East US), could be a property of a SKU Price (where the same SKU deployed in different regions has a different price), or could be a property of a resource (a single SKU/SKU Price in GCP applies to "Americas" where the resource could be deployed any of 4 regions). In my example with the Microsoft data, I faked a property called PricingRegion as an example of what could be put into SkuPriceDetails. I used the value "US East" from the x_SkuRegion column which actually differs from the value in the Region column "East US" This specific case aside, to your question of "What happens if a new dimension is created for something currently in SkuDetails?" The value SHOULD NOT be removed from the SkuDetails because that would violate the immutability clause in the normative section. The clause you're referencing is not in the normative section; it was intended to signal more about what data should be included rather than what should not be included. I'm trying to avoid someone implementing this reading these columns and asking themselves, "Does this require me to repeat PricingCategory, PricingUnit, etc. in SkuPriceDetails?" The answer to that question is no, but if they decide to do so, that's fine because there's nothing indicating the MUST NOT nor SHOULD NOT repeat those as key/value pairs here. |
This likely doesn't meet the criteria for being included in the appendix due to being well defined elsewhere, but I'm including it for discussion. PascalCase is also referenced in specification/attributes/column_naming_and_ordering.md with a link to an external definition https://techterms.com/definition/pascalcase
Additionally, reformatted examples as PascalCase
|
I added the PascalCase clause to both and reformatted the examples as PascalCase, per the discussion in TF2 today. I also added PascalCase to the glossary, though it may not meet our criteria for being included because it's well defined externally. The only other place it's referenced in FOCUS is in specification/attributes/column_naming_and_ordering.md where there's a link to an external site. This was added to the glossary for discussion since I could go either way on including it. If we decide to keep it, we'd link PascalCase to the glossary in these column definitions, otherwise we'll remove that addition from the glossary. Though it could be argued that PascalCase should belong as an attribute, I don't believe that's warranted at this point. |
Action Items from TF-2 call on Aug 28:
|
Co-authored-by: Udam Dewaraja <[email protected]>
Replaced _italic_ with *italic* Replaced * bullet with - bullet
The ordering has gotten flipped around a few times. The general feedback was that grouping clauses together by topic was easier to read and understand than grouping them by level of normativity. I'm not aware of where we take a stand on this in the design guidelines or similar, but happy to conform to guidelines as needed. |
|
@AWS-ZachErdman can you take a look at lines 3 and 13 to make sure I've incorporated your feedback appropriately? |
|
Changed verbiage on lines 10 and 11 to reconcile a conflict between the bullet and sub-bullets. |
Action Item from Maintainers' call on Sep 2nd:
|
Co-authored-by: Irena Jurica <[email protected]>
|
Updates since last week for 20240905 meeting:
|
|
Approved by the Members group on Sep 5. |
This change is dependent on #503 being merged as it links to SkuPriceDetails. This change to SkuPriceId solves for a case where a provider does not have a SkuPriceId but wants to include SkuPriceDetails. This case was introduced when there was a change in scope of #503 to not include SkuDetails. Changes: - Reformatted normative to bullets - Added option (MAY) to repeat SkuId as SkuPriceId when there is no SkuPriceId, as long as other conditions are not violated. --------- Co-authored-by: Udam Dewaraja <[email protected]> Co-authored-by: Joaquin <[email protected]>
jpradocueva
merged commit 31803cb
into
FinOps-Open-Cost-and-Usage-Spec:working_draft
Introduction of KeyValueFormat columns SkuDetails and SkuPriceDetails to capture properties of a SKU ID and SKU Price ID, respectively.
Lead Maintainer: Karl
Documents: