[scotwells]

A new HTTP proxy whose workload runs in another location can wait up to a minute before the edge can reach it, because the cell only notices that a workload has been put behind a proxy on a once-a-minute pass. This change drops every timer and makes the cell react to the events it was waiting on: the hub's reachability record changing, a published copy being deleted or edited on the hub, the cell's location being delivered, and the hub namespace appearing for a project's reachability record. Failed writes are still retried with the framework's normal backoff, and the cleanup of leftover copies runs once at startup and again whenever the cell's location changes. No new permissions are needed.

Test plan

• Controller test suite passes locally, with new tests for the reachability, hub copy and hub namespace watches
• New end-to-end scenario: a record is published, restored after deletion and withdrawn, each within 10 seconds, against the real cell and hub
• CI lint and e2e suites pass
• After merge, a new cross-location proxy in staging answers faster than the 34s measured after the last fix

Related to datum-cloud/enhancements#884

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[ecv]

Holding. Removing the one-minute resync drops the only retry for several paths where publish returns nil without a requeue, so a slice can stay unpublished, or a hub copy stay missing, until the pod changes or the operator restarts.

• The hub namespace not there yet (vpcendpointslice_writeback.go:182-186) logs and returns nil. A new namespace appearing on the hub is no event for either controller, and the EdgeReachability write swallows the same NotFound (edgereachability_controller.go:101-107), so its create event may never come.
• An unresolved location (:109-111) returns nil, and the startup sweep then no-ops, returns nil and never runs again.
• A hub copy that Karmada or a person deletes or edits is never re-applied, since nothing watches the hub's EndpointSlices. The edge then has no backend for that pod.
• collect reads the copy through the hub cache (:362). A slice deleted before the cache sees its fresh copy leaves the copy orphaned, which the ten-minute sweep used to collect.

Ask: requeue with a delay on those nil returns, or keep a slow periodic republish and sweep as a backstop next to the new watch.

[scotwells]

@ecv thanks, all four were real gaps. We went with watches rather than a timed requeue or a periodic backstop, so every wait is tied to the event it waits on; failed writes still retry through the controller's normal backoff.

• Hub namespace not there yet: the EdgeReachability writer now watches namespaces being created on the hub, so a record skipped for a missing namespace is written as soon as federation makes it. In the cell write-back this case can't happen while a project is live: the cell's project namespace is propagated from the hub namespace, so the hub one always exists first, and a missing one means the project is being torn down. It stays a no-op, which also avoids an infra RBAC change, since the cell's hub identity has no namespace access.
• Unresolved location: the cell watches ServingLocation (when the kind is served). Once the location resolves or changes, it republishes every slice and reruns the sweep.
• Hub copy deleted or edited: the cell watches its own copies on the hub (filtered to its location) and republishes the source slice. Writes are server-side apply, so an unchanged republish writes nothing.
• Orphaned by a stale cache: covered by the same watch. When the cache sees the copy, the event maps back to a source that's gone, and publish collects it.

Controller tests cover the reachability, hub copy and hub namespace paths, and a new e2e scenario against the real cell and hub checks that a record is published, restored after deletion, and withdrawn, each within 10s. The ServingLocation watch has no test of its own yet.

---

Generated by Claude Code

[ecv]

Approve. Each gap from my hold now has an event behind it:

• A hub namespace's creation enqueues its reachability record, whose write then republishes the namespace's slices.
• A ServingLocation arriving or changing republishes everything and sweeps.
• A copy deleted or edited on the hub maps back to its source slice and is put back, or collected when the source is gone.

The hub cache already held EndpointSlices for the copy reads, so the new copy watch adds no informer.

[kevwilliams]

Verified concurrent publishes from the four controllers self-heal through the copy watch, and the e2e's 10s deadlines fail against the old one-minute resync.