Meeting Minutes:

1. Disaggregation à resource resolution ms from blueprint processor
• Resource Resolution mS shall be created
• Self Service API shall forward the call to resource resolution mS
• Resource resolution engine
• Template engine generation
• Decouple the Database management for persisting the resource resolution. [nice to have]
• Database is outside of the mS For resource resolution. (mariagaleriadb)
• Resource Resolution Context Key à
• Resource resolution Component  need to be extended to support unassignment based on the data dictionary capabilities for unassign.
• The resource tables shall be extended to store the resource keys  and configlet id
• Alexis to make the change: Default to true for storing the configlet generation in the tables;
• Action Item:
• Alexis to provide POC implementation and provide feedback.
• Revisit Brinda idea of device modeling using json path.

1. Atomic Transaction—
• For a given action within support configlet generation  and download for multiple
• Each Transaction  support rollback /Failure
• Rollback include previously successful configlet download
• All Device are lock until all the action are implemented.
• Atomic Transaction should be supported in parallel; 

• Alexis Solution:
• NetConf Protocol
• Commit confirm capability supported
• Commit Confirm success
• Commit works for the first 2
• Commit fails on 3^rd.
•  
• CDS Platform capability for rollback is supported via imperative workflow and/or DG CDS failed action.
• Action
• Yuriy to create a US for testing the rollback activities as a roadmap item.
• Dan T to provide a WIP patch of Om implementation of atomic transaction for Alexis to review.
• General premise is to support a disconnect flow for rollback use case.
• Support the capability of Commit Id Rollback (also can be supported but the team felt that disc is more likely—this implementation can be modeled.

1. Resource Resolution for Ansible/Pyton:
• Action Item:

• Yuriy to create a placeholder US for supporting the capability for persisting resolved resource using Ansible/Python script. The Ansible/Pything script shall call the resource resolution API to store the resource resolve context. Notion is that CDS is the source of truth for all resolved resource that is pushed to the network.
• Alexis to upstream it.

1. Building Block Orchestration using CDS Resource Assignment:
• Bell is looking a way to eliminate the resource accumulator template and simplify the resource resolution for cloud orchestration.
• The approach is to use the directly the CDS Building block for Service, VNF, VF Module                Assign and Unassign
• Assign:
• Option 1:  (preferred)
• have SO retrieve the CDS context using the A&AI self-link.
  • Sub-Option 1 
    • Retrieve the Resolved name/value pair context
  • Sub-Option 2 (Preferred)
    • Retrieve the Cloud Meshed Context 
  • Sub-Option 1 & 2
    • CDS will provide right link for retrieving the correct sub-option. 
• Option2:
• have CDS Create either MD-SAL structure for SO to extract context as part of create
Partita

• Option 1 & 2:
  • Partial assignment should be supported. Can be model in CDS similar to the current DG implementation.

• Unassign/Delete
• Have CDS unassign the capability using the unassign capability reference in the data dictionary.

1. SDNC Helm Chart Update

• Update CDS chart to be standalone.
• Default CDS Chart to be Y
• Action Item:
• Yuriy to create US for Abdel.

1. MultiCloud , SO and CDS Integration

• Leverage the SO, SDNC, and CDS Building
• Multicloud to support the onboarding of the values.yaml via SDC
• Override values.yaml file will be a template
• CDS shall resolved resource in name value pair and SDNC shall persist in mD_SAL
• SO shall retrieve the SDNC context and pass it to MultiCloud
• MultiCloud shall mesh the override .yaml template with sdnc context and trigger HELM.
• Extended the CDS Integration to LCM Action and Helm Creation/Deletion.
• Action Item:
• Eric/Lukasz to help with the integration strategy for Frankfurt release.