...
- EMCO/ONAP Architecture alignment Deep Dive
- Part 1: On-boarding: Alignment across ONAP and EMCO, taking into account the role played by k8s.
- Infrastructure→Applications>Onboarding>MANO>Infrastructure Infrastructure → Applications>Onboarding>MANO>Infrastructure (end-to-end)
- Appropriate use cases for EMCO and ONAP, when to use them separately and or together
- The teams have identified two fundamental configurations, each ideally suited for different high level use cases
- ONAP is the centralized Service Orchestrator, Service Assurance and Automation Framework, with EMCO fulfilling specific roles as a component (multi cluster support, etc)
- EMCO is the distributed edge focused Service Orchestrator, with select ONAP Service Assurance components configured as needed.
- We can draw from the following examples and other supporting material during this session to describe the rationale
- Review of the EMCO_ONAP Alignment Proposal PPT.
- Lessons learned from:
- Magma orchestration with EMCO (2022-01-13 - EMCO: Orchestration of Magma)
- Magma orchestration with ONAP (https://wiki.onap.org/display/DW/2022+Enterprise+Task+Force?preview=/117743631/117743639/ONAP_Magma%20Integration%20status.pptx)
- EMCO team overviews the rationale for, deploying an app/service such as Magma as the primary SO
- Given the different configurations , how can the 5G SBP program demonstrate and delineate the rationale for the two configurations?
- Part 1: On-boarding: Alignment across ONAP and EMCO, taking into account the role played by k8s.
...
- Presentation walk-thru
- Two "variations" for the integration
- Variation/profile 1 - "SDO inspired" - leveraging ONAP's SO, DCAE based close loop automation, centralized inventory for PNF/VNF/CNF. EMCO as CNFM. Future enhancements (later phase): ONAP CDS for runtime configuration, OOF for optimization - supporting Intent Based Networking (IBN).
- Variation/profile 2- "Model free" - EMCO for orchestration and service configuration. ONAP DCAE for closed loop automation. Using Temporal, not Camunda for workflow. Focus is cloud-native, using Helm charts
- Catherine Lefevre presenting variation 1
- Next level of details would be breaking down each interface shown in the diagrams and specifying the API used, parameters, model.
- ONAP SO is adding Intent Based Orchestration in addition to the Model DrivenOrchestration.
- EMCO has also been working on intent based orchestration and so this is a key area for coordination. Seshu Kumar Mudiganti works within ONAP and EMCO and raised this point. matchmaking opportunity
- expose intent-based capabilities to NB interface is a goal
- Catherine proposes that Srinivasa Addepalli, Seshu Kumar Mudiganti Seshu, others interested in this subject can drive a discussion on this in the communities
- Srinivasa Addepalligives an overview of 2nd profile
- Primarily a cloud native design from the ground up. Not model driven- using helm charts exclusively
- Pluggable workflow engines, adding Temporal currently
- Intended for use case where lightweight orchestration is a key driver
- Intent based orchestration here includes intent -based placement of workloads
- also placement constraints, which edge location is chosen for example, capability awareness or latency awareness for example
- Service Mesh connectivity can be across k8s clusters and EMCO can automate this configuration
- Can customize the resource constraints for the same app/service depending on the edge location
- The GitOps approach for syncing resources was added to support compatibility with MS Azure and Google Anthos
- Lukasz Rajewskinotes that this Configuration #2 is indeed very lightweight and it is important to consider the Service Assurance capabilities of ONAP
- Lukasz Rajewski - In order to use DCAE closed loop automation, A&AI needs to be integrated as well.
- Seshu Kumar Mudiganti - Is Temporal the only supported workflow engine? Srinivasa Addepalli - There are other workflow engines supported. Temporal is not mandatory. The workflow is considered part of the "EMCO Ecosystem", not "EMCO Base". Catherine Lefevre Concerned about confusing the end users by the use of two different workflow engine.
- Temporal was added due to its fundamental cloud native architecture, becoming very popular in the enterprise world.
- Catherine Lefevre , Beth Cohen - Operations teams need simple tools. They are not software developers. New workflow engines should be easy to use by this type of users. During deployment time ("day 1") information has to be pulled from an external source (customer orders) automatically. Srinivasa Addepalli - This is exactly what the EMCO ecosystem is there for, to support these external integrations.
- Bob Monkman - There should be a default workflow option, as well as a pluggable option.
- Chaker Al-Hakim - There are functional differences between Camunda and Temporal, where the latter includes a state machine.
- Pankaj Goyal (Microsoft) to Everyone (5:55 AM)
is it really true that central inventory is not required?
Srini Addepalli (Intel) to Everyone (6:17 AM)
@Pankaj, inventory is required and maintained by EMCO. It is distributed, but common API is provided to get hold of inventory (both static and dynamic).
- Two "variations" for the integration