Open framing: dmfdeploy and the EBU Dynamic Media Facility publications

[znerol2]

Open framing: dmfdeploy and the EBU Dynamic Media Facility publications

This captures open architecture notes from 2026-06-21.

This is intentionally not an ADR, plan, accepted direction, or implementation request. It is a parking place for debate topics that may become RFC material after v0.1.

Scope / Disclaimer

dmfdeploy is an independent open-source experiment. It is not an official EBU project, not an implementation of record, not a reference implementation, and not an attempt to define what the Dynamic Media Facility should mean for the industry.

The official reference point is the EBU Dynamic Media Facility material, especially the published reference-architecture vocabulary around layers, verticals, lifecycle stages, Resource Profiles, Media Exchange, and Media Functions. dmfdeploy is a separate project trying to learn from that vocabulary and test whether a small, reproducible, open-source facility stack can be shaped in a way that is broadly compatible with it.

So in this discussion:

• Dynamic Media Facility / DMF means the external EBU concept, publications, reference architecture, and terminology.
• dmfdeploy means this repository and its component repos.
• Any wording here is exploratory. It should be read as "could this be a useful experiment?"

The current v0.1 commitment also remains unchanged: make the proven single-node/Flypack core stranger-runnable and legible before adding new surface area.

Project context:

• Current thesis: https://github.com/dmfdeploy/dmfdeploy/blob/main/docs/THESIS.md
• EBU vocabulary decision in this repo: https://github.com/dmfdeploy/dmfdeploy/blob/main/docs/decisions/0003-ebu-v2-taxonomy.md
• v0.1 commitments: https://github.com/dmfdeploy/dmfdeploy/blob/main/docs/decisions/architectural-commitments-v1.md
• MXL placement decision in this repo: https://github.com/dmfdeploy/dmfdeploy/blob/main/docs/decisions/0017-mxl-intra-host-data-plane.md

Working framing

One possible guardrail for dmfdeploy is:

Generic infrastructure systems provision substrate. dmfdeploy experiments with giving that substrate media-facility meaning.

This is a guardrail, not a claim of authority. OpenNebula, Proxmox, Kubernetes, Argo, Temporal, AWX, and similar systems already cover large parts of generic compute, VM lifecycle, Kubernetes deployment, or workflow execution. A useful role for dmfdeploy may be to explore the control envelope around media work:

• source-of-truth inventory
• identity and authority chain
• secrets custody
• media-function catalog intent
• lifecycle receipts
• observability derived from NetBox
• Layer 4/5 media semantics such as MXL, NMOS, ST 2110, PTP, licenses, and media-capable hardware

In the EBU vocabulary, generic substrate concerns are mostly concentrated around Layers 1-3. dmfdeploy is exploring what it means to attach media-specific intent and lifecycle semantics across Layers 4-6 and the Orchestration, Control, Monitoring, and Security verticals.

Topic 1: isolation boundary and MXL media nodes

An open question is where dmfdeploy should draw boundaries between:

• same cluster with namespaces
• same physical cluster with virtual clusters
• dedicated node pools
• separate autonomous clusters or media islands

A possible rule of thumb is to decide by failure domain, trust boundary, media determinism, and lifecycle ownership, not only by whether something can technically run on Kubernetes.

Possible framing:

• Trusted platform services may stay in the core cluster.
• Semi-autonomous workloads may fit a virtual-cluster model if they mainly need their own Kubernetes API surface, CRDs, or Helm/operator freedom.
• Dedicated node pools, autonomous clusters, or external media islands may be more appropriate when a workload needs kernel, CNI, NIC, PTP, driver, FPGA, GPU, DPDK/RDMA, or vendor-privileged control that could destabilize the shared platform.

For MXL, this intersects with this repo's ADR-0017: MXL is currently treated here as an intra-host Layer 4 data plane, so an mxl-processor host role is not merely a performance detail. In this experiment it becomes part of the placement contract.

Future debate should distinguish:

• MXL processor host inside the dmfdeploy cluster
• MXL processor node pool with taints/labels
• autonomous MXL/media island integrated via NMOS, NetBox, observability, and controlled APIs

Open questions:

