test(billing): pin usage subject to project name + fix metering doc#287
test(billing): pin usage subject to project name + fix metering doc#287ecv wants to merge 1 commit into
Conversation
e2e verified — both directionsRan
So the fix makes the billing test pass, and the hardened subject assertion fails against the old VRL — it genuinely catches the attribution regression. Note The fix-branch run is overall red only because of an unrelated test, Control branch deleted (was verification-only). |
scotwells
left a comment
scotwells
left a comment
There was a problem hiding this comment.
We don't attribute projects by UID. It's supposed to be the project name
The billing consumer (milo-os/billing) attributes usage by PROJECT NAME: it strips "projects/" from the CloudEvent subject and matches the remainder against BillingAccountBinding.spec.projectRef.name. The subject must therefore be projects/<project-name>; a subject built from the route_name namespace UID never resolves. The billing e2e previously accepted any single subject carrying the four CloudEvents, so a subject built from the wrong identifier passed undetected. Pin the assertion to projects/<project_name> and guard that project_name differs from the namespace UID, so a UID-based subject regression fails the test. Also correct the HTTP metering enhancement doc, which described project_name as merely a "dimension" — it is the attribution subject. Document the consumer contract (subject -> projectRef.name) so future changes don't repeat the confusion. No VRL behavior change. Refs #286, datum-cloud/infra#3444.
6a0a801 to
11d14c3
Compare
ecv
changed the title
scotwells
left a comment
scotwells
left a comment
There was a problem hiding this comment.
This is leaking a lot of implementation details in the doc. The NSO repo shouldn't know about what the billing repo does internally with usage events because that information may go stale over time.
2 participants
Note
Repurposed after review. An earlier revision changed the VRL to build the subject from the project UID — that was wrong. The billing consumer attributes by project name, so the existing VRL (subject = project name) is correct and is unchanged here. This PR is now test + doc hardening only.
Summary
Attribution for gateway usage runs in the billing consumer (
milo-os/billing,internal/controller/consumer): it stripsprojects/from the CloudEvent subject and matches the remainder againstBillingAccountBinding.spec.projectRef.name. So the subject must beprojects/<project-name>— and the current VRL already does exactly that.Two gaps let a wrong-identifier change (and a months-old misconception) look plausible. This PR closes both:
projects/<project_name>, and guards thatproject_namediffers from the namespace UID so a UID-based regression is actually distinguishable.http-traffic-metering.mdcalledproject_namea "dimension" and framed the namespace UID as the project identity — implying the subject should be the UID. Corrected:project_nameis the attribution subject, with the consumer contract (subject →projectRef.name) now documented.No VRL behavior change.
Test plan
Refs #286, datum-cloud/infra#3444.