Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...