• What criteria would promote an MXL-capable host from "node role" to "separate media island"?
• Should vendor-owned media appliances ever join a dmfdeploy cluster, or should they usually be integrated as external resources?
• How should vCluster-style tenancy relate to the EBU Dynamic Media Facility layers and lifecycle stages, if at all?

Topic 2: environment factory, not private cloud

There may be value in letting media operators create bounded environments: vendor sandboxes, generic Kubernetes labs, test hypervisors, replay environments, Windows/license-server VMs, and temporary media islands.

The boundary worth discussing is:

dmfdeploy may orchestrate environment intent, but should avoid becoming the environment substrate.

This suggests avoiding generic self-service cloud features already handled by OpenNebula, Proxmox, Kubernetes, Cluster API, or similar systems. Instead, dmfdeploy could experiment with a higher-level "environment factory" around media/facility intent:

1. request a media-relevant environment
2. allocate site, VLANs, prefixes, DNS, certificates, users, secrets, quotas
3. call the selected substrate provider
4. register the result in NetBox
5. attach monitoring/logging/access policy
6. enforce owner, expiry, audit, and teardown

Operator-facing actions might be media/facility actions, for example:

• create vendor media sandbox
• create MXL processing island
• create OB truck commissioning cell
• create NMOS/ST 2110 test environment

They should probably not start as generic "create VM with N vCPU and image X" flows, except perhaps as an advanced drill-down to the underlying provider.

Open questions:

• Which substrate provider, if any, should be the first integration target: OpenNebula, Proxmox, generic Kubernetes, Cluster API, or bare metal?
• Should the first step be a real integration or only a provider-adapter contract?
• Where should environment-factory state live: NetBox, a dmfdeploy API model, provider state, Git, or some combination?

Topic 3: OB truck onboarding and commissioning

One concrete scenario is an outside-broadcast truck with ordinary switches, servers, interfaces, and a small cloud-connected dmfdeploy proxy node capable of discovery, ZTP, and PXE.

A possible lifecycle, using the EBU terms as a guide:

1. Design / Plan

   • register a Facility such as "OB7"
   • define expected Resource Profile: networks, timing, hardware classes, media intent
   • create NetBox Site/Cluster placeholders

2. Provision

   • proxy node phones home
   • operator claims the facility
   • discovery runs: LLDP, DHCP fingerprinting, switch MAC tables, Redfish/BMC, IP scan, NMOS, PTP
   • operator reviews proposed inventory
   • accepted resources are written to NetBox

3. Configure

   • apply an intent profile such as "2110 UHD Truck" or "MXL Truck"
   • configure switches, host baseline, PXE/OS install where appropriate, k3s/Proxmox/OpenNebula where appropriate
   • attach identity, certificates, secrets, monitoring, and logging

4. Operate

   • run validation: PTP lock, multicast checks, NMOS registration, MXL domain health, monitoring targets, catalog deploy checks

5. Finalise & Review

   • record acceptance receipts
   • teardown or return temporary resources to pool
   • preserve audit and usage records

Important nuance: ZTP/PXE should be supported but not mandatory. Broadcast environments are often brownfield, partially configured, vendor-owned, or locked down. dmfdeploy should be able to explore both greenfield commissioning and "adopt existing infrastructure" mode.

Open questions:

• What is the minimal proxy-node contract?
• Which discovery signals are reliable enough to write directly to NetBox, and which require operator approval?
• Should "Facility", "Resource", "Capability", and "Blueprint" become first-class concepts in this project?

Topic 4: licenses as resource pools

The EBU Dynamic Media Facility framing treats licenses as part of the available resource set for media workloads. One possible interpretation for dmfdeploy is to treat licenses as allocatable resources without trying to replace vendor enforcement.

Potential model:

• dmfdeploy tracks license inventory and allocation.
• Vendors continue to enforce their own licenses.
• dmfdeploy performs pre-flight checks and avoids launching workloads that cannot be licensed.
• Optional connectors later reconcile against FlexLM, CodeMeter, Sentinel, vendor REST APIs, cloud entitlement APIs, or manual pools.

This points toward a general resource model rather than a license-only model:

