FOCUS #492: ConsumedQuantity and ConsumedUnit and Unused commitment #507

ijurica · 2024-07-12T14:58:38Z

Currently in normative paragraphs for both ConsumedQuantity and ConsumedUnit:

MUST NOT be null if ChargeCategory is "Usage" and ChargeClass not "Correction". This column MUST be null for other ChargeCategory values.

We need to adjust this considering both ConsumedQuantity and ConsumedUnit MUST be null in case of ChargeCategory 'Usage' and CommitmentStatus 'Unused'.

…ersion

ijurica · 2024-07-12T15:08:40Z

Overview:

ChargeCategory	ChargeClass	CommitmentStatus	ConsumedQuantity	ConsumedUnit
Usage	(null)	Used	MUST not be null	MUST not be null
Usage	Correction	Used	MAY be null	MAY be null
Usage	(null)	Unused	MUST be null?	MUST be null?
Usage	Correction	Unused	MUST be null?	MUST be null?
Purchase			MUST be null	MUST be null
Credit			MUST be null	MUST be null
Adjustment			MUST be null	MUST be null
Tax			MUST be null	MUST be null

…scussion

ahullah · 2024-07-12T15:37:01Z

Hey @ijurica this makes sense to me, it keeps ConsumedQuantity and ConsumedUnit clean for easy comparison with our regular qty fields

Overview:

ChargeCategory	ChargeClass	CommitmentStatus	ConsumedQuantity	ConsumedUnit
Usage	(null)	Used	MUST not be null	MUST not be null
Usage	Correction	Used	MAY be null	MAY be null
Usage	(null)	Unused	MUST be null	MUST be null
Usage	Correction	Unused	MUST be null	MUST be null
Purchase				MUST be null
Credit			MUST be null	MUST be null
Adjustment			MUST be null	MUST be null
Tax			MUST be null	MUST be null

ijurica · 2024-07-12T16:58:33Z

Although he is on vacation, @rileyjenk Jenkins provided detailed feedback on the topic. Unfortunately, I did not register this in time 😞 . Original comment added to the Issue and I am adding a copy so that we can continue the conversation here on the PR.

In the case of unused resource commitments such as RIs, ConsumedUnit and ConsumedQuantity should not be null, as the intent was for the unit to be representative of the commitment amount that when unused. For example if I purchase an m6g.xlarge RI and don't use it, then theses columns would represent the number of compute hours that went unused.

Here is a link to the raw example data: https://docs.google.com/spreadsheets/d/13FdQoNtsJbqawxL0hPiTg7ZdNnHUs9goJj_tatsBtME/edit?gid=0#gid=0

For spend commitments that are time isolated, like savings plans, we need to consider how those are represented. The issues comes into view when say for that same instance it is now covered by a savings plan. if ConsumedUnit is now dollars (which it should not be), then the practitioner is now unable to sum the total number of compute hours for something like ec2 because the units are not the same thing. It would be compute hours.

It is for this reason that we likely need to consider dedicated columns for commitment quantity column/s for providing this information.

And the there is SAAS:

One of the principle areas that we do not support at multiple levels is where a company has a non currency unit that is purchased upfront and then "consumed" like a currency by various usage. The naming conflict is unfortunate but when a "credit", "point", "token", or "" is consumed rather than an actual currency the consumed unit wasn't really intended to be that unit. That column is intended to represent the unit that was used.

