OSAC-3145: scope networking metering to ExternalIP and NATGateway only

[masayag]

Summary

Corrects the metering scope of the Part 2c Networking PRD. The merged version (#159, merge 3d09b39) meters VirtualNetwork, Subnet, SecurityGroup, ExternalIP, and NATGateway uniformly on an allocation basis. This PR narrows metering to the two resources that actually consume scarce provider infrastructure — ExternalIP and NATGateway — and explicitly moves VirtualNetwork, Subnet, and SecurityGroup to Out of Scope.

Why

Review comment 5204380439 on #159 established, via a market survey across hyperscalers and GPU/AI clouds, that virtual networks, subnets, and security groups are free everywhere and are never metered on an allocation basis — only scarce-infrastructure resources (public IPv4 / ExternalIP, NAT Gateways) are. That feedback arrived before #159 merged but was never applied to the merged document, so the live PRD meters resources that should be free. This PR closes that gap.

Changes

• Services table (§2.1), capabilities (§2.2), CAP-1 (§5.1), usage measurement model (§6), and acceptance criteria (§7): removed VirtualNetwork, Subnet, SecurityGroup
• Removed the network-class metering dimension (CAP-2, §6 intro, §7) and the Network class glossary term
• Removed the VirtualNetwork network-class user story and the Subnet parent-child attribution clause
• Reframed Open Question 11.1 from VirtualNetwork PENDING/READY to allocation metering generally
• Added an explicit Out-of-Scope entry plus a negative acceptance criterion asserting VirtualNetwork/Subnet/SecurityGroup generate no usage data

Metering of ExternalIP (including unattached-IP metering and attachment as a queryable dimension) and NATGateway is unchanged.

Notes

• Corrects OSAC-3145: PRD: Metering for Networking Resources #159 (already merged), so this lands as a new PR rather than an update to that PR.
• Structure was kept as-is (CAP-N format) for a minimal, reviewable diff; converting to the current OSAC PRD template is deferred.

🤖 Generated with Claude Code

[openshift-ci-robot]

@masayag: This pull request references OSAC-3145 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature to target the "5.1.0" version, but no target version was set.

Details

In response to this:

Summary

Corrects the metering scope of the Part 2c Networking PRD. The merged version (#159, merge 3d09b39) meters VirtualNetwork, Subnet, SecurityGroup, ExternalIP, and NATGateway uniformly on an allocation basis. This PR narrows metering to the two resources that actually consume scarce provider infrastructure — ExternalIP and NATGateway — and explicitly moves VirtualNetwork, Subnet, and SecurityGroup to Out of Scope.

Why

Review comment 5204380439 on #159 established, via a market survey across hyperscalers and GPU/AI clouds, that virtual networks, subnets, and security groups are free everywhere and are never metered on an allocation basis — only scarce-infrastructure resources (public IPv4 / ExternalIP, NAT Gateways) are. That feedback arrived before #159 merged but was never applied to the merged document, so the live PRD meters resources that should be free. This PR closes that gap.

Changes

• Services table (§2.1), capabilities (§2.2), CAP-1 (§5.1), usage measurement model (§6), and acceptance criteria (§7): removed VirtualNetwork, Subnet, SecurityGroup
• Removed the network-class metering dimension (CAP-2, §6 intro, §7) and the Network class glossary term
• Removed the VirtualNetwork network-class user story and the Subnet parent-child attribution clause
• Reframed Open Question 11.1 from VirtualNetwork PENDING/READY to allocation metering generally
• Added an explicit Out-of-Scope entry plus a negative acceptance criterion asserting VirtualNetwork/Subnet/SecurityGroup generate no usage data

Metering of ExternalIP (including unattached-IP metering and attachment as a queryable dimension) and NATGateway is unchanged.

Notes

• Corrects OSAC-3145: PRD: Metering for Networking Resources #159 (already merged), so this lands as a new PR rather than an update to that PR.
• Structure was kept as-is (CAP-N format) for a minimal, reviewable diff; converting to the current OSAC PRD template is deferred.

🤖 Generated with Claude Code

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[github-actions]

AI EP Review: EP-224

Score: 9/10 | Verdict: PASS

Criterion	Score	Notes
WHAT (clear need)	2/2	Clear user-facing capability: allocation metering for ExternalIP and NATGateway, with unattached IP tracking and parent-child attribution. All four canonical personas (Cloud Provider Admin, Cloud Infrastructure Admin, Tenant Admin, Tenant User) have dedicated headings with user stories. Services (VMaaS, CaaS, BMaaS) are identified with a scope table. The narrowing from five resource types to two billable ones is well-scoped and clearly stated.
WHY (justification)	2/2	Concrete justification grounded in provider resource scarcity: ExternalIPs consume finite address pool space, NATGateways consume dedicated gateway capacity, and both persist from allocation until deletion. The exclusion of VirtualNetwork/Subnet/SecurityGroup is backed by market evidence ('free across all surveyed hyperscalers and GPU/AI clouds'). Clear causal chain: no metering → no billing data → providers cannot account for scarce infrastructure tenants hold.
User-Facing Focus	2/2	No design leakage. The PRD describes user-observable outcomes — resource states (READY/ALLOCATED) are user-visible API states, not internal implementation details. No controllers, reconcilers, playbooks, finalizers, or internal conditions are mentioned. The revision actually removed previous design leakage ('backend network configuration and VLAN allocation' from the problem statement). Platform vocabulary (OVN, services) is used appropriately per the rubric's allowlist.
Right-Sized	1/2	The scope is coherent — ExternalIP metering, NATGateway metering, unattached IP tracking, and parent-child attribution are interdependent capabilities that cannot ship independently. However, the exclusion rationale ('configuration metadata that will not incur cost') is restated nearly verbatim across four locations: Problem Statement, Services (2.1), Capabilities (2.2 'billing-bound reporting'), and Out of Scope (3). The rubric's score-2 bar requires 'states its scope once, without restatement.' Each instance serves a different template section, but the phrasing is close enough to read as padding rather than necessary structural completeness.
Testability	2/2	Every acceptance criterion is verifiable by a PM/QA using the product: create ExternalIP/NATGateway and verify usage data accrues; allocate an unattached ExternalIP and verify data appears; create VirtualNetwork/Subnet/SecurityGroup and verify no metering data (negative AC); query usage by resource type, region, tenant, project, IP family, attachment status; attach ExternalIP to ComputeInstance and verify parent attribution. The negative acceptance criterion for excluded resources is a strong addition.

Verdict: Well-scoped metering PRD with clear billable-resource focus, concrete market-evidence justification, and fully testable requirements, held back slightly by restating the same exclusion rationale across four sections.

Feedback: The exclusion rationale for VirtualNetwork/Subnet/SecurityGroup ('configuration metadata that will not incur cost, free across all surveyed hyperscalers') appears nearly verbatim in the Problem Statement, Services (2.1), Capabilities (2.2), and Out of Scope (3) — state the full rationale once in the Problem Statement, then use a short back-reference in other sections (e.g., 'not metered — see §1'). This would tighten the document without losing clarity. The negative acceptance criterion confirming excluded resources generate no data is a strong addition that makes the scoping decision testable.

Critical (0)

None.

Important (1)

1. Exclusion rationale restated four times: the phrase 'configuration metadata that will not incur cost' (or close paraphrase) appears in §1 Problem Statement, §2.1 Services, §2.2 Capabilities ('billing-bound reporting — metering reports only networking resources that can incur cost'), and §3 Out of Scope. State the full justification once and back-reference it elsewhere to meet the Right-Sized 'states its scope once' bar.

Suggestions (2)

1. The Capabilities bullet 'Billing-bound reporting — metering reports only networking resources that can incur cost; it is not a quota feed and not a complete inventory' reads more like a design principle than a capability a user exercises. Consider folding this framing into the Problem Statement or removing it, and keeping §2.2 focused on deliverable capabilities.
2. Open Question 11.1 was broadened from 'VirtualNetwork' to 'allocation metering' generically, which is cleaner — but the example still only names ExternalIP. Adding a NATGateway example would confirm the question applies to both metered resource types.

---

Review cost

Model: claude-opus-4-6
Cost: $0.5594
Tokens: 938 in / 6.8k out
Cache: 156.4k read
Active time: 2m 34s
API calls: 0

[ronniel1]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: masayag, ronniel1

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [masayag,ronniel1]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment