SRM Refactor: Service Specification/Application deployment

Paris Stentoumisrequested to merge
refactor/app-deployment into refactor/tf-sdk-ports

Summary

Implements the first SRM service deployment path for command.srm.service.deploy, focused on deploy_workload.

Changes

  • Adds deploy command parsing and two-stage validation.
  • Adds deploy command coordinator for accept, completion, and post-accept failure handling.
  • Creates service_order, service_instance, and deploy capability_instance rows.
  • Publishes event.srm.operation.status and event.srm.operation.completed.
  • Handles duplicate operation_id as idempotent replay:
    • non-terminal duplicates re-emit accepted
    • terminal duplicates re-emit operation.completed
  • Adds naive placement support across zones/domains/capability bindings.
  • Adds repository methods needed for deploy state updates and replay reconstruction.

Scope Notes

  • TF-SDK execution is intentionally left as a TODO because TF-SDK is still WIP.
  • Placement is naive. The first found active domain which supports that specific capability is chosen. Available capacities are ignored for now. As for the Control Path Binding the default is chosen if present else the one with the highest priority (lowest value).
  • Service specification creation has known gaps and is not addressed here.
  • JetStream ACK/work queue semantics are not fully implemented yet; current NATS handling is a stepping stone.
Edited by Paris Stentoumis

Merge request reports