ArchCom 2019-06-25

Ramki reported the progress on the work on the distributed edge.

• Presenting an approach for Frankfurt.
• "Installation of cloud is a seperate topic and not considered here.
• Two options:
  • Use OOM only (cloud native direction)
  • Extending DCAE orchestration (Tosca + OOM helm charts). Aligns with current DCAE management architecture.
• Proposal is that DCAE contiues with the DCAE controller; while the rest continues to use OOM.
• The meeting aligned that this is the assumption for frankfurt, and the target discussions will continue.

 

 

2019-09-05-28

• Ramki provided a verbal update
• Still work in progress
• Cloud region access information seems to be getting concesous based ok K8s ETCD).  Uses the Custom resource definitions - Could be part of the OOM project.
• There was a comment that the credentials has to be made available to multicloud, and this was in the thinking.  From a deployment do it will stored in ONAP central.
• It is showing the ONAP components that are deployed in which locations.
• Other onap components get retriev notifications.

2019-04-16 ArchCom

Ramki Presented:  https://wiki.onap.org/download/attachments/28379482/Management%20Orchestration_v9-arch-update-04-16-09.pptx?api=v2

This is a pictural representation of:

-https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+Arch.Task+Force-Distributed+Management%28ONAP+etc.%29+components#EdgeAutomationthroughONAPArch.TaskForce-DistributedManagement(ONAPetc.)components-RequirementsNeedingOperatorFeedback

 

This captures the Near-term requirements:

. (1) Central Consolidated view.

• Single plane of glass from a management perspective
• Any deployment we need to have a single view of what is deployed centrally (e.g. what is deployed centrally and at the edge).
• There was a question about whether the centralized view would show what is centralized and what is distribued for the management applications, then answere was yes, and how the relationship is.
• There was a question about what the "3rd party" meant.  Its general, though the thinking is around e.g. analytics applications
• There were questions about the 2VMs Secondary", and this was refering to the K8s efforts to also support VMs.

(5) Central Design Flow integratin (excludes basic ONAP components e.g. SO)

• SDC Helm Integration
• There is two parts is that 1. this is helm charts and 2. that SDC can intergrate it.
• It was clarified that TOSCA was required for backwards compatbility.  The response was that is correct, the TOSCA integration for DCAE backwards compatability was more long term.
  • The interpettaion is that the DCAE components could be designed in SDC with HELM and TOSCA.
  • meaning some DCAE components can be integrated with HELM and some with TOSCA and be deployed together.
• It was clarified that SDC does design the "management applications" today.
• It was agreed to capture the TOSCA design integration as well.

(6) Central Conrol Loop Flow Integration

• CLAMP Helm integration
• "Central" Control Loop Flow means central to edge, meaning a control loop from edge to meaning that some of the ONAP compenent can be at the edge or it could be central.  The inital focus is keeping policy, SDC, etc central,  with analytics at the edge.  Other distribution is FFS.
• The design is central.
• There was a discussion about what happens when the rest is moved to the edge.
• The conclusion was keeping as a connected edge and keep it to DCAE and DCAE applications.

(7) Install Relevant Cloud (K8s or other) if not present

• Consider setting up the VIM if its not their.
• It was said to be seperate this and take it out of scope of the task force.

(1) (5) and (6) were accepted as short term requirements.

Long Term:

(4) SDC/CLAMP TOSCA, but this moves to "near term"

(2) The configuration of the DCAE  and applications should use the same configuration mechanism irrespective of whether its "Helm" based or "TOSCA" based.

• There was a discussion about examples and the mechanisms.  HELM can do configuration, but there is also configuration services in DCAE.
• It was noted that there were different types of configuration.  basic component configuration, or application behaviour configuration.

(3) In relation to 2, Use the same config mechanism, integrated with ONAP Policy and DMaaP.

- 

(8) Non K8s deployments for the managemend components

 

Next step, continue the function

 

2019-04-02 subcommittee F2F

Ramki presented the work from the Edge orchestration task force.

• Mentioned that there is the OOM controller and the DCAE controller
• Focussed on Analytics functions at the edge, cloosed loop functions at the edge, support 3rd party management components, geo-redundancy support
• There is alignment about using cloud native K8S for addressing current
• There was a question about the application configuration of applications at the edge, and whether this task force was looking at it.
• Coming back to ArchCom with requirements and architecture

