Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Consolidated Multi-Cloud workshop proposal to simplify scheduling

...

  • Description: Discuss goals, challenges and approaches to define an ONAP modeling long-term strategy (R2 and beyond), with the emphasis on E2E service automation, in sync with long-term architecture and driven by ONAP Service Provider requirements, and the short-term tactics (R2) in support of the long-term strategy; consider requirements, architecture, info models, data models, and DSLs in this order, and discuss the landscape of standards and open source communities contributing to them. Make specific long-term strategic, as well as specific short-term tactical recommendations for ONAP and other SDOs/open source communities.
  • Topic Leader: Michael Brenner, Cloudify, michael@cloudify.co
  • Volunteer Note Taker: First Last  email
  • Estimated Duration: 1.5 hrs
  • Link to data Source (if applicable)
  • Interested to attend:

Workshop Title:   ONAP Multi Cloud Architectural vision for R2 and beyond

Goal:                               Advance Multi Cloud beyond the current proxy implementation to address ONAP platform level issues across all use cases

Moderator(s):     Workshop Lead:            VMware, Wind River

Primary Contact:           Ramki Krishnan, VMware, ramkik@vmware.com

Estimated Duration:      3 hrs.

Desired Scheduling:     Before Architecture and TSC meetings. After lunch scheduling is desired since some folks are connecting from US and may not be able to attend in person. 

...

...

Subtopic 1:   Multi-Cloud Architectural Vision Introduction

Description:   This session will focus on discussion of the evolution of the Multi-Cloud framework for R2 and beyond, to address some of the platform gaps and move towards a more extensible and consistent cloud mediation layer. We would like to introduce a few key focus areas for this evolution, both in term of the use cases, architectural design principles, and integrations.

Architectural focus: Model Driven API for cloud infrastructure, Standardized cloud telemetry management, and policy driven cloud agnostic deployment.

Deep-dive topics subtopics (2, 3 and 4) towards achieving this vision are listed below for convenience

  • Standardized Infrastructure class statistics Model
  • Towards a performance-aware and portable cloud-agnostic infrastructure
  • Architectural options for Multi-vendor SDN Controller and Multi Cloud Deployments in a DC

Suggested Audience:     ONAP ONAP-OF, OOM, SDN-C, SO, VF-C, APP-C, DMaaP

Estimated Duration:        2 hrs.

Desired Scheduling:       Before topics 2, 3, 4, Architecture and TSC meetings.

Topic Lead               :       VMware

Interested in Attending:

...

 1.5 hrs

Subtopic Lead:                 VMware

Presenters:                       AT&T, VMware, Wind River, Intel (to confirm)

Subtopic 2:   Standardized Infrastructure Class statistics Model

Description:                   This session will focus on a hierarchical cloud-platform-aware architectural framework with separation of collection, storage, processing functions and real-time vs historical analytics components. In this framework, Multi Cloud will deliver a standardized infrastructure class statistics model for driving ONAP component/VNF placement/change management across distributed DC multi cloud instances through ONAP-OF, DCAE and other components. The benefit to ONAP platform, across all use cases, will be delivering the best performance and security while minimizing cost.

Suggested Audience:     ONAP ONAP-OF, DCAE, A&AI, Policy, OOM, SDN-C, DMaaP

Estimated Duration:        1  .5 hrs.Desired Scheduling

Subtopic Lead:           After Topic 1 and Before Architecture and TSC meetings.Topic Lead               :       AT      AT&T

Presenters:                 :       VMware, Wind River, AT&T, Intel

Interested in Attending:

Wind River, AT&T, Intel

Subtopic Topic 3:  Towards a performance-aware and portable cloud-agnostic infrastructure

Description:                    Multi-vendor cloud portability and interoperability while delivering performance is a mandatory feature of distributed DC deployments. The practical challenge in achieving this goal is the lack of standardization of Platform-aware and QoS features, for example extra specs in OpenStack, which results in a vertically integrated solution. This session will focus on how Multi Cloud can offer policy standardization and translation as a microservice for platform-aware and QoS features (hard-guarantee, min-guarantee, best effort etc.) for addressing this challenge and how NFV application classes such as IMS/EPC Control/Data Plane can benefit from this framework.

Suggested Audience:    VNF   VNF Requirements/Modelling, A&AI, Policy, SO, VF-C, APP-C, SDC

Estimated Duration:       1  .5 hrs.

Desired SchedulingSubtopic Lead:         After Topic 1 and Before Architecture and TSC meetings.Topic Lead               :        Bin Yang, Wind River, bin.yang@windriver.com Presenters               :      Wind River, Intel, VMware (to confirm)

Interested in Attending:

Presenters:                      Wind River, Intel

Subtopic Topic 4:   Architectural options for Multi-vendor SDN Controller and Multi Cloud Deployments in a DC

...

Estimated Duration:       1 .5 hrs.

Desired Scheduling:      After Topic 1 and Before Architecture and TSC meetings.

Topic Lead               :      VMware

Presenters               :      Huawei, AT&T (to confirm), VMware, Intel

Interested in Attending:

...

Subtopic Lead:               AT&T

Presenters:                     AT&T, Intel, Huawei, VMware


Kubernetes vs Dockers Swarm supporting ONAP-OOM on multi-cloud multi-stack environment

Description:  ONAP was set originally to support multiple container platform and cloud through TOSCA. In R1 ONAP and OOM is dependent completely on Kubernetes. As there are other container platforms such as Docker Swarm that are gaining more wider adoption as a simple alternative to Kubernetes. In addition operator may need the flexibility to choose their own container platform and be open for future platform. We need to weight the alternatives and avoid using package managers as Helm that makes K8s mandatory.

...

Amsterdam Release Lesson Learned

...