• Update on scope for Beijing.
    • Question from John Ng: Do we need to perform a major change on the components architecture in order to support auto-restart of components in order to preserve state?
      • ONAP has been tested on OOM to restart/recover properly in most cases when there are no transactions in progress. More testing required to make it work during transactions, that we don't loose any data, that transactions gets completed.
      • Need to make sure that Kubernetes itself is highly available as well. What tools are needed around k8s to make sure the k8s infra is monitored? Some of the architecture will be very specific to the operators. Action: update the OOM architecture diagram to properly reflect the boundaries of OOM vs operator-specific technologies. 
      • The logging project is working on end to end traceability of transactions. Maybe that could be used for the transaction during failures
      • One of the ONAP issues to be clarified: how can we ensure e2e transactions in ONAP using OOM/K8S, even when failures occur? 
      • The OOM team should present the technology and guidelines so that component teams can make their components highly available / recoverable / etc.
      • The OOM team should be ready to present the guidelines at the santa clara event. The ambitions goal would be to have one example to show (eg. SDNC) the guidelines.
      • Create 1 challenge/goal for the team: Have an SDNC OOM enabled clustering available prior to the santa clara event. David Sauvageau to define the epic/stories.
      • Need to make sure Config Management is part of the Beijing release. Goal is to enable multiple deployments of ONAP with independent parameters.
        • Need to build a solution to "stop copying configs".
        • Do we consider as part of Beijing the support of "Multi-ONAP deployments" / Federation of ONAPs? Could be because the network is too big, because of different countries/legislations, etc. Need to refine the problem statement. The technology used can be used.
        • Actions: Bring the topic to the architecture sub-committee. Roger Maitland will work with John Ng and Michael O'Brien, Mike Elliott, Borislav Glozman to have an initial proposal documented online. Ideas will be discussed with the community then.Subscribe for the carrier grade page for updates!
      • Should Offline install be part of Beijing release?
        • Many carriers want to install without being dependent of an internet connection
        • One of the strategies with config management is the configurability of a local nexus repo to avoid internet dependency
        • Also, cloudify would be able to support an offline install. Cloudify would create a local mirror of the repos to support offline install
        • Question: does kubernetes itself have an offline install capabilities?
        • Offline install should be added as a clear objective for the Beijing release, i.e OOM offers the capability for offline install (initial install); component teams need to implement on their projects.  Need to scope properly.
            • Need to work with the demo / integration team.
            • There is some core re-architecture work to happen on some component teams if we set this as a target.
            • We could also approach the security team as one of the core reason for this is for security matters. Requirement could come from the security team. David Sauvageau to send question to Stephen Terrill
      • Should OOM Continuous Deployment be part of Beijing?
      • Should ONAP platform TOSCA support be part of Beijing?
  • Santa clara event - sessions (presentations with demos)
    Root Epic :  OOM-392 - Getting issue details... STATUS
  • No labels