From 2f28529daa96e8304eb1f2615b13b80fc36c530e Mon Sep 17 00:00:00 2001 From: Moti Asayag Date: Sun, 26 Jul 2026 12:32:52 +0300 Subject: [PATCH 1/4] OSAC-3149: PRD: Metering for Network Bandwidth Add PRD for network bandwidth metering covering per-tenant ingress/egress GiB transferred with consumption-based metering model dependent on networking vendor integration. Assisted-by: Claude Code Co-Authored-By: Moti Asayag Co-Authored-By: Claude Signed-off-by: Moti Asayag --- .../OSAC-3149-metering-bandwidth/prd.md | 121 ++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 enhancements/OSAC-3149-metering-bandwidth/prd.md diff --git a/enhancements/OSAC-3149-metering-bandwidth/prd.md b/enhancements/OSAC-3149-metering-bandwidth/prd.md new file mode 100644 index 000000000..d4527fac8 --- /dev/null +++ b/enhancements/OSAC-3149-metering-bandwidth/prd.md @@ -0,0 +1,121 @@ +# Metering and Usage Tracking — Part 2d: Network Bandwidth + +| Field | Value | +|-------------|----------------------| +| Author(s) | masayag@redhat.com | +| Jira | [OSAC-3149](https://redhat.atlassian.net/browse/OSAC-3149) | +| Date | 2026-07-26 | + +## Glossary + +Terms defined in the [Part 1 PRD](/enhancements/metering-and-usage-tracking/prd.md) apply here. Additional terms: + +| Term | Definition | +|------|-----------| +| **Bandwidth metering** | Metering of data transferred (ingress/egress) across tenant network boundaries, measured in GiB. | + +## 1. Problem Statement + +OSAC provisions networking infrastructure for tenants but has no mechanism to track network traffic volumes. Data transfer (ingress and egress) consumes provider bandwidth capacity and generates real infrastructure costs — transit fees, peering costs, upstream bandwidth. Unlike resource-based metering where usage is tied to the existence of a resource, bandwidth is a consumption-based meter driven by traffic volume rather than time. + +Without bandwidth metering, Cloud Provider Admins cannot apply data transfer pricing, and Tenant Admins have no visibility into which projects or applications generate the most network traffic. The data source for traffic counters must come from the networking vendor integration (e.g., Netris, OVN-Kubernetes). + +## 2. In Scope + +- Per-tenant bandwidth metering — ingress/egress GiB transferred, broken down by direction +- Vendor integration requirements — the networking vendor must provide per-tenant traffic counters to the metering system +- Project-level bandwidth breakdown — available when the networking vendor's data source supports project attribution + +## 3. Out of Scope + +- BMaaS metering — tracked separately ([OSAC-2506](https://redhat.atlassian.net/browse/OSAC-2506)) +- Storage metering — tracked separately ([OSAC-3141](https://redhat.atlassian.net/browse/OSAC-3141)) +- Networking resource metering (VirtualNetworks, Subnets, PublicIPs, etc.) — tracked separately ([OSAC-3145](https://redhat.atlassian.net/browse/OSAC-3145)) +- Costing, billing, quota enforcement, and budget alerts — deferred to a separate PRD +- Per-application bandwidth metering inside tenant environments +- Bandwidth shaping or rate limiting + +## 4. User Stories + +### Cloud Provider Admin + +- As a Cloud Provider Admin, I want to view network bandwidth usage across all tenants broken down by direction (ingress/egress) and tenant, so that I can apply data transfer pricing. + +### Cloud Infrastructure Admin + +- As a Cloud Infrastructure Admin, I want to enable bandwidth metering by integrating the networking vendor's traffic data source, so that per-tenant ingress/egress usage appears alongside resource-based meters. + +### Tenant Admin + +- As a Tenant Admin, I want to view my organization's network bandwidth usage broken down by direction (ingress/egress) and, when the vendor data source supports it, by project, so that I can identify sources of high data transfer costs. + +### Tenant User + +- As a Tenant User, I want to view bandwidth usage broken down by ingress and egress and, when the vendor data source supports project attribution, by project, so that I can identify applications generating high data transfer volumes. + +## 5. Capabilities + +### 5.1 Bandwidth Metering + +- **CAP-1:** Network bandwidth is metered per tenant as GiB transferred, broken down by direction (ingress/egress). The data source for traffic counters is provided by the networking vendor integration. +- **CAP-2:** Bandwidth usage is queryable by tenant, direction, and time period. Project-level bandwidth breakdown is available only if the networking vendor's data source provides project-level attribution; otherwise bandwidth is queryable at the tenant level only. + +### 5.2 Cross-cutting + +- **CAP-3:** Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure. Bandwidth meters use the same deduplication and retention requirements as Part 1 (CAP-15, CAP-16). + +## 6. Charge Calculation Model + +OSAC provides usage data. The provider applies their own price schedule to generate charges. This section defines the metering units and formulas for bandwidth, extending the charge calculation model from [Part 1](/enhancements/metering-and-usage-tracking/prd.md). + +Bandwidth is a consumption meter. Unlike the resource-based allocation meters in sibling PRDs, it is driven by traffic volume rather than time. + +| Meter | Formula | Example (1 TiB egress) | +|-------|---------|----------------------| +| egress GiB | volume × rate/GiB | 1024 × $0.05/GiB = $51.20 | +| ingress GiB | volume × rate/GiB | 1024 × $0.01/GiB = $10.24 | + +## 7. Acceptance Criteria + +- [ ] Bandwidth usage is recorded per tenant as GiB transferred, broken down by direction (ingress/egress) +- [ ] Bandwidth usage can be broken down by tenant, direction, and time period; project-level breakdown is available when the vendor data source supports project attribution +- [ ] Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure +- [ ] All Part 1 cross-cutting acceptance criteria (deduplication, retention, independent deployment) apply to bandwidth meters + +## 8. Assumptions + +- Part 1 metering infrastructure is deployed and operational. +- Network bandwidth data will be provided by the networking vendor (e.g., Netris, OVN-Kubernetes) via an integration that provides traffic counters to the metering system. + +## 9. Dependencies + +- **Part 1 metering infrastructure:** The metering infrastructure established by [Part 1](/enhancements/metering-and-usage-tracking/prd.md) is a prerequisite. Part 2d extends but does not replace it. +- **Networking vendor integration:** Bandwidth metering depends on a data source for per-tenant traffic counters. The specific vendor API and integration mechanism will be determined during design. + +## 10. Risks + +### 10.1 Bandwidth data source unidentified + +- **Owner:** OSAC platform team / Networking team +- **Mitigation:** No networking vendor has been selected to provide per-tenant ingress/egress traffic counters. Without a data source, bandwidth metering cannot be implemented. Engage Netris and OVN-Kubernetes teams during design to evaluate options. Bandwidth metering may ship after other Part 2 meters if the vendor integration is not ready. + +### 10.2 Part 1 metering infrastructure not yet built + +- **Owner:** OSAC platform team +- **Mitigation:** All Part 2d meters depend on the metering infrastructure (event pipeline, provider adapters) established by Part 1 (OSAC-985). Part 2d implementation cannot begin until Part 1 infrastructure is deployed. + +## 11. Open Questions + +### 11.1 Network bandwidth data source + +- **Owner:** OSAC platform team / Networking team +- **Impact:** CAP-1, CAP-2. Carried forward from Part 1. The networking vendor (Netris, OVN-Kubernetes, or AAP) must provide per-tenant ingress/egress traffic counters. The choice of data source determines how traffic data reaches the metering system. This must be resolved during design. + +## Related PRDs + +This PRD is part of the Metering Part 2 family: + +- **Part 2a: BMaaS** — [OSAC-2506](https://redhat.atlassian.net/browse/OSAC-2506) +- **Part 2b: Storage** — [OSAC-3141](https://redhat.atlassian.net/browse/OSAC-3141) +- **Part 2c: Networking** — [OSAC-3145](https://redhat.atlassian.net/browse/OSAC-3145) +- **Part 2d: Network Bandwidth** — this document (OSAC-3149) From 88063eeb8b11996021dcf6d453ac8d667107ab4d Mon Sep 17 00:00:00 2001 From: Moti Asayag Date: Sun, 26 Jul 2026 14:33:35 +0300 Subject: [PATCH 2/4] OSAC-3149: replace billing terminology with metering language Apply the same terminology cleanup as sibling metering PRDs: fix broken Part 1 links to OSAC-985 renamed path, replace pricing/costing language with metering equivalents, rename "Charge Calculation Model" to "Usage Calculation Model" with pure accumulation rules (no dollar amounts), inline Part 1 cross-cutting ACs, and add UI out-of-scope statement consistent with other metering PRDs. Assisted-by: Claude Code Co-Authored-By: Moti Asayag Co-Authored-By: Claude Signed-off-by: Moti Asayag --- .../OSAC-3149-metering-bandwidth/prd.md | 31 ++++++++++--------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/enhancements/OSAC-3149-metering-bandwidth/prd.md b/enhancements/OSAC-3149-metering-bandwidth/prd.md index d4527fac8..1a570213c 100644 --- a/enhancements/OSAC-3149-metering-bandwidth/prd.md +++ b/enhancements/OSAC-3149-metering-bandwidth/prd.md @@ -8,7 +8,7 @@ ## Glossary -Terms defined in the [Part 1 PRD](/enhancements/metering-and-usage-tracking/prd.md) apply here. Additional terms: +Terms defined in the [Part 1 PRD](/enhancements/OSAC-985-metering-and-usage-tracking/prd.md) apply here. Additional terms: | Term | Definition | |------|-----------| @@ -16,9 +16,9 @@ Terms defined in the [Part 1 PRD](/enhancements/metering-and-usage-tracking/prd. ## 1. Problem Statement -OSAC provisions networking infrastructure for tenants but has no mechanism to track network traffic volumes. Data transfer (ingress and egress) consumes provider bandwidth capacity and generates real infrastructure costs — transit fees, peering costs, upstream bandwidth. Unlike resource-based metering where usage is tied to the existence of a resource, bandwidth is a consumption-based meter driven by traffic volume rather than time. +OSAC provisions networking infrastructure for tenants but has no mechanism to track network traffic volumes. Data transfer (ingress and egress) consumes provider bandwidth capacity — transit links, peering connections, and upstream bandwidth are finite resources. Unlike resource-based metering where usage is tied to the existence of a resource, bandwidth is a consumption-based meter driven by traffic volume rather than time. -Without bandwidth metering, Cloud Provider Admins cannot apply data transfer pricing, and Tenant Admins have no visibility into which projects or applications generate the most network traffic. The data source for traffic counters must come from the networking vendor integration (e.g., Netris, OVN-Kubernetes). +Without bandwidth metering, Cloud Provider Admins have no usage data for data transfer volumes, and Tenant Admins have no visibility into which projects or applications generate the most network traffic. The data source for traffic counters must come from the networking vendor integration (e.g., Netris, OVN-Kubernetes). ## 2. In Scope @@ -33,13 +33,14 @@ Without bandwidth metering, Cloud Provider Admins cannot apply data transfer pri - Networking resource metering (VirtualNetworks, Subnets, PublicIPs, etc.) — tracked separately ([OSAC-3145](https://redhat.atlassian.net/browse/OSAC-3145)) - Costing, billing, quota enforcement, and budget alerts — deferred to a separate PRD - Per-application bandwidth metering inside tenant environments +- UI for viewing bandwidth usage — metering data is consumed by the billing system, which provides the user-facing usage views - Bandwidth shaping or rate limiting ## 4. User Stories ### Cloud Provider Admin -- As a Cloud Provider Admin, I want to view network bandwidth usage across all tenants broken down by direction (ingress/egress) and tenant, so that I can apply data transfer pricing. +- As a Cloud Provider Admin, I want to view network bandwidth usage across all tenants broken down by direction (ingress/egress) and tenant, so that I can account for data transfer volumes per tenant. ### Cloud Infrastructure Admin @@ -47,7 +48,7 @@ Without bandwidth metering, Cloud Provider Admins cannot apply data transfer pri ### Tenant Admin -- As a Tenant Admin, I want to view my organization's network bandwidth usage broken down by direction (ingress/egress) and, when the vendor data source supports it, by project, so that I can identify sources of high data transfer costs. +- As a Tenant Admin, I want to view my organization's network bandwidth usage broken down by direction (ingress/egress) and, when the vendor data source supports it, by project, so that I can identify sources of high data transfer usage. ### Tenant User @@ -64,23 +65,25 @@ Without bandwidth metering, Cloud Provider Admins cannot apply data transfer pri - **CAP-3:** Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure. Bandwidth meters use the same deduplication and retention requirements as Part 1 (CAP-15, CAP-16). -## 6. Charge Calculation Model +## 6. Usage Calculation Model -OSAC provides usage data. The provider applies their own price schedule to generate charges. This section defines the metering units and formulas for bandwidth, extending the charge calculation model from [Part 1](/enhancements/metering-and-usage-tracking/prd.md). +OSAC captures usage data. Downstream systems (billing, quota, analytics) consume this data and apply their own logic. This section defines the metering units and accumulation rules for bandwidth, extending the usage calculation model from [Part 1](/enhancements/OSAC-985-metering-and-usage-tracking/prd.md). Bandwidth is a consumption meter. Unlike the resource-based allocation meters in sibling PRDs, it is driven by traffic volume rather than time. -| Meter | Formula | Example (1 TiB egress) | -|-------|---------|----------------------| -| egress GiB | volume × rate/GiB | 1024 × $0.05/GiB = $51.20 | -| ingress GiB | volume × rate/GiB | 1024 × $0.01/GiB = $10.24 | +| Meter | Scope | Unit | Accumulation | Example | +|-------|-------|------|-------------|---------| +| egress GiB | continuous | GiB | total egress data transferred in period | 1,024 GiB (1 TiB) | +| ingress GiB | continuous | GiB | total ingress data transferred in period | 1,024 GiB (1 TiB) | ## 7. Acceptance Criteria - [ ] Bandwidth usage is recorded per tenant as GiB transferred, broken down by direction (ingress/egress) - [ ] Bandwidth usage can be broken down by tenant, direction, and time period; project-level breakdown is available when the vendor data source supports project attribution - [ ] Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure -- [ ] All Part 1 cross-cutting acceptance criteria (deduplication, retention, independent deployment) apply to bandwidth meters +- [ ] Duplicate bandwidth metering events do not cause double-counting +- [ ] Bandwidth raw events are retained for at least 7 days; aggregated data is retained for at least 13 months +- [ ] Bandwidth metering deployment is independent of existing provisioning workflows ## 8. Assumptions @@ -89,7 +92,7 @@ Bandwidth is a consumption meter. Unlike the resource-based allocation meters in ## 9. Dependencies -- **Part 1 metering infrastructure:** The metering infrastructure established by [Part 1](/enhancements/metering-and-usage-tracking/prd.md) is a prerequisite. Part 2d extends but does not replace it. +- **Part 1 metering infrastructure:** The metering infrastructure established by [Part 1](/enhancements/OSAC-985-metering-and-usage-tracking/prd.md) is a prerequisite. Part 2d extends but does not replace it. - **Networking vendor integration:** Bandwidth metering depends on a data source for per-tenant traffic counters. The specific vendor API and integration mechanism will be determined during design. ## 10. Risks @@ -102,7 +105,7 @@ Bandwidth is a consumption meter. Unlike the resource-based allocation meters in ### 10.2 Part 1 metering infrastructure not yet built - **Owner:** OSAC platform team -- **Mitigation:** All Part 2d meters depend on the metering infrastructure (event pipeline, provider adapters) established by Part 1 (OSAC-985). Part 2d implementation cannot begin until Part 1 infrastructure is deployed. +- **Mitigation:** All Part 2d meters depend on the metering infrastructure (event pipeline, usage store) established by Part 1 (OSAC-985). Part 2d implementation cannot begin until Part 1 infrastructure is deployed. ## 11. Open Questions From 9616d0fa0dafa19a8f91b158534c65321703c9a8 Mon Sep 17 00:00:00 2001 From: Moti Asayag Date: Sun, 26 Jul 2026 14:36:57 +0300 Subject: [PATCH 3/4] OSAC-3149: address reviewer feedback on bandwidth data source risk Clarify Risk 10.1 per avishayt's review comment: the risk is not that no vendor has been selected, but that it has not been confirmed whether the vendors already integrated with OSAC (Netris, OVN-Kubernetes) expose per-tenant traffic counter APIs that OSAC can consume for metering. Assisted-by: Claude Code Co-Authored-By: Moti Asayag Co-Authored-By: Claude Signed-off-by: Moti Asayag --- enhancements/OSAC-3149-metering-bandwidth/prd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/enhancements/OSAC-3149-metering-bandwidth/prd.md b/enhancements/OSAC-3149-metering-bandwidth/prd.md index 1a570213c..2442ce9d6 100644 --- a/enhancements/OSAC-3149-metering-bandwidth/prd.md +++ b/enhancements/OSAC-3149-metering-bandwidth/prd.md @@ -100,7 +100,7 @@ Bandwidth is a consumption meter. Unlike the resource-based allocation meters in ### 10.1 Bandwidth data source unidentified - **Owner:** OSAC platform team / Networking team -- **Mitigation:** No networking vendor has been selected to provide per-tenant ingress/egress traffic counters. Without a data source, bandwidth metering cannot be implemented. Engage Netris and OVN-Kubernetes teams during design to evaluate options. Bandwidth metering may ship after other Part 2 meters if the vendor integration is not ready. +- **Mitigation:** It has not been confirmed whether the networking vendors integrated with OSAC (Netris, OVN-Kubernetes) expose per-tenant ingress/egress traffic counter APIs that OSAC can consume for metering. Without a confirmed data source, bandwidth metering cannot be implemented. The design phase must evaluate which vendor APIs are available and how traffic counter data reaches the metering system. Bandwidth metering may ship after other Part 2 meters if the vendor integration is not ready. ### 10.2 Part 1 metering infrastructure not yet built From 20c26031a77263d9efe0f8ef7498d26436258b18 Mon Sep 17 00:00:00 2001 From: Moti Asayag Date: Sun, 26 Jul 2026 15:27:33 +0300 Subject: [PATCH 4/4] OSAC-3149: reframe internal acceptance criteria as user-observable outcomes Address AI review feedback: rewrite CAP-3 from deployment constraint to user-observable outcome, replace internal acceptance criteria (deduplication, retention windows, deployment independence) with PM-verifiable criteria, and move deployment detail to Assumptions. Assisted-by: Claude Code Co-Authored-By: Moti Asayag Co-Authored-By: Claude Signed-off-by: Moti Asayag --- enhancements/OSAC-3149-metering-bandwidth/prd.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/enhancements/OSAC-3149-metering-bandwidth/prd.md b/enhancements/OSAC-3149-metering-bandwidth/prd.md index 2442ce9d6..a94045c10 100644 --- a/enhancements/OSAC-3149-metering-bandwidth/prd.md +++ b/enhancements/OSAC-3149-metering-bandwidth/prd.md @@ -63,7 +63,7 @@ Without bandwidth metering, Cloud Provider Admins have no usage data for data tr ### 5.2 Cross-cutting -- **CAP-3:** Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure. Bandwidth meters use the same deduplication and retention requirements as Part 1 (CAP-15, CAP-16). +- **CAP-3:** Bandwidth metering is available without requiring changes to existing tenant or cluster workflows. Bandwidth meters use the same accuracy and data-availability guarantees as Part 1 meters (CAP-15, CAP-16). ## 6. Usage Calculation Model @@ -80,14 +80,14 @@ Bandwidth is a consumption meter. Unlike the resource-based allocation meters in - [ ] Bandwidth usage is recorded per tenant as GiB transferred, broken down by direction (ingress/egress) - [ ] Bandwidth usage can be broken down by tenant, direction, and time period; project-level breakdown is available when the vendor data source supports project attribution -- [ ] Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure -- [ ] Duplicate bandwidth metering events do not cause double-counting -- [ ] Bandwidth raw events are retained for at least 7 days; aggregated data is retained for at least 13 months -- [ ] Bandwidth metering deployment is independent of existing provisioning workflows +- [ ] Enabling bandwidth metering does not disrupt existing tenant or cluster provisioning workflows +- [ ] Bandwidth usage totals are accurate — querying the same period twice returns consistent results +- [ ] Historical bandwidth data is available for at least 13 months ## 8. Assumptions - Part 1 metering infrastructure is deployed and operational. +- Bandwidth meters are additive to the Part 1 metering deployment and require no separate infrastructure. - Network bandwidth data will be provided by the networking vendor (e.g., Netris, OVN-Kubernetes) via an integration that provides traffic counters to the metering system. ## 9. Dependencies