Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • How does this align with external standards/specifications?
    • At target, TOSCA should be used to model platform deployments and operations.
  • Are there dependencies with other open source projects?
    • Open source technologies could be Cloudify, Kubernetes, Docker, and others.
    • The OOM will have dependency on the current proposed "Common Controller Framework" (CommServ 2) project and will leverage its software framework.   
    • The OOM will require to work with the MSB project for to perform a comprehensive Service Registry function. At this point, the 2 projects seems to have needs to manage service registry at 2 different levels, i.e. MSB at the micro/macro service endpoint level vs OOM at the micro-service/component level. 
    • The OOM will have inter-dependencies with DCAE (specifically the DCAE Controller).  OOM will be built on the CCF software framework for ONAP platform management.  DCAE Controller will be updated to use the same CCF software framework.  In addition, OOM ("Root Node") and DCAE Controller ("DCAE Node") form the initial hierarchy of managers for ONAP platform management (as depicted in Slides 7-8 of this deck: https://wiki.onap.org/pages/worddav/preview.action?fileName=ONAP_Operations_Manager_Proposalv2.pdf&pageId=3246809).  OOM Root Node is the Tier 1 manager responsible for the entire platform and delegates to the Tier 2 DCAE Controller/DCAE Node to be responsible for managing DCAE and its analytics and collector microservices. 
    • The current proposed "System Integration and Testing" (Integration) Project might have a dependency on this project - use OOM to deploy/undeploy/change the test environments, including creation of the container layer.
    • This project has also a dependency on the LF infrastructure (seed code from ci-management project) 

...


Initial Implementation Proposal: ONAP on Containers

Description:

This milestone describes a deployment and orchestration option for the ONAP platform components (MSO, SDNC, DCAE, etc.) based on Docker containers and the open-source Kubernetes container management system. This solution removes the need for VMs to be deployed on the servers hosting ONAP components and allows Docker containers to directly run on the host operating system. As ONAP uses Docker containers presently, minimal changes to existing ONAP artifacts will be required.

...