Skip to content

OSAC-3149: PRD: Metering for Network Bandwidth #160

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
openshift-merge-bot merged 4 commits into from
Jul 26, 2026
+124 −0
Merged

OSAC-3149: PRD: Metering for Network Bandwidth #160

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2f28529
OSAC-3149: PRD: Metering for Network Bandwidth
masayag Jul 26, 2026
88063ee
OSAC-3149: replace billing terminology with metering language
masayag Jul 26, 2026
9616d0f
OSAC-3149: address reviewer feedback on bandwidth data source risk
masayag Jul 26, 2026
20c2603
OSAC-3149: reframe internal acceptance criteria as user-observable ou…
masayag Jul 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
124 changes: 124 additions & 0 deletions enhancements/OSAC-3149-metering-bandwidth/prd.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,124 @@
# 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/OSAC-985-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 — 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 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

- 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
- 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 account for data transfer volumes per tenant.

### 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 usage.

### 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 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

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.

@avishayt avishayt Jul 26, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's similar to MaaS (token volume)

@masayag masayag Jul 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly — bandwidth is a consumption meter driven by volume (GiB transferred) rather than time, similar to how MaaS meters token counts. The sibling PRDs (BMaaS, Storage, Networking resources) use allocation meters tied to resource existence duration.


| 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
Comment on lines +81 to +82

@coderabbitai coderabbitai Bot Jul 26, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Specify tenant isolation as an acceptance outcome.

The user stories distinguish provider-wide visibility from tenant-admin and tenant-user visibility, but these criteria do not require tenant-scoped consumers to be prevented from viewing another tenant’s bandwidth data. Add an explicit authorization/isolation outcome.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/OSAC-3149-metering-bandwidth/prd.md` around lines 81 - 82, Add
an explicit acceptance criterion to the bandwidth usage requirements stating
that tenant-admin and tenant-user consumers can access only their own tenant’s
data and cannot view another tenant’s bandwidth usage, while preserving
provider-wide visibility for authorized provider consumers.

- [ ] 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
Comment on lines +81 to +85

@coderabbitai coderabbitai Bot Jul 26, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Carry the Part 1 data-integrity guarantees into acceptance criteria.

“Querying the same period twice returns consistent results” proves repeatability, not accuracy, and does not verify CAP-15/CAP-16. The criteria also omit that retention must be configurable.

Add outcome-focused criteria covering vendor-counter accuracy, no measurement gaps during upgrades, no double-counting from duplicate events, and configurable retention of at least 13 months.

Proposed acceptance-criteria update 
- [ ] Bandwidth usage totals are accurate — querying the same period twice returns consistent results
- [ ] Historical bandwidth data is available for at least 13 months
+ [ ] Bandwidth usage totals accurately reflect the vendor-provided traffic counters, and repeated queries for the same period return consistent results
+ [ ] Upgrades do not lose collected bandwidth data or create gaps for ongoing workloads
+ [ ] Duplicate traffic events do not double-count bandwidth usage
+ [ ] Historical bandwidth data is retained for at least 13 months, with a configurable retention period
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- [ ] 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
- [ ] 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
- [ ] 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
- [ ] Enabling bandwidth metering does not disrupt existing tenant or cluster provisioning workflows
- [ ] Bandwidth usage totals accurately reflect the vendor-provided traffic counters, and repeated queries for the same period return consistent results
- [ ] Upgrades do not lose collected bandwidth data or create gaps for ongoing workloads
- [ ] Duplicate traffic events do not double-count bandwidth usage
- [ ] Historical bandwidth data is retained for at least 13 months, with a configurable retention period
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/OSAC-3149-metering-bandwidth/prd.md` around lines 81 - 85,
Update the bandwidth metering acceptance criteria near the existing accuracy and
historical-data items to explicitly require vendor-counter accuracy, no
measurement gaps during upgrades, and no double-counting of duplicate events.
Replace the fixed 13-month retention wording with configurable retention whose
minimum supported duration is 13 months, while preserving the existing
repeatability and provisioning-workflow criteria.

Source: Learnings


## 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

- **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

### 10.1 Bandwidth data source unidentified

- **Owner:** OSAC platform team / Networking team
- **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

- **Owner:** OSAC platform team
- **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

### 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)
Loading