RFC #564: Do the topology-parent and topology-source tags win over a new relationship model?

[znerol2]

Moved from #602 so the question can be discussed before any work is scheduled. The original issue is closed and links here.

---

The question

The launcher already records two tags, topology-parent: and topology-source:. Should they stay the authoritative way to record relationships, or should the platform add a new relationship model?

What the plan proposes

• Section 3.1 reads the source and finds the tags are narrower than the discussion assumed. topology-parent: carries a catalog entry key, and topology-source: carries a declared source id. Neither names an instance. The viewer release gets neither tag. NetBox therefore records no instance-to-instance edge.
• Section 3.1 separates three representations of a connection: design intent in git, actuation state written by the switch playbook, and the observed state of the running instance. A switch changes actuation state without changing git, so the declared selection can be stale as a live signal.
• Section 3.1 proposes not inventing a relationship model. It proposes widening the two tags into a design-reference and design-element pair over a larger domain, with the same semantics and no migration.
• Section 3.2 proposes keeping the existing topology parameters as a launch parameter set for one chart, and not growing them into a design representation. A new graph artifact would sit at a different layer, and a compiler step would emit the parameters.
• Section 3.5 adds that one catalog entry produces several service records, so a design element cannot be keyed to a service record.

What would change the answer

• A requirement to record connections between running instances, which the tags do not do today.
• A finding that widening the tags causes migration or naming problems the plan did not foresee.
• A decision to give NetBox a first-class relationship object, which would need an ADR-0037 and ADR-0046 amendment.

Links

• Discussion: https://github.com/orgs/dmfdeploy/discussions/564
• Plan: https://github.com/dmfdeploy/dmfdeploy/blob/main/docs/plans/DMF%20Media%20Workload%20Design%20Canvas%20Plan.md

This is a request for comment. Answering it does not start any work.