Page History

...

In the Amsterdam release, OOM will be used to automatically deploy and re-deploy all ONAP platform components using containers technology, to monitor components state and to automatically heal broken platform components when required. 

Use Cases

OOM functionality functionality is platform wide and is therefore not directly tied to specific use cases. However the vFW use case will be used as the test bed for OOM. 

Minimum Viable Product

• ONAP platform 1-click deployment on kubernetes for key components:
  
  • MVP
    onap-aai
    • aai-service
    • hbase
    • model-loader-service
  • onap-appc
    • dbhost
    • dgbuilder
    • sdnctldb01
    • sdnctldb02
    • sdnhost
  • onap-message-router
    • dmaap
    • global-kafka
    • zookeeper
  • onap-mso
    • mariadb
    • mso
  • onap-policy
    • brmsgw
    • drools
    • mariadb
    • nexus
    • pap
    • pdp
    • pypdp
    • portalapps
    • portaldb
    • vnc-portal
  • onap-robot
    • robot
  • onap-sdc
    • sdc-be
    • sdc-cs
    • sdc-es
    • sdc-fe
    • sdc-kb
  • onap-sdnc
    • dbhost
    • sdnc-dgbuilder
    • sdnc-portal
    • sdnctldb01
    • sdnctldb02
    • sdnhost
  • onap-vid
    • vid-mariadb
    • vid-server
  • AAF
  • DCAE
  • MSB
  • Multi-VIM
  • VFCStretch target
    
  • CLI (Stretch)
  CLAMP (Stretch)
  • Holmes (Stretch)
• vFirewall demo on docker/kubernetes
• OOM Guidelines: 
  • Provide guidelines to the community teams for bringing components to oom/kubernetes (all component teams can bring themselves their components to OOM). 
• Platform containers monitoring:  provide visibility to the state of each components
• Platform components auto-healing mvp: auto-restart of platform containers on shutdown (may require a second level of policies on top of kubernetes to avoid infinite restarts)
• Platform Configuration management to deploy on different environments
  
  • MVPTechnical architecture & technology POCs for tools like Ansible, Chef, Cloudify for config management
  • Platform configuration parameters externalization to enable custom deployments (i.e. remove all hardcoded parameters). 
    • Critical parameters like openstack deployments and etc in an environment file. 
  • Component-level configuration & version management: allow to easily change configurations and manage different versions of the configuration files for each component.
  • Platform configuration management examples/demos so that the community knows how to use oom. Would require 2 examples
    • 1 would be for lab deployment
    • 1 for a production
  deploymentStretchDistributed platform
  • • deployment
  Using config management to determine where to deploy each individual components across geographies (stretch)
  • Advanced Multi-data-center platform deployment policies, e.g. applying anti-affinity rules for different components.
  • Automated config management (M2)
• Platform Upgradability:
  • Teams must expose endpoints for rollbacks and ensure backward compability. We need to provide requirements to each component teams.
  • Ability to deploy multiple instances of ONAP on different versions.
  • Manage individual components versions - Ability to upgrade 1 component at the time. 
• Running ONAP platform across different hosts (stretch)
• Running ONAP on different geographies (stretch)

• Platform infrastructure & multi-deployment options support (TBD)Collaboration
  • Integration team: monitoring an end-to-end platform solution. Make the vFW demo managed by oom. 
  MSB: Service registration and discovery is overlapping - need to be in MVP.
  • Orchestrating infrastructure deployment and more deployment options with Cloudify - will determine if it is MVP or stretch or M2 scope. Maybe we lay the foundation in M1 Amsterdam and then grow. 
  
  

Stretch goal

• ONAP platform 1-click deployment on kubernetes for additional components:
  
  • CLI (Stretch)
  • CLAMP (Stretch)
  • Holmes (Stretch)
• Platform Configuration management - Scaled deployment
  
  • Distributed platform deployment using config management to determine where to deploy each individual components across geographies (stretch)
  • Advanced Multi-data-center platform deployment policies, e.g. applying anti-affinity rules for different components.

Out of scope

• Platform components/containers auto-scaling auto scaling

Functionalities

List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities.

...

Third Party Products Dependencies

Third Party Products mean products that are mandatory to provide services for your components. Development of new functionality in third party product may or not be expected.
List the Third Party Products (OpenStack, ODL, RabbitMQ, ElasticSearch,Crystal Reports, ...).

In case there are specific dependencies  (Centos 7 vs Ubuntu 16. Etc.) list them as well.

...