Page Comparison

...

• 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 for all components:
  • • 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?)
    • MSB
    • Multi-VIM
    • VFC
    • CLI (Stretch)
    • CLAMP (Stretch)
    • CCF
    • Holmes (Stretch)
• Monitoring of platform containers, i.e. visibility to the state of each components
• Auto-restart of platform containers when required - maybe requires a second level of policies to avoid infinite restarts.
• Configuration management to deploy on different environments
  • POCs for tools like Ansible, Chef, Cloudify for config management
    
  • step 1 - Externalize platform parameters (remove hardcoded params). 
    • Critical parameters like openstack deployments and etc in an environment file. 
  • step 2 - Configuration management 
  • step 3
    • Need to allow to easily change configurations and manage different versions of the configuration files for each component.
  • Using configuration management to determine which component versions to deploy.
  • Using config management to determine where to deploy each indivirual 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 - 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)

• 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. 

...