Add cost service type to service type definitions by pgarciaq · Pull Request #60 · dcm-project/enhancements

pgarciaq · 2026-06-17T23:21:16Z

Summary

Adds the cost service type as a fifth DCM service type alongside vm, container, database, and cluster.

Unlike the four compute-oriented types, cost provisions visibility (metering, overhead distribution, financial tracking) rather than infrastructure.

Changes

Adds cost to the service type enum and lists
Defines the CostSpec schema with:
- target (resource_id, resource_type)
- cost_model (rates, markup, distribution)
- currency
Documents the three-tier model (basic metering → distribution → full cost)

Context

This service type is used by the Cost Management Service Provider enhancement, which was asked to define its service type in a separate PR to the service-type-definitions document (consistent with how other SPs reference existing type definitions rather than defining them inline).

The initial implementation is backed by Red Hat Lightspeed Cost Management (Project Koku).

Test plan

Schema fields are consistent with the CostSpec in the cost-sp enhancement
Service type enum includes all five types
Schema follows the same pattern as vm/container/database/cluster

Made with Cursor

Introduces the `cost` service type as a fifth DCM service type alongside vm, container, database, and cluster. Unlike the four compute-oriented types, cost provisions visibility (metering, overhead distribution, financial tracking) rather than infrastructure. Includes the CostSpec schema with target, cost_model (rates, markup, distribution), and currency fields. Supports three tiers: basic metering, distribution, and full cost. See the Cost Management Service Provider enhancement for the full SP proposal. Signed-off-by: Pau Garcia Quiles <pgarciaq@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

…st type End-to-end proof that the dcm-project/enhancements#60 'cost' serviceType maps onto UDLM, and the first use of the Process entityType in the registry. - family=Resource, entityType=Process (a long-running observational process realized by a cost provider, e.g. Koku) — not infrastructure, not Knowledge - target = a typed `references` relationship to the compute types; the resource id is resolved on the instance, not baked into the type spec - costModel (rates/markup/distribution) + currency = declarative spec data - three-tier model = a real JSON-Schema presence-conditional (E3): tier-3 (rates present) requires currency; tier-1 basic metering passes. Verified with Draft202012Validator. - metered/computed figures = typed Realized outputs (E2: meteredUsage, computedCost, costBreakdown, period...) - 'cost = metering x rate' is prose in computedCost's description only — never an embedded expression (G2); the computation is the provider's act - README + design-notes §4a cross-reference the worked type validate.py: all 7 types + instance valid (0 invalid). Signed-off-by: Chris Roadfeldt <chris@roadfeldt.com>

croadfeldt · 2026-06-18T02:05:15Z

Why: vendor-agnosticism is a core DCM/UDLM requirement — a service type should be implementable by any provider, not just one. This cost definition is at the right layer (a service-type definition, consumed by an SP), so the only ask here is about the data shape.

