Loading
SRM Refactor: Network Capability Activation
Summary
Adds handling for command.srm.network.capability.activate and wires it into the NATS DataBus subscription flow.
The new activation flow validates the command payload, resolves the requested network capability against active service specification requirements, performs naive placement using zone/domain constraints, creates the accepted service order and service instance records, and publishes SRM operation status/completed events according to the current architecture.
Changes
- Added
SrmNetworkCapabilityActivateV1command schema with service instance, service specification, placement pin, and network capability payload validation. - Added
NetworkCapabilityActivateCommandCoordinatorto parse commands, commit acceptance separately, publish accepted status, complete the operation, and handle before/after acceptance failures. - Added
NetworkCapabilityActivateUseCasefor:- duplicate operation replay
- supported capability validation
- active service specification and requirement resolution
- zone/domain placement
- service order and service instance creation
- capability instance creation
- operation completed/failed event generation
- Subscribed SRM to
command.srm.network.capability.activate. - Added temporary default QoD service specification bootstrap until catalog migrations/Alembic are introduced.
- Added bootstrap settings for the default QoD service specification and platform app provider.
- Updated canonical parameter/domain exports to support the new flow.
- Added unit, application, API, and integration coverage for the network capability activation path and DataBus command flow.
Notes
- Capability execution is currently a placeholder success path. The use case includes a TODO to replace it with a TF-SDK capability activation adapter call.
- The default QoD service specification bootstrap is temporary and should be removed once catalog data is managed through migrations.