What happened:
The reuse-domain uniqueness check landed in #280 decides whether two pools are served by one master
by intersecting their spec.backends -- that is, by KVCacheBackend OBJECT NAMES. For a MANAGED
backend the object is the master, so the identity holds. For an EXTERNAL one it does not: the object
is a declaration of endpoints, and two differently-named objects may name the same Admin address.
Two pools bound to two such objects therefore write ONE physical tenant ledger while the check
reports no shared backend and admits the duplicate domain -- the last-write-wins quota and cache
collision the check exists to prevent. validateKVCacheBackendExternal validates each object's
endpoints[].address on its own; nothing compares addresses ACROSS objects, so the collision is
admitted at creation, not only through a later address edit.
Found by review of #280. That PR narrowed its refusal message to say the two Bindings' pools NAME
the same backend rather than that they are SERVED BY one master, which makes the check honest about
its own reach -- it does not extend the reach.
What you expected to happen:
Two pools that write the same tenant ledger are refused a shared reuse domain, whether the master
they share is reached through one backend object or two.
How to reproduce it (as minimally and precisely as possible):
Create two KVCacheBackend objects with connection.external naming the same Admin endpoint under
different object names. Bind a pool to each, and claim the same domain.name on both Bindings.
Both are admitted: poolsSharedMasters in pkg/worker/webhooks/worker/kv_cache_pool_binding.go
intersects the two pools' backend name lists and finds nothing in common.
Anything else we need to know?:
Closing this needs a decision before an implementation, which is why it is filed rather than fixed:
- WHAT IS THE IDENTITY. The Admin address alone, the whole endpoint set, or an ID the master
reports. An address is editable and reachable through more than one spelling (host versus IP, a
trailing dot, an explicit default port); a master-reported ID is authoritative but requires the
master to be reachable at admission, which this check does not require today.
- WHAT HAPPENS TO POOLS ALREADY BOUND when an address is edited into a collision. Refusing the edit
and letting it through are both defensible, and the choice decides whether the webhook has to
watch KVCacheBackend updates at all.
WHAT DOES NOT CLOSE THIS: refusing two external objects whose Admin addresses are byte-identical.
That catches the copy-paste case and leaves the one a deployment actually produces -- the same
master named by host in one object and by IP in another.
Environment:
Not environment-specific. Requires multi-tenancy enabled and two external backends.
What happened:
The reuse-domain uniqueness check landed in #280 decides whether two pools are served by one master
by intersecting their
spec.backends-- that is, by KVCacheBackend OBJECT NAMES. For a MANAGEDbackend the object is the master, so the identity holds. For an EXTERNAL one it does not: the object
is a declaration of endpoints, and two differently-named objects may name the same Admin address.
Two pools bound to two such objects therefore write ONE physical tenant ledger while the check
reports no shared backend and admits the duplicate domain -- the last-write-wins quota and cache
collision the check exists to prevent.
validateKVCacheBackendExternalvalidates each object'sendpoints[].addresson its own; nothing compares addresses ACROSS objects, so the collision isadmitted at creation, not only through a later address edit.
Found by review of #280. That PR narrowed its refusal message to say the two Bindings' pools NAME
the same backend rather than that they are SERVED BY one master, which makes the check honest about
its own reach -- it does not extend the reach.
What you expected to happen:
Two pools that write the same tenant ledger are refused a shared reuse domain, whether the master
they share is reached through one backend object or two.
How to reproduce it (as minimally and precisely as possible):
Create two KVCacheBackend objects with
connection.externalnaming the same Admin endpoint underdifferent object names. Bind a pool to each, and claim the same
domain.nameon both Bindings.Both are admitted:
poolsSharedMastersinpkg/worker/webhooks/worker/kv_cache_pool_binding.gointersects the two pools' backend name lists and finds nothing in common.
Anything else we need to know?:
Closing this needs a decision before an implementation, which is why it is filed rather than fixed:
reports. An address is editable and reachable through more than one spelling (host versus IP, a
trailing dot, an explicit default port); a master-reported ID is authoritative but requires the
master to be reachable at admission, which this check does not require today.
and letting it through are both defensible, and the choice decides whether the webhook has to
watch KVCacheBackend updates at all.
WHAT DOES NOT CLOSE THIS: refusing two external objects whose Admin addresses are byte-identical.
That catches the copy-paste case and leaves the one a deployment actually produces -- the same
master named by host in one object and by IP in another.
Environment:
Not environment-specific. Requires multi-tenancy enabled and two external backends.