• license pools
• GPU/FPGA pools
• multicast ranges
• PTP domains
• cloud credits
• MXL processor slots
• storage/network bandwidth classes

Open questions:

• Should licenses be modeled in NetBox, in dmfdeploy-specific state, or as provider-reported resources?
• What is the minimum useful manual LicensePool model before any vendor connector exists?
• How does usage/metering remain separate from billing/invoicing?

Topic 5: media capability classes

The discussion raised provider-neutral media capability names such as mxl.2x.large.

This may be useful if the names are validated capability profiles, not hardware prescriptions.

Examples:

• cpu.small
• cpu.medium
• gpu.large
• mxl.1x.medium
• mxl.2x.large
• mxl.fpga.large
• st2110.gateway.medium

The important split:

• generic compute flavor: CPU, RAM, storage
• media capability profile: NIC count/speed, PTP, SR-IOV/RDMA/DPDK, MXL support, ST 2110 bandwidth, accelerators, licenses, NUMA/topology assumptions

Also important: declared vs validated capability.

NetBox may know a server has two 100G NICs. dmfdeploy should probably expose something like mxl.2x.large only after validation proves the host can actually support the intended media behavior.

Open questions:

• Should capability classes be treated as part of the EBU "Resource Profile" vocabulary in this project?
• Should they be catalog requirements, NetBox custom fields, a dmfdeploy API model, or all three?
• What validation tests are required before a host can claim an MXL capability class?
• How should provider-specific flavors map into provider-neutral classes?

Topic 6: AWX, Argo, and Temporal

Another open thread is whether AWX remains the right long-term actuator for dmfdeploy, especially given footprint concerns on small single-node/Flypack-style systems.

This is explicitly post-v0.1 discussion material. The current v0.1 commitment says AWX is the catalog actuator, and Argo/actuator reshaping is out of scope until v0.1 is delivered.

Potential future split:

• Ansible remains a low-level executor for BIOS/BMC, host bootstrap, OS hardening, network setup, firmware checks, and one-shot host tasks.
• Argo CD, if adopted later, handles desired-state Kubernetes deployment.
• Temporal, if ever adopted, handles durable facility lifecycle processes: wait for reboot, await operator approval, reserve licenses, retry validation, hold state for days, and resume after controller failure.

This would not mean "remove Ansible". It would mean Ansible stops being the lifecycle brain for long-running facility processes.

Open questions:

• Is AWX's footprint and roadmap uncertainty enough to justify a post-v0.1 spike?
• Is Temporal too much platform for a single-node/Flypack footprint?
• Could Argo Workflows be sufficient before Temporal is considered?
• What is the smallest experiment that compares AWX-as-actuator with a durable workflow engine without destabilizing the proven v0.1 loop?

Non-goals for this discussion

• No claim that dmfdeploy represents, extends, or defines the EBU Dynamic Media Facility.
• No change to v0.1 commitments.
• No decision to adopt OpenNebula, Proxmox, Temporal, Argo, vCluster, or any new substrate.
• No change to ADR-0017's current MXL placement contract.
• No attempt to turn dmfdeploy into a generic private cloud.
• No issue-level work assignment yet.

Suggested next step after v0.1

If this material still looks useful after v0.1, promote it into one or more RFC-style discussions:

1. Environment Factory and Provider Adapter Contract
2. Media Capability Classes and Resource Profile Mapping
3. License and Resource Pool Model
4. Post-AWX Lifecycle Orchestration Spike

Each should remain debate material until there is a forcing function, acceptance criteria, and a clear decision boundary.

[znerol2]

Status update, 2026-07-17: the first of the four RFCs this thread named is now live — Media function packaging, catalog sources & trust tiers (#248, tracked by #204).

The other three now have a grounded on-ramp: the roadmap landed as docs/plans/DMF Marketplace Resource Model and Placement Grounded Roadmap 2026-07-17.md (#245) routes media capability classes & Resource Profile mapping (after L3 WP0 lands under #202), licence & resource pool model (pairs with ADR-0045 ratification), and post-AWX lifecycle orchestration (only if AWX hits a wall, per the commitments-v1 bar). Sequenced one at a time by design.