Rather than define a bespoke cost vocabulary (Koku's 40+ dimensions, Infrastructure/Supplementary), consider conforming the consumable cost data to FOCUS (the FinOps Open Cost & Usage Specification — current 1.4, FinOps Foundation; AWS/Azure/GCP and Koku all emit it) and OpenCost (CNCF) for Kubernetes cost allocation. Express the rate dimensions in FOCUS terms, and map the direct-vs-allocated intent onto FOCUS allocation columns. The rate-card authoring can stay a thin provider offering — rate cards are inherently finance-policy.

Net: any FOCUS-emitting cost provider — not just Koku — can implement the same cost type, and consumers query cost identically regardless of which provider backs it.

The underlying principle: adopt the external standard by reference rather than re-model it, which keeps the contract vendor-neutral and avoids reinventing a spec the ecosystem already maintains.

gabriel-farache · 2026-06-18T13:39:31Z

You may want to add a bullet in the goal section too: https://github.com/pgarciaq/enhancements/blob/92fc0d9cae2b63078ccac810b3d5d217f91e52e2/enhancements/service-type-definitions/service-type-definitions.md#goals

gabriel-farache · 2026-06-18T13:44:50Z

+| Field         | Required | Type   | Description                                          |
+| :------------ | :------- | :----- | :--------------------------------------------------- |
+| resource_id   | Yes      | string | DCM instance ID of the resource to track costs for   |
+| resource_type | No       | string | Type of the target resource (default: _cluster_)     |


why resource_type is not mandatory and why defaulting to cluster? IIUC, this SP will monitor the a resource created by DCM and provide cost related data to the user (and DCM?)
So how is resource_type influencing this? I see nothing about that too

So how is resource_type influencing this? I see nothing about that too

maybe this is out of the scope of this document and it will be for each SP enhancement (eg: #57 ) to define how this field's influence

The possible values (cluster, vm, container) for resource_type is the same as service_type for the instance, no?

that is my guess yes as the cost manager for DCM will look into resources created by DCM but it needs to be explicitly written here IMO

and as #57 is focused on cluster only, I really believe we should remove the default cluster value to avoid any confusiuon

i'm thinking the field names might be confusing and since the cost resource itself targets other resources, maybe target_id and target_type might be better here? And definitely agree, these should be required. And all default values are set in the catalog item and not on the service type level so the doc should give examples instead.

jenniferubah · 2026-06-19T14:43:00Z

+The initial implementation is backed by
+[Red Hat Lightspeed Cost Management](https://github.com/project-koku/koku)
+(Project Koku). See the
+[Cost Management Service Provider enhancement](https://github.com/dcm-project/enhancements/blob/main/enhancements/cost-sp/cost-sp.md)
+for the full proposal.


Is there any need to mention this? This cost type is generic and can be implemented by any cost SP/product

jenniferubah · 2026-06-19T14:58:58Z

+| :--------- | :------- | :----------------------------------- | :--------------------------------------------------- |
+| target     | Yes      | [Target](#cost-target-object)        | The resource to track costs for                      |
+| cost_model | No       | [CostModel](#cost-costmodel-object)  | Rate configuration (absent = basic metering only)    |
+| currency   | No       | string                               | Currency code (default: _USD_)                       |


jenniferubah · 2026-06-19T14:59:39Z

+| :----------- | :------- | :-------------------------------------- | :----------------------------------------------- |
+| rates        | No       | array[[Rate](#cost-rate-object)]        | Tiered rate definitions (absent = distribution only) |
+| markup       | No       | [Markup](#cost-markup-object)           | Markup percentage                                |
+| distribution | No       | string                                  | Distribution method: _cpu_ or _memory_ (default: _cpu_) |


jenniferubah · 2026-06-19T15:06:53Z

+| :-------- | :------- | :----- | :------------------------------------------------------------- |
+| metric    | Yes      | string | Rate metric (e.g., _cpu\_core\_usage\_per\_hour_, _node\_cost\_per\_month_) |
+| cost_type | No       | string | _Infrastructure_ or _Supplementary_ (default: _Infrastructure_) |
+| value     | Yes      | number | Rate value (≥ 0)                                               |


for consistency across the document, this should be integer?

pgarciaq requested review from Fale, croadfeldt, gabriel-farache, gciavarrini, jenniferubah, machacekondra, pkliczewski and ygalblum as code owners June 17, 2026 23:21

croadfeldt mentioned this pull request Jun 18, 2026

Enhancement proposal: Cost Management Service Provider #57

Open

gabriel-farache reviewed Jun 18, 2026

View reviewed changes

jenniferubah reviewed Jun 19, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add cost service type to service type definitions#60

Add cost service type to service type definitions#60
pgarciaq wants to merge 1 commit into
dcm-project:mainfrom
pgarciaq:cost-service-type

pgarciaq commented Jun 17, 2026

Uh oh!

croadfeldt commented Jun 18, 2026

Uh oh!

gabriel-farache Jun 18, 2026

Uh oh!

gabriel-farache Jun 18, 2026

Uh oh!

gabriel-farache Jun 18, 2026

Uh oh!

jenniferubah Jun 18, 2026

Uh oh!

gabriel-farache Jun 19, 2026

Uh oh!

jenniferubah Jun 19, 2026

Uh oh!

jenniferubah Jun 19, 2026 •

edited

Loading

Uh oh!

jenniferubah Jun 19, 2026 •

edited

Loading

Uh oh!

jenniferubah Jun 19, 2026

Uh oh!

jenniferubah Jun 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	\| currency \| No \| string \| Currency code (default: _USD_) \|
	\| currency \| No \| string \| Currency code (e.g: _USD_, _GBP_) \|

	\| distribution \| No \| string \| Distribution method: _cpu_ or _memory_ (default: _cpu_) \|
	\| distribution \| No \| string \| Distribution method: _cpu_ or _memory_ (e.g: _cpu_) \|

Conversation

pgarciaq commented Jun 17, 2026

Summary

Changes

Context

Test plan

Uh oh!

croadfeldt commented Jun 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jenniferubah Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jenniferubah Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jenniferubah Jun 19, 2026 •

edited

Loading

jenniferubah Jun 19, 2026 •

edited

Loading