You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(operator): scope VPC Link/namespace per-VPC; teardown on ingress removal; prune stale routes
Round-7 review:
- F1 (critical): VPC Link was matched by a hardcoded name ('oab-vpc-link')
with no VPC check. A VPC Link's ENIs live in one VPC and cannot route to
another, so a second bot in a *different* VPC would silently reuse the
first VPC's link and get unreachable integrations. Fixed by naming the
link 'oab-vpc-link-<vpc-id>', scoped per-VPC.
- F2: same collision class for the Cloud Map namespace — matched by
configured name only. Fixed by scoping the actual namespace name to
'<cloudMapNamespace>-<vpc-id>' (the DnsConfig VPC association makes
namespace-per-VPC the correct AWS-native mental model anyway; the
private DNS only resolves inside that VPC).
- F3: apply only ever added ingress resources — editing a manifest to
remove spec.ingress orphaned the per-bot HTTP API + Cloud Map service.
apply now detects 'had ingress before, doesn't now' by comparing
against the previously-stored S3 manifest and calls the same
best-effort ingress::teardown used by .
- F4: ensure_route only ever added routes; renaming/removing a webhook
path left a dead route on the bot's API forever. Added
prune_stale_routes, which deletes any route on the bot's API whose key
isn't in the current ingress.paths after ensuring the desired ones.
Added 3 unit tests (vpc_link_name, vpc_scoped_namespace) — 13 total.
Updated README + module doc to describe per-VPC scoping and the new
apply-time teardown/pruning behavior.
Verified: build, clippy --all-targets -D warnings, cargo test (13 passed).
Copy file name to clipboardExpand all lines: operator/README.md
+19-11Lines changed: 19 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -241,9 +241,9 @@ spec:
241
241
242
242
On `apply` this reconciles (idempotently, reused by name):
243
243
244
-
1. **Cloud Map** private DNS namespace + a per-service **SRV** record (carries the container port; a plain A record does not work as a VPC-Link integration target)
244
+
1. **Cloud Map** private DNS namespace (`<cloudMapNamespace>-<vpc-id>`, shared per-VPC) + a per-service **SRV** record (carries the container port; a plain A record does not work as a VPC-Link integration target)
245
245
2. **ECS service registry** wiring (attached at service creation)
246
-
3. **VPC Link** (shared `oab-vpc-link`), waits until `AVAILABLE`
246
+
3. **VPC Link** (`oab-vpc-link-<vpc-id>`, shared per-VPC), waits until `AVAILABLE`
247
247
4. **API Gateway HTTP API** (`oab-webhook-<ns>-<name>`, one per bot) + `HTTP_PROXY` integration over the VPC Link
248
248
5. One **route** per path + a `prod` auto-deploy **stage**
249
249
6. A self-referencing **security-group** inbound rule on `containerPort`
@@ -265,19 +265,27 @@ LINE console:
265
265
> If the service already exists without service discovery, `apply` provisions the
266
266
> ingress resources and prints how to recreate the service so traffic can reach it.
267
267
>
268
-
> **Shared VPC Link:** all ingress-enabled bots in a VPC share one `oab-vpc-link`.
269
-
> A VPC Link's subnets/security groups are fixed at creation and cannot be changed,
270
-
> so every ingress bot in the VPC must use the same `networking.subnets` /
271
-
> `securityGroups` as whichever bot created the link first. `apply` prints a
272
-
> reminder when it reuses an existing link.
268
+
> **Shared per-VPC (not per-account):** all ingress-enabled bots in the *same VPC*
269
+
> share one VPC Link (`oab-vpc-link-<vpc-id>`) and one Cloud Map namespace
270
+
> (`<cloudMapNamespace>-<vpc-id>`) — both are named by VPC ID so bots in different
271
+
> VPCs never collide or reuse each other's link/namespace. A VPC Link's
272
+
> subnets/security groups are fixed at creation and cannot be changed, so every
273
+
> ingress bot in a given VPC must use the same `networking.subnets` /
274
+
> `securityGroups` as whichever bot created that VPC's link first. `apply` prints
0 commit comments