Repository navigation
fix(router): requeue only the service route policies an event affects - #1373
Merged
Merged
Conversation
Every VPCAttachment, VPC, ServiceEndpoint and producer report event requeued every ServiceRoutePolicy. The controller has one worker and each reconcile reads every attachment, so in a cell with a few dozen policies the queue never drained: each policy was rebuilt only every few seconds, and a new consumer waited a whole pass, up to about 10 s under load, before its route was installed. A workload that resolves a name at start-up timed out until then. Map attachment events, old and new object, to the policies that select the attachment as a consumer or as a producer of their endpoint; endpoint and report events to the policies that route to that endpoint; VPC events to the policies that reference that VPC. Policy, BGPRouter and BGPVRFInstance events still requeue every policy.
A conflict between two translated policies can start or end through an event that now requeues only one of them, such as its producer becoming ready. The reconcile that sees it withdraws the other policy's routes, and nothing restored them until its periodic requeue. Track the conflict set and requeue every policy that entered or left it.
savme
approved these changes
Nov 6, 2026
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
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.
Requested by Scot Schuchert-Wells
Fixes datum-cloud/compute#630. Related: datum-cloud/enhancements#921.
Problem
A newly started instance cannot resolve names for its first few seconds. The node's service route controller installs a new consumer's route only when it next reconciles that consumer's ServiceRoutePolicy. Every VPCAttachment, VPC, ServiceEndpoint and producer report event in the cell requeued every policy. The controller has one worker and each reconcile reads every attachment. With a few dozen policies, the queue never drained and each policy was rebuilt only every few seconds. Measured in a test cell, the queue held about 55 policies at all times, with a median wait of about 5 s and a p99 of about 10 s. A new consumer waited one full pass before its route existed, and lookups to the service address timed out until then.
Change
New mappers in
internal/controller/serviceroute_requeue.go:consumerVPCRef) or whose endpoint selects it as a producer (selector orattachmentRef). A policy the attachment left is requeued too, so it withdraws its route.consumerVPCRefnames it.The router architecture doc describes the mapping.
Testing
consumerVPCReffilteringgo build ./...,go vet,golangci-lint(0 issues) andgo test -racepass in a Linux build container for./internal/controller/,./cmd/galactic-router/,./pkg/serviceplan/and the instrumentation tests.serviceroutepolicyworkqueue depth and wait drop to near zero