...
This proposal introduces the ONAP Platform OOM (ONAP Operations Manager) – which initially includes a manager for cross-technology orchestration and container orchestration. It is a framework on which a complete set of OAM capabilities for the ONAP platform components. The OOM will unify the deployment, management and control capabilities for ONAP, including all components, the data messaging fabric as well as the micro-services (including collectors, analytics, UI apps, etc.) to be on-boarded onto the platform. The ONAP Platform OAM OOM addresses the current lack of consistent platform-wide method in managing software components, their health, resiliency and other lifecycle management functions. With the OOM, service providers will have a single dashboard/UI to deploy & un-deploy the entire (or partial) ONAP platform, view the different instances being managed and the state of each component, monitor actions that have been taken as part of a control loop (e.g., scale in-out, self-heal), and trigger other control actions like capacity augments.
...
- 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
...
- 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?
- Options 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 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.
Resources:
- Primary Contact Person: David Sauvageau (Bell Canada)
- Munish Agarwak (Ericsson)
- John NG Ng (AT&T)
- Arthur Berezin (Gigaspaces)
- John Murray (AT&T)
- Christopher Rath (AT&T)
- Roger Maitland (Amdocs)
- Jérôme Doucerain (Bell Canada)
- Marc-Alexandre Choquette ( (Bell Canada)
Alexis De Talhouët (Bell Canada)
- Mike Elliot (Amdocs)
- Mike Nguyen (Amdocs)
- Catherine Lefevre (AT&T)
- TBD (Orange)
...