Take for example that you do not have direct to dollars and you have credits. Say that those credits are used up by different features at different rates (e.g. https://docs.snowflake.com/en/user-guide/cost-understanding-compute). If the provider puts the consumed Unit as credits it does not reflect the usage, only the credits. If I wanted to know how many compute hours I used, I would not be able to.

It is for this reason that in the example of a made up currency unit like credits, tokes, etc... we need specific support for this scenario. We need support for expressing the purchase of those units, and their burn down.

cnharris10 · 2024-07-12T17:29:29Z

Although he is on vacation, @rileyjenk Jenkins provided detailed feedback on the topic. Unfortunately, I did not register this in time 😞 . Original comment added to the Issue and I am adding a copy so that we can continue the conversation here on the PR.

In the case of unused resource commitments such as RIs, ConsumedUnit and ConsumedQuantity should not be null, as the intent was for the unit to be representative of the commitment amount that when unused. For example if I purchase an m6g.xlarge RI and don't use it, then theses columns would represent the number of compute hours that went unused.
Here is a link to the raw example data: https://docs.google.com/spreadsheets/d/13FdQoNtsJbqawxL0hPiTg7ZdNnHUs9goJj_tatsBtME/edit?gid=0#gid=0
For spend commitments that are time isolated, like savings plans, we need to consider how those are represented. The issues comes into view when say for that same instance it is now covered by a savings plan. if ConsumedUnit is now dollars (which it should not be), then the practitioner is now unable to sum the total number of compute hours for something like ec2 because the units are not the same thing. It would be compute hours.
It is for this reason that we likely need to consider dedicated columns for commitment quantity column/s for providing this information.
And the there is SAAS:
One of the principle areas that we do not support at multiple levels is where a company has a non currency unit that is purchased upfront and then "consumed" like a currency by various usage. The naming conflict is unfortunate but when a "credit", "point", "token", or "" is consumed rather than an actual currency the consumed unit wasn't really intended to be that unit. That column is intended to represent the unit that was used.
Take for example that you do not have direct to dollars and you have credits. Say that those credits are used up by different features at different rates (e.g. https://docs.snowflake.com/en/user-guide/cost-understanding-compute). If the provider puts the consumed Unit as credits it does not reflect the usage, only the credits. If I wanted to know how many compute hours I used, I would not be able to.
It is for this reason that in the example of a made up currency unit like credits, tokes, etc... we need specific support for this scenario. We need support for expressing the purchase of those units, and their burn down.

All of these points are being discussed/considered in TF1 around commitment utilization for CSP's and SaaS. I think we should combine efforts in one of the TF's to ensure that alignment occurs. As Irena and I have at least started incorporating OCI and SaaS models, the accounting of these providers makes tracking unused amounts of variable timeframes more complicated.

I'm not entirely sure that an "Unused" row is the holistic answer but instead other routes like a new ChargeCategory value and/or additional columns. We should discuss.

jpradocueva · 2024-07-12T23:05:57Z

Action items, TF-3, July 12:

TF3-#507 Irena: to check and correct any inconsistencies in the supporting content of the PR.
TF3-#507 Team members to provide feedback on the PR, preferably directly on the PR itself.

ijurica · 2024-07-18T16:22:04Z

Single purpose: When we were deciding whether to use Consumed Quantity and Unit for purchase-related records, one of the main criteria was ... Strive to build columns that serve a single purpose.... Unused usage-related records do not report on consumed but unused usage, similar to how commitment purchase-related records could report on consumable usage.
Addressing all commitment types in a uniform manner: As Chris pointed out, the introduction of new columns is likely and will be further discussed as part of the Commitment Utilization discussion. I prefer addressing all commitment types in a uniform manner over treating RIs as a special case due to the fact that the same Consumed Units would be used. (If we introduce a column for normalized quantity, we could use it for all commitment-related records and actually perform the math—comparing what's purchased vs. used and unused, etc.)

ijurica · 2024-07-19T13:52:45Z

A fictional FOCUS dataset that we could use as a basis for further Consumed Quantity/Unit discussion is available here.

jpradocueva · 2024-07-19T19:41:43Z

Action Item from TF-3, July 19 call:

Action Items:

TF3-#507 PR #507 to be put on hold.
TF3-#507 Chris and Irena: To lead the commitment utilization discussions and update the PR accordingly.

flanakin · 2024-08-07T08:40:29Z

Single purpose: When we were deciding whether to use Consumed Quantity and Unit for purchase-related records, one of the main criteria was ... Strive to build columns that serve a single purpose.... Unused usage-related records do not report on consumed but unused usage, similar to how commitment purchase-related records could report on consumable usage.

I don't quite understand why "unused" usage should not be tracked consistently. This makes it more difficult to quantify overall usage. If someone doesn't want unused, then they already have a means to filter it out. This feels like we're making things more complex by adding extra rules to support a simple summation that can never happen "simply" because of the need to group by units and some other column that isn't even in FOCUS yet to make sense of what we're grouping since not all units are created equal.

Do we have a clear understanding of the scenarios where someone would want unused included in the quantity and when they wouldn't?

shawnalpay · 2024-09-03T15:17:52Z

supporting_content/columns/consumedquantity.md

+
+## ConsumedQuantity and ConsumedUnit normatives overview
+
+| ChargeCategory | ChargeClass | CommitmentStatus | ConsumedQuantity | ConsumedUnit     |


flanakin · 2024-09-05T19:06:13Z

specification/columns/consumedquantity.md

+* ConsumedQuantity MUST be of type Decimal and MUST conform to [Numeric Format](#numericformat) requirements.
+* ConsumedQuantity MUST NOT be null if [ChargeCategory](#chargecategory) is "Usage", unless [ChargeClass](#chargeclass) is "Correction" or [CommitmentDiscountStatus](#commitmentdiscountstatus) is "Unused".
+* ConsumedQuantity MAY be null if ChargeCategory is "Usage" and ChargeClass is "Correction"
+* ConsumedQuantity MUST be null if CommitmentDiscountStatus is "Unused" or for other ChargeCategory values.


This feels wrong to me. If someone wants to filter out unused usage charges, they can do that today. If we remove this, then we won't have a clean, consistent way to quantify all usage quantities together (used and unused, which are all effectively billed for).

flanakin · 2024-09-05T19:06:58Z

specification/columns/consumedquantity.md

+
+The ConsumedQuantity column MUST NOT be used to determine values related to any pricing or cost metrics.


Shouldn't this be part of the table?

Suggested change

The ConsumedQuantity column MUST NOT be used to determine values related to any pricing or cost metrics.

* ConsumedQuantity MUST NOT be used to determine values related to any pricing or cost metrics.

flanakin · 2024-09-05T19:08:31Z

specification/columns/consumedunit.md

+* ConsumedUnit MUST NOT be null if [ChargeCategory](#chargecategory) is "Usage", unless [ChargeClass](#chargeclass) is "Correction" or [CommitmentDiscountStatus](#commitmentdiscountstatus) is "Unused".
+* ConsumedUnit MAY be null if ChargeCategory is "Usage" and ChargeClass is "Correction"
+* ConsumedUnit MUST be null if CommitmentDiscountStatus is "Unused" or for other ChargeCategory values.


Can we simplify by requiring based on ConsumedQuantity?

Suggested change

* ConsumedUnit MUST NOT be null if [ChargeCategory](#chargecategory) is "Usage", unless [ChargeClass](#chargeclass) is "Correction" or [CommitmentDiscountStatus](#commitmentdiscountstatus) is "Unused".

* ConsumedUnit MAY be null if ChargeCategory is "Usage" and ChargeClass is "Correction"

* ConsumedUnit MUST be null if CommitmentDiscountStatus is "Unused" or for other ChargeCategory values.

* ConsumedUnit MUST NOT be null if [ConsumedQuantity](#consumedquantity) is not null.

* ConsumedUnit MUST be null if ConsumedQuantity is null.

flanakin · 2024-09-05T19:08:55Z

specification/columns/consumedunit.md

+
+The ConsumedUnit column MUST NOT be used to determine values related to any pricing or cost metrics.


Should we merge with the rest of the list?

Suggested change

The ConsumedUnit column MUST NOT be used to determine values related to any pricing or cost metrics.

* ConsumedUnit MUST NOT be used to determine values related to any pricing or cost metrics.

@cnharris10

…arately from consumed quantity/unit columns (#400) **Lead Maintainers**: Chris Harris, @cnharris10, Irena Jurica, @ijurica ### Documents: * **PR**: [#400](#400) Commitment Utilization and Normalization * **PR**: [#524](#524) rename Commitment-Based Discount to Commitment-Discount by [[email protected]](mailto:[email protected]) * [Usage vs Pricing Quantity and unit examples](https://docs.google.com/spreadsheets/d/1zA0brhrEntfWlzt5VNcNLBFnKPEiarajTF84o4ATeEw/edit?gid=1705742856#gid=1705742856) * [24.07.21-CommitmentUtilization-sample-datasets](https://docs.google.com/spreadsheets/d/1AYDPZ4rl90PPEbyQJUaGCUSwZ4s_sfy-8sO2KyNq0aM/edit?usp=drive_link) * [#400-commitment-utilization](https://drive.google.com/drive/u/0/folders/1u4_rc6TAqgMwuIQEKUVIX3zAzyvLM7Dj) folder * Document: [24.09.08 - Commitment utilization discussion](https://docs.google.com/document/d/1bOD6MYoFi0fX-MgLyN-hxUpNOSfojlsL0MSt3menOxk/edit?usp=sharing) * **Slack channel**: [#tf-commitment-utilization](https://f2-focus.slack.com/archives/C07CPAQDN75) * Approval deadline: ~Aug 29~, Sep 5 # Related PR's (Appendices): - #528 - #535 # Key Points - Adds 3 new columns to track CSP usage-based and spend-based commitments: `CommitmentDiscountConsumedQuantity`, `CommitmentDiscountPurchasedQuantity`, `CommitmentDiscountUnit` - `CommitmentDiscountConsumedQuantity` captures the commitment units used or unused in a charge period. - `CommitmentDiscountPurchasedQuantity` captures the commitment units purchased for one-time and recurring charge periods. - `CommitmentDiscountUnit` captures the unit that the commitment discount specifies. - Fixes a 1.0 bug by specifying that `ConsumedQuantity` and `ConsumedUnit` MUST be NULL for unused commitment rows. (reference [pr](#507)) - Further scopes the definition of `commitment discount` and `negotiated discount` within the glossary and specifies that `CommitmentDiscount*` columns only correspond to `commitment discounts`. ## UPDATE (8/16/24) 1. Columns renamed to: `CommitmentDiscountConsumedQuantity`, `CommitmentDiscountUnit`, `CommitmentDiscountPurchaseQuantity` 2. `{List,Contracted}UnitPrice`, `Pricing{Quantity,Unit}` are null when `CommitmentDiscountStatus:Unused` 3. `{List,Contracted}Cost` are 0 when `CommitmentDiscountStatus:Unused` 4. New, official glossary terms incorporated from FinOps page for [`commitment-based discount`](https://www.finops.org/assets/terminology/#commitment-discounts) and [`negotiated discount`](https://www.finops.org/assets/terminology/#cloud-cost-management-terminology) ## UPDATE (8/19/24) 1. `{List,Contracted}{Cost,UnitPrice}` and `Pricing{Quantity,Unit}` columns now `0` or `null` when `CommitmentDiscountStatus:Unused` (TO BE DISCUSSED in TF-1) 2. `{List,Contracted}{Cost,UnitPrice}` and `Pricing{Quantity,Unit}` columns now in bullet-list format. 3. Correction-based normative text added by Irena. 4. This [pr](#524) exists to renaming all instances of `/commitment[\-,\s]?based\sdiscount/i` to `commitment discount` (with correct casing) ### Discussion Points (8/20/24) 1. 2 current views for columns: `{List,Contracted}{Cost,UnitPrice}` and `Pricing{Quantity,Unit}` when `CommitmentDiscountStatus:Unused` a. Set all values to appropriate `null` or `0` values (current). b. Set all values to the same values as the purchase record (if it exists). 2. Currently, `PricingCategory MUST be "Committed" when [CommitmentDiscountId](#commitmentdiscountid) is not null`. Should this be changed to `Standard` for `Purchase` rows where the `CommitmentDiscountId` is the `ResourceId`? 3. With commitment/negotiated discount definitions altered, is it clear that current/planned `CommitmentDiscount*` columns are relevant for commitment discounts and *not* negotiated discounts? ## UPDATE (8/21/24) 1. Includes a recurring purchase for each charge period of the term for No/Partial Upfront commitments - No Upfront Purchase - has all units for the charge period - Partial Upfront Purchase - has 1/2 of the units for each charge period 2. Reverts changing guidance around these `{List,Contracted}{Cost,UnitPrice}` and `Pricing{Quantity,Unit}` columns. 3. Adds additional guidance commitment discount purchase is one-time vs. recurring 4. Adds additional phrasing to differentiate commitment vs negotiated discounts in each CommitmentDiscount* column. 5. Removes edit to resource name to further minimize pr size (for now) ## Update (8/22/24) 1. Changes to the ResourceId column have been reverted (no clause for ResourceId to be null with an unused commitment discount) ## Update (8/31/24) Given that this pr was not fully approved on 8/30, and there was considerable feedback (but less time) to merge `CommitmentDiscountConsumedQuantity` and `CommitmentDiscountPurchasedQuantity` into 1 column, I've gone ahead with this change to form column: `CommitmentDiscountQuantity`. Practitioners can stil filter to purchases and committed usage like: - Purchases: `ChargeCategory = 'Purchase' AND CommitmentDiscountId IS NOT NULL` - Committed Usage (Used): `ChargeCategory = 'Usage' AND CommitmentDiscountStatus = 'Used' AND CommitmentDiscountId IS NOT NULL` - Committed Usage (Unused): `ChargeCategory = 'Usage' AND CommitmentDiscountStatus = 'Unused' AND CommitmentDiscountId IS NOT NULL`. ## Update (9/3/24) - Added a brief paragraph around size-flexibility within `CommitmentDiscountQuantity` - Added additional glossary terms: `size-flexibility`, `instance-family`, `instance-type`, `instance-type-ratio`. - `instance-type-ratio` is the proposal for a generic, "FOCUS" term for `normalization factor` (AWS), or `size flexibility ratio` (Azure) This change is meant to reduce the number of proposed columns *without* changing *any* (meaningful) intent of the previous versions with 2 quantity columns. The last commit to this pr encapsulates this entire change and can be backed out if the group does not approve of this iteration. ## Update (9/10/24) - Further generalize "size-flexibility" as "commitment flexibility" and tie to provider requirements - Further generalize unit suggestions # Sample Data https://docs.google.com/spreadsheets/d/1AYDPZ4rl90PPEbyQJUaGCUSwZ4s_sfy-8sO2KyNq0aM/edit?pli=1&gid=1976106562#gid=1976106562 # Normative Text (original version, adopted into pr) https://docs.google.com/spreadsheets/d/1AYDPZ4rl90PPEbyQJUaGCUSwZ4s_sfy-8sO2KyNq0aM/edit?pli=1&gid=464941124#gid=464941124 --------- Co-authored-by: Irena Jurica <[email protected]> Co-authored-by: Udam Dewaraja <[email protected]> Co-authored-by: Graham <[email protected]> Co-authored-by: Larry Advey <[email protected]> Co-authored-by: Michael Flanakin <[email protected]>

ijurica · 2024-10-01T23:13:21Z

This issue is addressed in a separate PR and this PR can be closed.

shawnalpay · 2024-10-09T02:55:35Z

Closing per @ijurica 's comment above that this was addressed in a separate PR.

FOCUS #493: ConsumedUnit and ConsumedQuantity spec update - initial v…

89c6caa

…ersion

ijurica requested a review from a team as a code owner July 12, 2024 14:58

ijurica linked an issue Jul 12, 2024 that may be closed by this pull request

ConsumedQuantity and ConsumedUnit in case of 'Unused' commitment #492

Closed

ijurica changed the title ~~FOCUS #493: ConsumedQuantity and ConsumedUnit update - addressing Unused usage~~ FOCUS #493: ConsumedQuantity and ConsumedUnit and Unused commitment Jul 12, 2024

jpradocueva changed the title ~~FOCUS #493: ConsumedQuantity and ConsumedUnit and Unused commitment~~ FOCUS #492: ConsumedQuantity and ConsumedUnit and Unused commitment Jul 12, 2024

FOCUS #492: ConsumedUnit and ConsumedQuantity spec update - up for di…

d329e14

…scussion

jpradocueva added this to the v1.1 milestone Jul 12, 2024

jpradocueva mentioned this pull request Jul 19, 2024

ConsumedQuantity and ConsumedUnit in case of 'Unused' commitment #492

Closed

cnharris10 mentioned this pull request Aug 7, 2024

FOCUS #319: Track (sometimes differing) commitment burndown units separately from consumed quantity/unit columns #400

Merged

jpradocueva added the P1 label Aug 22, 2024

shawnalpay reviewed Sep 3, 2024

View reviewed changes

flanakin reviewed Sep 5, 2024

View reviewed changes

shawnalpay closed this Oct 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FOCUS #492: ConsumedQuantity and ConsumedUnit and Unused commitment #507

FOCUS #492: ConsumedQuantity and ConsumedUnit and Unused commitment #507

ijurica commented Jul 12, 2024

ijurica commented Jul 12, 2024

ahullah commented Jul 12, 2024 •

edited

Loading

ijurica commented Jul 12, 2024

cnharris10 commented Jul 12, 2024 •

edited

Loading

jpradocueva commented Jul 12, 2024

ijurica commented Jul 18, 2024

ijurica commented Jul 19, 2024

jpradocueva commented Jul 19, 2024

flanakin commented Aug 7, 2024

shawnalpay Sep 3, 2024

flanakin Sep 5, 2024

flanakin Sep 5, 2024

flanakin Sep 5, 2024

flanakin Sep 5, 2024

ijurica commented Oct 1, 2024

shawnalpay commented Oct 9, 2024


		## ConsumedQuantity and ConsumedUnit normatives overview

		\| ChargeCategory \| ChargeClass \| CommitmentStatus \| ConsumedQuantity \| ConsumedUnit \|


		The ConsumedQuantity column MUST NOT be used to determine values related to any pricing or cost metrics.


	The ConsumedQuantity column MUST NOT be used to determine values related to any pricing or cost metrics.
	* ConsumedQuantity MUST NOT be used to determine values related to any pricing or cost metrics.


		The ConsumedUnit column MUST NOT be used to determine values related to any pricing or cost metrics.


	The ConsumedUnit column MUST NOT be used to determine values related to any pricing or cost metrics.
	* ConsumedUnit MUST NOT be used to determine values related to any pricing or cost metrics.

FOCUS #492: ConsumedQuantity and ConsumedUnit and Unused commitment #507

FOCUS #492: ConsumedQuantity and ConsumedUnit and Unused commitment #507

Conversation

ijurica commented Jul 12, 2024

ijurica commented Jul 12, 2024

ahullah commented Jul 12, 2024 • edited Loading

ijurica commented Jul 12, 2024

cnharris10 commented Jul 12, 2024 • edited Loading

jpradocueva commented Jul 12, 2024

Action items, TF-3, July 12:

ijurica commented Jul 18, 2024

ijurica commented Jul 19, 2024

jpradocueva commented Jul 19, 2024

Action Item from TF-3, July 19 call:

flanakin commented Aug 7, 2024

shawnalpay Sep 3, 2024

Choose a reason for hiding this comment

flanakin Sep 5, 2024

Choose a reason for hiding this comment

flanakin Sep 5, 2024

Choose a reason for hiding this comment

flanakin Sep 5, 2024

Choose a reason for hiding this comment

flanakin Sep 5, 2024

Choose a reason for hiding this comment

ijurica commented Oct 1, 2024

shawnalpay commented Oct 9, 2024

ahullah commented Jul 12, 2024 •

edited

Loading

cnharris10 commented Jul 12, 2024 •

edited

Loading