Versions Compared

Old Version 64

changes.mady.by.user Srinivasa Addepalli

Saved on

compared with

New Version 65

changes.mady.by.user Srinivasa Addepalli

Saved on

Key

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

...

  • Option 1 analytics : Option 1 uses same infrastructure that is available for deploying VNFs

    • Option 1 Pros (with respect to other options)
      • Since it uses same infrastructure as VNFs, any enhancements done in orchestration for VNFs comes free for ONAP management applications .
      • ONAP Management applications requiring selective placement (based on criteria such as hardware capabilities, latency, distance, affinity and anti-affinity) can be satisfied using OOF.
      • ONAP management applications that have 1:1 correspondence with VNFs can be brought together.
      • ONAP management applications of different form factors (such as VM and containers) can be taken care.
      • ONAP management applications can be placed in cloud regions with different technologies
      • Single orchestrator for both managed and management applications.
    • Option 1 Cons:
      • Majority of ONAP management applications today are described using helm and hence they can be deployed easily using option 1.  But, there are many ONAP management applications are described using TOSCA. They can't be deployed using option 1 until TOSCA support is added in SO.  Since Cloudify-TOSCA plan is not in the roadmap for Dublin., It is also an understanding that Cloudify-TOSCA support in SO may not happen this year. 
      • Some of the ONAP components are not instantiated using OOM. They get instantiated dynamically by CLAMP framework.  Supporting CLAMP initiated ONAP management application deployment with SO may require significant development.
    • Analysis:
      • Any management application that is described in HEAT/Helm, that is independent of CLAMP can leverage this option. 
      • Since there are applications that are described in Cloudirfy-TOSCA, it is felt that this option alone can't satisfy the critical requirement 
      • It also appears that AT&T EOM option is tested in AT&T labs and comprehensivebeing extended to deploy management applications in remote sites and it is in active development.
      • It also appears that AT&T intends to opensource EOM.
    • Conclusion:
      • Go with EOM (Option 2) - And enhance to satisfy all the high requirements.
      • But, any management application that is independent of CLAMP and described using HEAT/Helm can use this option, upon the choice of the deployment admin.

  • It was considered pragmatic to synergize Options 2 and 3 to produce a best of breed solution

...