Commit 97bbeff2 authored by Sergio Gimenez's avatar Sergio Gimenez
Browse files

docs(fm): derive a federated zone's UUID from the partner's zone id

Partners name zones with opaque strings while the rest of the platform
addresses zones by UUID, and nothing said where that UUID comes from. FM
derives it: uuid5 over a fixed namespace and "{partner_op_id}:{zone id}".

Re-syncing a partner's catalogue then becomes an upsert with nothing to
reconcile, a restored fm_db keeps the ids OEG and App Providers already
hold, and two FM replicas agree without coordinating. A renamed partner
zone counts as a new zone plus a removal, which is how OPG.04 treats
zoneId anyway.
parent 3d5ad76c
Loading
Loading
Loading
Loading
+9 −0
Changes for fm/persistence-model.md: 9 added lines, 0 removed lines.
Original line number Diff line number Diff line
@@ -225,6 +225,15 @@ Indexes: `idx_routing_rules_type_value` on `(identifier_type, value_range)`, `id

Indexes: `idx_shared_catalogue_partner_direction` on `(partner_op_id, direction)`, `idx_shared_catalogue_resource_type`.

**Identity of a federated zone.** A partner names its zones with opaque strings (`madrid-edge-3`),
while SRM, OEG and App Providers address zones by UUID. FM derives that UUID instead of inventing
one: `uuid5(6518f1ca-ac73-52a4-80f0-7d7645a4018e, "{partner_op_id}:{external_zone_id}")`, where the
namespace is fixed for the platform. The same partner and zone therefore always produce the same
UUID, so re-syncing a partner's catalogue is an upsert with nothing to reconcile, a restored `fm_db`
keeps the ids OEG and App Providers already hold, and two FM replicas agree without coordinating.
Both identifiers live in `resource_data` (`external_zone_id`, `zone_id`). A renamed partner zone is
a new zone plus a removal, which matches OPG.04 treating `zoneId` as the zone's identity.

#### `federation_transactions`

| Column | Type | Constraints | Description |
+4 −0
Changes for fm/requirements-and-design.md: 4 added lines, 0 removed lines.
Original line number Diff line number Diff line
@@ -553,6 +553,10 @@ the partner side, so behaviour doesn't depend on who started the operation.
| `GET` | `/internal/federated-zones/{zone_id}` | Resolve one zone against `shared_resource_catalogues`; `404` if no partner offers it |
| `GET` | `/internal/federated-zones` | Every zone partners currently offer, for SRM's zone listing |

`zone_id` is the platform-side UUID FM derives from the partner's own zone identifier, as
[fm/persistence-model.md](/fm/persistence-model.md) describes under `shared_resource_catalogues`;
FM maps it back to the partner's opaque `zoneId` when it calls them.

Response `200` for one zone (the list returns an array of the same objects):

```json