...
Management application: Can be ONAP component or equivalent component from third parties
Architectural Options:
Discussion Kick off:
Various Architectural Options: https://wiki.onap.org/download/attachments/28379482/ONAP-DDF-Distributed-Analytics-framework-v1.pptx?api=v2
Solution Options
Management Apps as traditional Apps/VNFs - Option 1 | Extending DCAE Orchestration (OOM-Tosca + OOM helm charts)- Option 2 | Cloud Native K8S Ecosystem (which includes current OOM helm charts ) - Option 3 |
|---|---|---|
Existing infrastructure that is available in ONAP •Use SDC for onboarding management applications if they are independent of VNF Or make management app also part of VNF if it needs to be dynamic •Use SO to bring up the management app like any other VNF •Leverage MC for talking to various cloud-regions of different technologies (Management App as VM or container or public cloud entity) •Leverage OOF to make placement decisions (such as HPA, affinity, anti-affinity) | Using Existing DCAE orchestration to deploy and manage lifecycle for all management application (central and edge) DCAE orchestration supports deployments of Ms (collectors, and analytics services); primary orchestrator is cloudify. The current orchestration can be extended for supporting deployment of helm charts and Tosca_blueprints to deploy wide ranges of managed applications/services at multiple sites. | Cloud Native K8S Ecosystem - https://landscape.cncf.io/ ONAP OOM Project - Prescriptive Helm Charts for various ONAP management plane components |
...
| Requirement | Operator Near-term (2019) vs Long-term (Beyond 2019) | Operator feedback Consolidation | Comments |
|---|---|---|---|
1.Consolidated view of deployed management component micro-services (in Central and other locations such as Edge) and their relationship for central Orchestrator | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term Verizon- near-term Vodafone - near-term | Near-term | |
2.For a given application configuration management mechanism is the same independent of location (Central and Edge), including dynamic configuration support | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term Verizon- long-term Vodafone - long-term | Long-term | Clarification (added 4/11): The requirement indicates configuration management at both central and edge should be consistent. Having different mechanism to handle this at different site will be operational issue. |
| 3. In relation to No. 2, retain the capability to integrate with Central ONAP Policy and DMaap BusController (for secure topic/feed) | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term Verizon - long-term Vodafone - long-term | Long-term | Clarification (added 4/11): This is relevant to #6 and should be treated under same priority. This is also existing capability in ONAP and will be required for Day0 in the target architecture for backward compatibility to existing components (DCAE, Policy) |
4.Retain the ability to support TOSCA artifacts distributed from SDC and CLAMP. | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - near-term Verizon - long-term Vodafone - long-term | Long-term | Clarification (added 4/11): This is relevant to #5 and should be treated under same priority. This is also existing capability in ONAP and will be required for Day0 in the target architecture for backward compatibility to existing components (DCAE, SDC, Policy, CLAMP). It is not mandatory to follow existing workflow. With regard to TOSCA support, the relevant standard is ETSI SOL 001. |
5.Design flow integration (SDC, DCAE-DS) and Standardized configuration modelling support by Central Orchestrator | AT&T - near-term Bell Canada - near-term Orange - near-term Swisscom - near-term Verizon - near-term Vodafone - near-term | Near-term | Applicable only to management applications (Analytics, 3rd party etc.) which are on boarded after the basic ONAP components are up and running. |
6.Dynamic Control Loop flow deployment and support through CLAMP/Policy Integration by Central Orchestrator | AT&T - near-term Bell Canada - long-term Orange - near-term Swisscom - long-term Verizon - long-term Vodafone - near-term | Near-term vs Long-term tie | Applicable only to management applications (Analytics, 3rd party etc.) which are on boarded after the basic ONAP components are up and running. Additional Clarification – If the application is using ONAP Control Loop flow, then it shall follow the approach suggested by CLAMP framework. |
7.Multi-tenant infrastructure management - Install relevant K8S clusters if they are not already present. | AT&T - near-term (for both a and b) Bell Canada - N/A - not an ONAP accountability. Orange - NO. No the ONAP purposes according to us. Swisscom - not in ONAP scope Verizon - near-term Vodafone - near-term | Tie - 3 near-term, 3 No | Clarification – This also includes installation of other relevant VIMs (OpenStack etc.) besides K8S if needed. Can use open source K8S cluster API effort (https://github.com/kubernetes-sigs/cluster-api) as applicable to bring up K8S clusters on various Clouds (Amazon, Azure, OpenStack, VMware etc.) |
8. Support for non-K8S based workload deployment | AT&T - near-term Bell Canada - long-term Orange - long-term Swisscom - long-term Verizon - near-term Vodafone - long-term | Long-term | Clarification – This is the ability for ONAP to deploy applications across heterogeneous env (k8s, openstack etc) |
Architectural Options:
Discussion Kick off:
...
Consensus on Requirements (Arch. sub committee presentation/discussion - 04/16/2019)
...