...
- UI/Dashboard – this provides DevOps users a view of the inventory, events and state of what is being managed by the ONAP Operations Manager, and the ability to manually trigger corrective actions on a component. The users can also deploy ONAP instances, a component, or a change to a software module within a component.
- API handler – this supports NB API calls from external clients and from the UI/Dashboard
- Inventory & data store – tracks the inventory, events, health, and state of the ONAP instances and individual components
- ONAP Lifecycle Manager – this is a model-driven orchestration engine for deploying/un-deploying instances and components. It will trigger downstream plugin actions such as instantiate VMs, create containers, stop/restart actions, etc. Target implementation should aim at TOSCA as the master information model for deploying/managing ONAP Platform components.
- SB Interface Layer – these are a collection of plugins to support actions and interactions needed by the ONAP Operations Manager to ONAP instances and other external cloud related resources – plugins may include Openstack, Docker, Kubernetes, Chef, Ansible, etc.
- Service & Configuration Registry – this function performs the registry and discovery of components/software to be managed as well as the subsequent health check on each registered component/software
- Hierarchical OOM architecture for scaling and specialization - OOM's architecture allows for a hierarchical implementation for scale as volume/load and scope of the underlying ONAP platform instance(s) increases. (see attached deck for more information on OOM's hierarchical architecture - Slides 7-8: https://wiki.onap.org/pages/worddav/preview.action?fileName=ONAP_Operations_Manager_Proposalv2.pdf&pageId=3246809.)
Scope:
- In scope: ONAP Platform lifecycle management & automation, i.e.
- Platform Deployment: Automated deployment/un-deployment of ONAP instance(s) / Automated deployment/un-deployment of individual platform components
- Platform Monitoring & healing: Monitor platform state, Platform health checks, fault tolerance and self-healing
- Platform Scaling: Platform horizontal scalability
- Platform Upgrades: Platform upgrades
- Platform Configurations: Manage overall platform components configurations
- Platform migrations: Manage migration of platform components
- Out of scope:
...
- 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 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)
...