CDS artifact authoring & distribution should be done through the integration with SDC. For the execution of the blueprints, in order to provide access to the execution logs, and provide end-user teams with full control over the lifecycle of the executors - a model similar to the DCAE controllers & analytics applications is used - controlled through Kubernetes roles and Gitlab group membership for their authoring & deployment.

Possible Patterns

• Run fully independent controller instances, and whichever components have to run controller actions need to know which blueprint processor it should talk to 
  • This requires a mechanism to define, and provide visibility to which Controller instance is used for a given service or resource 
  • Ideas : 
    • Upon creation/initial service instantiation, assign a CDS instance and inventory it. 
      • This requires support in the inventory (A&AI) to identify 
      • This may mean impacts to components calling controllers, having to look up that inventory binding
      • Which component deals with the assignment of that CDS instance? i.e. CDS ? or simply supply it.

• Similar to a controller-resource registry (applicable at different levels - service, generic-vnf, pnf, etc.)
• Challenges  
  • Complete scaling unit for controllers : 
    • As a whole unit (Controller blueprint processor/logic interpreter, controller data store (CDS DB, MDSAL), externalized executors, etc.**

Resource committed :

Sebastien Premont (Bell)

Integration Owner :
Olivier(Bell)

Other TSC must-have requirements committed for SO: