Draft.
Project Name:
- Proposed name for the project: ONAP Platform ContainerizationONAP Operations Manager
- Proposed name for the repository: pfcoom
Project description:
This proposal introduces the ONAP Platform OAM OOM (ONAP Operations , Administration, and ManagementManager) – which initially includes a controller for cross-technology orchestration and container orchestration. It is a framework on which a complete set of OAM capabilities can be enabled on ONAP. The ONAP Platform Controller 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 Controller OAM addresses the current lack of consistent platform-wide method in managing software components, their health, resiliency and other lifecycle management functions. With the ONAP Platform ControllerOOM, 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.
...
- 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.
Proposed Phasing of Contribution:
We plan to contribute first the ONAP Platform Controller software framework based on the above functional architecture. Then we will follow up with the 1st tier ONAP Platform Controller Root Node and 2nd tier DCAE Node. Note that the 2nd tier DCAE Node will replace the existing DCAE Controller that is embedded in the initial ONAP release.
...
Initial proposal - ONAP Containerization with Docker/Kubernetes
This project describes a supplementary deployment and management solution for ONAP platform components 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.
The primary benefits of this approach are as follows:
- Life-cycle Management. Kubernetes is a comprehensive system for managing the life-cycle of containerized applications. Its use as a platform manager will ease the deployment of ONAP, provide fault tolerance and horizontal scalability, and enable seamless upgrades.
- Hardware Efficiency. As opposed to VMs that require a guest operating system be deployed along with the application, containers provide similar application encapsulation with neither the computing, memory and storage overhead nor the associated long term support costs of those guest operating systems. An informal goal of the project is to be able to create a development deployment of ONAP that can be hosted on a laptop.
- Deployment Speed. Eliminating the guest operating system results in containers coming into service much faster than a VM equivalent. This advantage can be particularly useful for ONAP where rapid reaction to inevitable failures will be critical in production environments.
- Cloud Provider Flexibility. A Kubernetes deployment of ONAP enables hosting the platform on multiple hosted cloud solutions like Google Compute Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more.
In no way does this project impair or undervalue the VM deployment methodology currently used in ONAP. Selection of an appropriate deployment solution is left to the ONAP user.
Challenges
Although the current structure of ONAP lends itself to a container based manager there are challenges that need to be overcome to complete this project as follows:
- Duplicate containers – The VM structure of ONAP hides internal container structure from each of the components including the existence of duplicate containers such as Maria DB.
- DCAE - The DCAE component not only is not containerized but also includes its own VM orchestration system. A possible solution is to not use the DCAE Controller but port this controller’s policies to Kubenetes directly, such as scaling CDAP nodes to match offered capacity.
- Ports - Flattening the containers also expose port conflicts between the containers which need to be resolved.
- Permanent Volumes - One or more permanent volumes need to be established to hold non-ephemeral configuration and state data.
- Configuration Parameters - Currently ONAP configuration parameters are stored in multiple files; a solution to coordinate these configuration parameters is required. Kubernetes Config Maps may provide a solution or at least partial solution to this problem.
- Container Dependencies – ONAP has built-in temporal dependences between containers on startup. Supporting these dependencies will likely result in multiple Kubernetes deployment specifications.
Scope:
- In scope: ONAP Platform lifecycle management & automation through containers, i.e.
- Platform Deployment: Automated deployment/un-deployment of ONAP instance(s) using containers / Automated deployment/un-deployment of individual platform components using containers,
- Platform Monitoring & healing: Monitor platform state, Platform health checks, fault tolerance and self-healing using containers
- Platform Scaling: Platform horizontal scalability through containers
- Platform Upgrades: Platform upgrades using containers
- Supplementing NEXUS repositories with additional containers which are currently built dynamically.
- Platform Configurations: Manage overall platform components configurations
- Platform migrations: Manage migration of platform componentsInactivating the DCAE Controller and replacing its functionality with native Kubernetes operations.
- Out of scope: support of container networking for VNFs. The project is about containerization of the ONAP platform itself.
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
- Please Include architecture diagram if possible
- What other ONAP projects does this project depend on?
- May have a close relationship with OAM (ONAP Administration and Management)
- How does this align with external standards/specifications?
- N/A
- Are there dependencies with other open source projects?
- Docker
- Kubernetes
Resources:
- Primary Contact Person: David Sauvageau (Bell Canada)
- 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)
Other Information:
- link to seed code (if applicable)
- Vendor Neutral
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
- Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name: platform-containerization
- JIRA project prefix: pfc
...