...
- Flexible Platform Deployment - While current ONAP deployment automation enables the entire ONAP to be created, more flexibility is needed to support the dynamic nature of getting ONAP instantiated, tested and operational. Specifically, we need the capability to repeatedly deploy, un-deploy, and make changes onto different environments (dev, system test, DevOps, production), for both platform as a whole or on an individual component basis. To this end, we are introducing the ONAP Platform Controller with orchestration capabilities into the deployment, un-deployment and change management process associated with the platform.
- State Management of ONAP platform components – Our initial health checking of Components and software modules are done manually and lack consistency. We are proposing key modules/services in each ONAP Component to be able to self-register/discovered into the ONAP Platform Controller, which in turn performs regular health checks and determines the state of the Components/software.
- Control Loop Actions – Currently there is a lack of event-triggered corrective actions defined for platform OAM. The ONAP Platform Controller will enable DevOps to view events and to manually trigger corrective actions. The actions might be simple initially – stop, start or restart the container. Over time, more advanced control loop automation, triggered by policy, will be built into the ONAP Platform Controller.
Future Potential Use Cases: (These are use cases that could be defined in the future to further advance ONAP Platform OAM/Lifecycle Management)
- Platform-wide microservices on-boarding
- Container support enhancements
- Automated control loop actions
- Integration of DCAE analytics to drive ONAP Controllers corrective actions
- Resiliency – scale in/scale out of Components/software modules
- Capacity augments
- Multiple ONAP instance management –ONAP Controller managing dev/test/prod instances or managing geo-regional instances
- Network integration – control of networks interconnecting Components and networks interconnecting ONAP instances
...
Proposed ONAP Platform Controller Functional Architecture:
- UI/Dashboard – this provides DevOps users a view of the inventory, events and state of what is being managed by the ONAP Platform Controller, 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 the TOSCA-based 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.
- SB Interface Layer – these are a collection of plugins to support actions and interactions needed by the ONAP Platform Controller 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.
- Tiered Controller Architecture – The ONAP Platform Controller will be designed to be scalable via a hierarchy or tiers of controller instances, as volume increases or as need arises. Initially, there will be two tiers of controllers - ONAP Platform Controller Root Node and ONAP Platform Controller DCAE Node:
- The 1st tier Root Node is responsible for deploying and managing all components (except for DCAE) and the Controller DCAE Node
- The 2nd tier DCAE Node is responsible for deploying and managing all subcomponents within DCAE
- Note: It is not necessary to have a separate 2nd tier Node for each ONAP component as volume scales
...
Proposed Phasing of Contribution:
...