- Created by Kenny Paul, last modified by Roger Maitland on Aug 24, 2017
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 4 Next »
Introduction
The ONAP Operations Manager (OOM) is responsible for life-cycle management of the ONAP platform itself; components such as MSO, SDNC, etc. It is not responsible for the management of services, VNFs or infrastructure instantiated by ONAP or used by ONAP to host such services or VNFs. OOM uses the open-source Kubernetes container management system as a means to manage the Docker containers that compose ONAP where the containers are hosted either directly on bare-metal servers or on VMs hosted by a 3rd party management system. OOM ensures that ONAP is easily deployable and maintainable throughout its life cycle while using hardware resources efficiently.
Quick Start Guide
Once a kubernetes environment is available and the deployment artifacts have been customized for your location, ONAP is ready to be installed.
In-order to be able to support multiple ONAP instances within a single kubernetes environment a configuration set is required. The createConfig.sh
script is used to do this.
createConfig.sh
> ./createConfig.sh -n onapTrial
|
The bash script createAll.bash
is used to create an ONAP deployment with kubernetes. It has two primary functions:
- Creating the namespaces used to encapsulate the ONAP components, and
- Creating the services, pods and containers within each of these namespaces that provide the core functionality of ONAP.
createAll.bash
|
Namespaces provide isolation between ONAP components as ONAP release 1.0 contains duplicate application (e.g. mariadb) and port usage. As such createAll.bash
requires the user to enter a namespace prefix string that can be used to separate multiple deployments of onap. The result will be set of 10 namespaces (e.g. onapTrial-sdc, onapTrial-aai, onapTrial-mso, onapTrial-message-router, onapTrial-robot, onapTrial-vid, onapTrial-sdnc, onapTrial-portal, onapTrial-policy, onapTrial-appc
) being created within the kubernetes environment. A prerequisite pod config-init (pod-config-init.yaml
) may editing to match you environment and deployment into the default namespace before running createAll.bash
.
Each project should have its own page with all of the associated project pages / attachments under it.
For consistency, use the same <project Name> as recoded in the lis of Resources and Repositories
OOM Architecture and Technical Details
OOM uses the Kubernetes container management system to orchestrate the life cycle of the ONAP infrastructure components. If you'd like to learn more about how this works or develop the deployment specifications for a project not already managed by OOM look here: OOM User Guide.
Amsterdam Release Planning
- M1 Release Planning Checklist link
- M2 Functionality Freeze Checklist link
- M3 API Freeze Checklist link
- M4 Code Freeze Checklist link
- RCx Checklist link
- Sign-Off Checklist link
- OOM for Planning Milestone Checklist Template
Links to Further Information
- The OOM project proposal page is here: Approved Project Proposal.
- Configuration data for all of the ONAP sub-projects is distributed by OOM. For more information on how this is done see: OOM Configuration Management.
- If you're interested in project status, look here: OOM Status.
- The committers on this team are listed here: OOM Team
- The OOM Weekly meeting notes will help you understand what the OOM team is actively working on.
- No labels