Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 16 Next »

Brief Project Overview

The ONAP Operations Manager is responsible for configuration and life-cycle management of the ONAP platform. OOM leverages the industry leading Kubernetes to provide production-grade container orchestration, resiliency and scalability.

OOM defined standardized Helm Charts provide ONAP components with:

  • customization of ONAP deployments (e.g. select components 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
  • 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)

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)

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?


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