Mike Elliot presnted OOM:

• the mechanisms should be the same irrespective of whether its the edge or not.
• mike presented the OOM capabilites and what is in and out of scope

Vijay presented the DCAE architecture and evolution

• Want to retain the capability as this evolves.
• Presented an enhanced OOM proposal to hande DCAE
• Mentioned to use Rancher, and mentioned to replace it with cloudify. It was clarified that infrastructure is outside of ONAP, and Rancher is a possible (reference) tool to use. 
• Avoide the scope creep to formally include infrastructure deployment
• Functionally this is including the capabilities to setup the DCAE components in the centralized ONAP controller.

Still to come back.

 

2019-03-26 ArchCom

Ramki gave a short update, in preparation for the F2F meeting to be held at the sub-committeees meeting: https://wiki.onap.org/download/attachments/50202249/Management%20Orchestration_v6-arch-update-03-26-2019.pptx?api=v2

 

2019-01-29 Archcom

Ramki walked through: https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components

Ramki indicated that he has more feedback and as a result cleaned up and clarfiied the table.

Management workloads: Edge using certain ONAP management workload functions as an Offload.

• Offload means placed at the edge.
• There were questions on trying to understand the scenarios that were explained
• Explain "offload term" and "VPC" term as well as that it is an IaaS approach
  • There were comments that offload can be offload to accelerators so another term such as placement could be used.
• Clarify that the "Edge and central provides" are different is that the central provider is still managing the management and central functionality running at the edge, but using another operators infrastructure.
• Staring the requirements and considerations.  Take this next week.

2019-01-22 Archcom

Ramki walked through: https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components

It describes 4 scenarios in 2 dimensions.

• Edge is orchestrated by ONAP; Edge is not orchestrated by ONAP

• Edge provider and Central provider are the same; or not

Ramki is calling for operator input on the priorities for the scenarios. Allow a few minutes next week to go over the priorities.

 

 

2019-01-15 Archom

Ramki Walk through https://wiki.onap.org/display/DW/Distributed+Management+%28ONAP+etc.%29+components  to go over the definition of the task force.

• Come back with the architectural scenarios
• Come back with the architectural options.

 

2018-12-18: Archcom.

Walked through the following slides https://wiki.onap.org/download/attachments/8225716/ONAP%20Arch%20input%20-%20Edge%20Analytics-ramki-srini-2%20.pptx?api=v2 

•  Propoposal to have any type of analytics framework and to be able to instantiate any anlytics applications.
• show that onap can deploy and configure frameworks in various cloud regions (Big data AF), prometheus AF
• Prove that ONAP can deploy one example application (preferable ML based)
• Use the terms "Managed application" or "management applications"
• Consider whether its deployed in the managed or management environment.
• We need to be able to plug in different management applications into ONAP.
• Srini: There is two types of analytics applications.  1. VNF specific and 2. ONAP specific.
• Vimal: Not in alignment.
• Seperate the question of alignment of DCAE controller and OOM; from the question of what the analytics is.
• Action: Initate a action regarding looking into DCAE controller and OOM.
• The term non-ONAP management functions to represent management functions that do not come from ONAP.
• OOM will need to understand cloud regions etc.
• Long Term: Edge analytics seen as a management function.  same approach for other management functinos (controllers)
• Need a way to deploy management applications that are outside the ONAP scope.
• Alex: operational issues are important.  Treating it like a VNF may challenge that.

 

 

2018-10-29 Arc Dublin F2F:

Srini presented these slides with support from Ramki and Margaret.

Proposes concrete work-items for Dublin timeframe, together with several items to study.

There was a question regarind the PDNA help charts, the answer was no.

Infrastructure is currently out of scope.

There was good alignment on the scope of dublin and recognition for the items to discuss in the dublin timeframe.

 

 ----

2018-10-23 Arch subcommittee:

Ramki Presented: << link >>

• Slide 3, is an example, but its model driven.
• Slide 5: There was a question whether the "edge infra" requirements are specific for the edge.  The discussion was that these are more accentuated at the edge.
• The presentation was appreciated.  There were some requests to ensure that the requirements are general.
• Slide 10 captures resulting requirements.
• Question regarding Akraino relationship in terms of commitment implications.