You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 62 Next »

Draft.

Project Name:

  • Proposed name for the project: ONAP Operations Manager
  • Proposed name for the repository: oom

Project description:

This proposal introduces the ONAP Platform OOM (ONAP Operations Manager) to efficiently Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). The OOM addresses the current lack of consistent platform-wide method in managing software components, their health, resiliency and other lifecycle management functions.  With 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 across data centers. 

The primary benefits of this approach are as follows:

  • 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 Operations Manager 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 Operations Manager, which in turn performs regular health checks and determines the state of the Components/software.
  • Platform Operations Orchestration / Control Loop Actions – Currently there is a lack of event-triggered corrective actions defined for platform components.  The ONAP Operations Manager will enable DevOps to view events and to manually trigger corrective actions.  The actions might be simple initially – stop, start or restart the platform component.  Over time, more advanced control loop automation, triggered by policy, will be built into the ONAP Operations Manager. 



Proposed ONAP Operations Manager Functional Architecture:



  • 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

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: 

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • The ONAP Operations Manager (OOM) is used to deploy, manage and automate ONAP platform components operations. 
  • 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 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) 

Resources:

  • Primary Contact Person: David Sauvageau (Bell Canada)
  • Munish Agarwak (Ericsson)
  • John 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 Elliott (Amdocs)
  • Mandeep Khinda (Amdocs)
  • Catherine Lefevre (AT&T)
  • TBD (Orange)
  • Alon Strikovsky (Amdocs)
  • Elhay Efrat (Amdocs)
  • Yury Novitsky (Amdocs)
  • Eliyahu Noach (Amdocs)
  • Xin Miao (Huawei)
  • Joe Zhang (ZTE)
  • Jason Hunt (IBM)
  • Jochen Kappel (IBM)
  • Josef Reisinger (IBM)
  • Helen Chen (Huawei)
  • Earle West (AT&T)
  • Yang Xu (Huawei)

Other Information:

  • link to seed code (if applicable)
     aai/aai-data AAI Chef environment files
     aai/logging-service AAI common logging library
      aai/model-loader Loads SDC Models into A&AI
     appc/deployment APPC docker deployment

     ci-management - Management repo for Jenkins Job Builder, builder scripts and management related to the CI configuration.
     dcae/apod/buildtools - Tools for building and packaging DCAE Analytics applications for deployment
     dcae/apod/cdap  - DCAE Analytics' CDAP cluster installation
     dcae/operation - DCAE Operational Tools
     dcae/operation/utils - DCAE Logging Library
     dcae/utils - DCAE utilities
     dcae/utils/buildtools  - DCAE utility: package building tool
     mso/chef-repo - Berkshelf environment repo for mso/mso-config
     mso/docker-config -MSO Docker composition and lab config template

     mso/mso-config - mso-config Chef cookbook

    ncomp/docker - SOMF Docker Adaptor

    policy/docker - Contains the Policy Dockerfile's and docker compose script for building Policy Component docker images.
    sdnc/oam - SDNC OAM


  • 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: ONAP Operations Manager
  • JIRA project prefix: oom

Repo name: oom
Lifecycle State: Incubation
Primary Contact: TBD
Project Lead: TBD
mailing list tag oom
Committers (Name - Email - IRC):

*Link to TSC approval: 
Link to approval of additional submitters: 

  • No labels