...
OOM functionality
Minimum Viable Product
- Run the vFirewall demo on docker/kubernetes
- Document Guidelines for bringing components to kubernetes (all component teams can bring themselves their components to OOM).
- ONAP platform 1-click deployment using containers on kubernetes for all 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
(old or new or both?) - onap-aai
- MSB
- Multi-VIM
- VFC
- Stretch target
- CLI (Stretch)
- CLAMP (Stretch)
CCF- Holmes (Stretch)
- MVP
- 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 Monitoring of platform containers, i.e. visibility to the state of each components
- AutoPlatform components auto-healing mvp: auto-restart of platform containers when required - maybe requires 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
- MVP
- Technical 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.
- Need to 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 deployment
- Stretch
- Distributed platform deployment
- Using config management to determine where to deploy each
- individual components across geographies (stretch)
- Anti-affinity
- Config management examples so that the community know how to use:
- 1 would be for lab deployment
- 1 for a production deployment
- step 2 -
- Advanced Multi-data-center platform deployment policies, e.g. applying anti-affinity rules for different components.
- Automated config management (M2)
- MVP
- 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)
- 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.
Out of scope
- Platform components/containers auto scaling of onap platform containers
...
- -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.
...