diff --git a/enhancements/OSAC-3145-metering-networking/prd.md b/enhancements/OSAC-3145-metering-networking/prd.md index baf1f1778..ecce3179c 100644 --- a/enhancements/OSAC-3145-metering-networking/prd.md +++ b/enhancements/OSAC-3145-metering-networking/prd.md @@ -13,42 +13,45 @@ Terms defined in the [Part 1 PRD](/enhancements/metering-and-usage-tracking/prd. | Term | Definition | |------|-----------| | **Allocation metering** | Metering that runs from the point a resource is allocated until deletion, regardless of whether the resource is actively in use. Reflects the provider's physical capacity reservation. | -| **Network class** | A provider-defined network backend configuration that determines VirtualNetwork behavior and metering classification. | ## 1. Problem Statement -OSAC provisions networking resources — virtual networks, subnets, security groups, external IPs, NAT gateways — but has no mechanism to track their consumption over time. These resources consume provider capacity from the moment they are provisioned until deletion, regardless of whether they are actively carrying traffic. An external IP consumes address pool space whether it is attached to a resource or not — the provider's pool is finite and each allocation reduces availability. A VirtualNetwork consumes backend network configuration and VLAN allocation from creation. +OSAC provisions ExternalIPs and NAT Gateways that consume scarce provider infrastructure from allocation until deletion, but has no mechanism to report that consumption to billing. An ExternalIP consumes finite address pool space whether it is attached to a resource or not — the provider's pool is finite and each allocation reduces availability. A NAT Gateway consumes dedicated gateway capacity for as long as it exists. Metering exists to supply billing with usage data for resources that can incur cost — not to enforce quota, and not to inventory every networking object a tenant holds. -Without metering for these resources, Cloud Provider Admins have no usage data to account for the networking infrastructure tenants hold, and Tenant Admins have no visibility into their networking footprint across projects. +VirtualNetworks, Subnets, and SecurityGroups are configuration metadata that will not incur cost — they are free across all surveyed hyperscalers and GPU/AI clouds, none of which meter them on an allocation basis — so metering does not report them. + +Without metering for the billable networking resources, Cloud Provider Admins have no usage data to account for the scarce network infrastructure tenants hold, and Tenant Admins have no visibility into their billable networking footprint across projects. ## 2. In Scope ### 2.1 Services -Networking resources are service-agnostic — a VirtualNetwork or Subnet is metered regardless of which service consumes it. Attachment resources vary by target type. +Metered networking resources are service-agnostic — an ExternalIP or NATGateway is metered regardless of which service (VMaaS, CaaS, BMaaS) consumes it. | Resource | VMaaS | CaaS | BMaaS | |----------|-------|------|-------| -| VirtualNetwork | Yes | Yes | Yes | -| Subnet | Yes | Yes | Yes | -| SecurityGroup | Yes | Yes | Yes | | NATGateway | Yes | Yes | Yes | | ExternalIP | Yes | Yes | Yes | ExternalIP resources support all three services and can be attached to ComputeInstances, Clusters, and BareMetalInstances. Attachment status is tracked as a queryable dimension on the ExternalIP meter, not as a separately metered resource. +VirtualNetwork, Subnet, and SecurityGroup are available on all three services but are not metered — they are configuration metadata that will not incur cost, so metering does not report them. + ### 2.2 Capabilities -- Networking resource allocation metering — metering for VirtualNetworks, Subnets, SecurityGroups, ExternalIPs, and NATGateways from READY/ALLOCATED state to deletion +- Billing-bound reporting — metering reports only networking resources that can incur cost; it is not a quota feed and not a complete inventory of the networking objects a tenant or user holds +- Networking resource allocation metering — metering for ExternalIPs and NATGateways from READY/ALLOCATED state to deletion - Unattached IP metering — ExternalIPs generate usage data regardless of attachment status, with attachment status as a queryable dimension -- Parent-child attribution — extending [Part 1](/enhancements/metering-and-usage-tracking/prd.md) CAP-11 and CAP-12 so that networking resources attached to a parent resource can be attributed to it in a unified usage view: ExternalIPs to ComputeInstances, Clusters, and BareMetalInstances, and Subnets to any resource connected via network attachments +- Parent-child attribution — extending [Part 1](/enhancements/metering-and-usage-tracking/prd.md) CAP-11 and CAP-12 so that ExternalIPs attached to a parent resource can be attributed to it in a unified usage view: ExternalIPs to ComputeInstances, Clusters, and BareMetalInstances ## 3. Out of Scope -- BMaaS compute metering — tracked separately ([OSAC-2506](https://redhat.atlassian.net/browse/OSAC-2506)); networking resources consumed by BMaaS (VirtualNetworks, Subnets, ExternalIPs, etc.) are in scope here +- Metering of VirtualNetwork, Subnet, and SecurityGroup — these are configuration metadata that will not incur cost (free across all surveyed hyperscalers and GPU/AI clouds); metering does not report them (per PR #159 review, [comment 5204380439](https://github.com/osac-project/enhancement-proposals/pull/159#issuecomment-5204380439)) +- Quota enforcement and a complete inventory of the networking resources a tenant or user holds — these are not purposes of metering +- BMaaS compute metering — tracked separately ([OSAC-2506](https://redhat.atlassian.net/browse/OSAC-2506)); ExternalIPs and NATGateways consumed by BMaaS are in scope here - Storage metering — tracked separately ([OSAC-3141](https://redhat.atlassian.net/browse/OSAC-3141)) - Network bandwidth metering (ingress/egress traffic) — tracked separately ([OSAC-3149](https://redhat.atlassian.net/browse/OSAC-3149)) -- Costing, billing, quota enforcement, and budget alerts — deferred to a separate PRD +- Costing, billing, rate schedules, invoicing, and budget alerts — deferred to a separate billing PRD; this PRD supplies the usage data that billing consumes - UI for viewing networking usage — metering data is consumed by the billing system, which provides the user-facing usage views - Workload-level metering inside tenant environments @@ -56,16 +59,15 @@ ExternalIP resources support all three services and can be attached to ComputeIn ### Cloud Provider Admin -- As a Cloud Provider Admin, I want networking resource usage data across all tenants to be available broken down by resource type (VirtualNetwork, ExternalIP, NATGateway), so that downstream systems can track the network infrastructure each tenant consumes. +- As a Cloud Provider Admin, I want networking resource usage data across all tenants to be available broken down by resource type (ExternalIP, NATGateway), so that downstream systems can track the scarce network infrastructure each tenant consumes. ### Cloud Infrastructure Admin -- As a Cloud Infrastructure Admin, I want VirtualNetwork usage to be automatically grouped by the network classes I have configured in OSAC, so that different network backends (e.g., high-performance DPDK, standard OVN) are tracked as distinct metering categories — without requiring a separate registration step in the metering system. -- As a Cloud Infrastructure Admin, I want to add meters for new networking resource types (e.g., LoadBalancer, VPN Gateway) via configuration without redeployment, extending Part 1 CAP-6 to networking resources. +- As a Cloud Infrastructure Admin, I want to add meters for new networking resource types that consume scarce infrastructure (e.g., LoadBalancer, VPN Gateway) via configuration without redeployment, extending Part 1 CAP-6 to networking resources. ### Tenant Admin -- As a Tenant Admin, I want my organization's networking resource usage data to be available broken down by project, including the count and duration of VirtualNetworks, ExternalIPs, and NATGateways, so that downstream systems can attribute networking consumption to the teams that provisioned them. +- As a Tenant Admin, I want my organization's networking resource usage data to be available broken down by project, including the count and duration of ExternalIPs and NATGateways, so that downstream systems can attribute networking consumption to the teams that provisioned them. ### Tenant User @@ -75,8 +77,8 @@ ExternalIP resources support all three services and can be attached to ComputeIn ### 5.1 Networking Resource Allocation Metering -- **CAP-1:** Tenant-facing networking resources (VirtualNetwork, Subnet, SecurityGroup, ExternalIP, NATGateway) are metered on an allocation basis. Usage accrues from the point the resource reaches READY or ALLOCATED state until deletion. -- **CAP-2:** Networking usage is queryable by resource type, network class (for VirtualNetworks), IP family (IPv4/IPv6 for IP resources), region, tenant, and project. +- **CAP-1:** Billable networking resources (ExternalIP, NATGateway) are metered on an allocation basis. Usage accrues from the point the resource reaches READY or ALLOCATED state until deletion. +- **CAP-2:** Networking usage is queryable by resource type, IP family (IPv4/IPv6 for ExternalIP), region, tenant, and project. ### 5.2 Unattached IP Metering @@ -90,22 +92,20 @@ ExternalIP resources support all three services and can be attached to ComputeIn This section defines the metering units and measurement approach for networking resources, extending the usage measurement model from [Part 1](/enhancements/metering-and-usage-tracking/prd.md). Downstream systems (cost management, billing) consume this usage data and apply their own pricing — rate schedules are outside the scope of metering. -Each networking resource type has a flat allocation meter. Usage is queryable by resource type, region, tenant, and project; VirtualNetworks additionally use network class; ExternalIPs additionally use IP family and attachment status (see CAP-2 and CAP-3). +Each metered networking resource type has a flat allocation meter. Usage is queryable by resource type, region, tenant, and project; ExternalIPs additionally use IP family and attachment status (see CAP-2 and CAP-3). | Resource | Meter | Unit | Example (30 days) | |----------|-------|------|-------------------| -| VirtualNetwork | resource-seconds | seconds of allocation | 2,592,000 resource-seconds | -| Subnet | resource-seconds | seconds of allocation | 2,592,000 resource-seconds | | ExternalIP (IPv4) | resource-seconds | seconds of allocation | 2,592,000 resource-seconds | | NATGateway | resource-seconds | seconds of allocation | 2,592,000 resource-seconds | -| SecurityGroup | resource-seconds | seconds of allocation | 2,592,000 resource-seconds | ## 7. Acceptance Criteria -- [ ] Each tenant-facing networking resource (VirtualNetwork, Subnet, SecurityGroup, ExternalIP, NATGateway) generates allocation usage data from READY/ALLOCATED state to deletion +- [ ] Each billable networking resource (ExternalIP, NATGateway) generates allocation usage data from READY/ALLOCATED state to deletion - [ ] An allocated-but-unattached ExternalIP generates usage data -- [ ] Networking usage can be broken down by resource type, region, tenant, and project; VirtualNetworks additionally expose network class; IP resources expose IP family; ExternalIPs expose attachment status -- [ ] Networking resources attached to a parent resource (ExternalIPs to ComputeInstances/Clusters/BareMetalInstances, Subnets via network attachments) can be attributed to the parent in a unified usage view +- [ ] VirtualNetwork, Subnet, and SecurityGroup generate no metering usage data +- [ ] Networking usage can be broken down by resource type, region, tenant, and project; ExternalIPs additionally expose IP family and attachment status +- [ ] ExternalIPs attached to a parent resource (ComputeInstances/Clusters/BareMetalInstances) can be attributed to the parent in a unified usage view - [ ] Networking usage data is available after deploying the metering update without provisioning additional infrastructure - [ ] Networking usage data maintains per-second granularity, deduplication, and retention consistent with Part 1 metering @@ -127,10 +127,10 @@ Each networking resource type has a flat allocation meter. Usage is queryable by ## 11. Open Questions -### 11.1 Should VirtualNetwork metering start at PENDING or READY? +### 11.1 Should allocation metering start at PENDING or READY? - **Owner:** OSAC platform team -- **Impact:** CAP-1. The current model starts metering at READY/ALLOCATED because that is when the resource is usable by the tenant. However, PENDING resources may already consume backend infrastructure (network configuration, VLAN allocation). Starting at PENDING aligns with the BMaaS allocation model (metering from provisioning start). Starting at READY aligns with what the tenant can observe and use. This applies to all networking resources with a PENDING-to-READY transition. +- **Impact:** CAP-1. The current model starts metering at READY/ALLOCATED because that is when the resource is usable by the tenant. However, a resource may already consume scarce provider capacity while PENDING (e.g., an ExternalIP reserved from the pool before it becomes attachable). Starting at PENDING aligns with the BMaaS allocation model (metering from provisioning start). Starting at READY aligns with what the tenant can observe and use. This applies to all metered networking resources with a PENDING-to-READY transition. ## Related PRDs @@ -145,8 +145,11 @@ This PRD is part of the Metering Part 2 family: ## Provenance -Committed: commit @ prd 0.7.1 - b8b3f86, workspace prd/OSAC-3145 @ 2c5bc7d (50 behind origin/main, dirty) +Authored: respond @ prd 0.6.3 - 6ec8c11, workspace main @ 78853cd +Final: revise @ prd 0.8.0 - 7efcedb, workspace HEAD @ 6e8f396 + +> Context changed between respond and revise. -> Authoring phases not recorded this session (commit-time snapshot only). +> This document's phase history does not include an initial /draft — structure was not verified against the template from origin. - +