Conversation
Edge Envoy access logs record which POP served a request but nothing about the upstream it was proxied to, so an operator debugging a 503 cannot tell what backend the request reached. This adds an optional, immutable, consumer-authored attachedTo reference to NetworkInterfaceClaim, projects it onto the bound NetworkInterface, and carries it forward through the generated EndpointSlice and into the Envoy cluster metadata the extension server programs. The reference is opaque: the networking operator copies apiGroup, kind, and name without importing any consumer type or branching on a kind. Key changes: - add AttachedToRef and attachedTo on the claim and interface specs - project attachedTo from claim to interface on bind, create, and sync - set endpoint targetRef and stamp attached-to slice labels only when every member of a network service agrees on one reference - read the slice labels in the extension server policy index and write upstream_apigroup, upstream_kind, and upstream_name into the datum-gateway cluster filter_metadata Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2 tasks
Contributor
Author
|
Downstream of this API change:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
An edge access log shows which point of presence served a request but nothing about the upstream it was proxied to, so debugging a failing response cannot tell which backend it reached.
This carries an optional, consumer-authored reference to whatever a network interface is attached to, such as a compute instance, from the claim through to the Envoy cluster the edge programs, and the networking layer copies its group, kind, and name without interpreting them.
An operator can then read the upstream's group, kind, and name from the access log next to the point of presence that served the request.
Accuracy is per rule for now: a rule resolving to one attached thing logs it, a rule spanning several logs an empty upstream, and per-endpoint accuracy needs an upstream Envoy Gateway change tracked separately.
Test plan
🤖 Generated with Claude Code