Brief Project Overview

The ONAP Operations Manager is responsible for configuration and life-cycle management of the ONAP platform.

At its core, OOM leverages the industry leading Kubernetes to provide production-grade container orchestration, resiliency and scalability.

ONAP applications use OOM's standardized Helm Charts to provide:

  • customization of ONAP deployments (e.g. ONAP subset for Edge)
  • unified dependency management
  • centralized hierarchical configuration
  • resource limit allocations for different sized deployments (development vs production)

Low cost of entry means ONAP can be deployed from a laptop into any public or private infrastructure that is hosting Kubernetes.

oomLogoV2-large.png

https://kubernetes.io - "allows Google to run billions of containers a week"

New component capabilities for Dublin (i.e. the functional enhancements)

Below is a summary of functional enhancements. For more details please see OOM Dublin Priorities presentation

from Dublin F2F on Dec. 12 - ONAP Project Developers Event, Dec 10 - 12, 2018, (Virtual Webinars)

Platform Resiliency

  • Highly-Available Kubernetes Cluster Deployment
  • Improved Persistent Storage resiliency through the use of a new Default Storage Class Provisioner
  • Multi-site support using CNI reference integration
    • note: applications can take advantage of multi-site by using POD and/or Node (anti)affinity, taints/tolerations, labels per application

Platform Security

  • Integration of an Ingress Controller for Northbound access control and reduction of NodePorts
  • Network Policies (Deferred to El Alto - due to lack of available resources)
  • Transparent TLS enablement via Istio reference integration required Istio→AFF integration (de-prioritized by security subcommittee)

           Addressed to a degree with M3 Checkpoint item under Security - "Has the project committed to enabling transport level encryption on all interfaces and the option to turn it off?".

          With the ability to disable all embedded encryption mechanisms, allows for Service Providers to choose to use Istio or other similar technologies. 

Footprint Optimization

  • Database Consolidation (DBaaS)
    • single shared MariaDB-Galera instance (clients in Dublin: SO, SDNC)
      • includes removing mySQL from SDNC in favor of MariaDB-Galera
    • single shared Cassandra instance (clients in Dublin: AAI, SDC)
    • Portal on shared MariaDB-Galera and Cassandra being investigated (Stretch Goal - has not yet been communicated with Portal Team)
    • single shared Postgres instance (deferred to El Alto)

Platform Upgradeability

  • Upgrade Framework supporting automated rolling upgrade for applications
    • includes in-place schema and data migrations (as well as support for migration to Blue-Green (Pre-prod to Prod) deployment environments)
    • includes upgrading from embedded database instances into shared database instance
  • OOM working with a subset of ONAP project teams to provide full release-to-release upgrades as an MVP for Dublin
    • A&AI (complete)
    • SO (in progress)
    • SDC (in progress)
    • SDNC (in progress)

Platform Monitoring

  • Improved Health Monitoring and Reporting w/ Integration of Prometheus w/ Operator
  • Platform Management UI (deferred to El Alto)
    • integrating best-of-bread open source projects to provide platform monitoring and reporting
    • deployment management via OOM

Offline Installer

  • Delivery of Casablanca Offline Installer in Dublin timeframe
  • Working to align OOM charts such that they are compatible with Offline Installer going forward (WIP)

Helm Chart Ownership Transfer

  • OOM working with a subset of ONAP project teams to transfer the team's Helm Charts into project oom subrepos
  • Building of OOM codebase will work the same as it does in Casablanca
    • oom subrepos pulled into parent oom repository following docs team approach of linking in submodules

New or modified interfaces

OOM does not provide any external APIs.

If they are modified, are they backwards compatible?

N/A

Interface naming (point to an example)

N/A

Reference to the interfaces.

N/A

What are the system limits?

Dependent on Helm and Kubernetes

Involved use cases, architectural capabilities or functional requirements.

OOM manages components for all ONAP support use cases.

Listing of new or impacted models used by the project (for information only).

OOM does not ingest the ONAP data model.


  • No labels