Here is In the quick meeting note from our weekly meeting last week
1: PTL election started on Thursday and concluded on Saturday. Xinhui was voted as PTL. Congratulations Xinhui!
2: MultiCloud release planning page has been setup. https://wiki.onap.org/display/DW/Multi-Cloud+Release+1+Planning
- Gil has volunteered to create functionality requirement for release 1 in terms of epics and user stories. The release planning page is already hooked with JIRA. Once Gil populated the information into JIRA, we will be able to review and decide on what to include for R1.
3: Discussed release 1 target architecture
- Danny took action item to update the slide. This is done, see attached slide 2 and 3.
- Committers and volunteers are needed to dedicate time next week to work on release 1 target architecture (slide 2). The consensus is that the architecture should focus on enabling minimal feature set supporting the sequence flows of vFW, vDNS, and vEPC use cases
Please send email to Xinhui, the newly elected PTL, and cc everyone in this email list, if you like to contribute.
- Slide 3 describes one possible approach for R1 API design. The main goal is to maintain OpenStack API compatibility while evolving towards a common API framework. Robert, Bin H, and Danny will discuss this further. Anyone who is also interested in this, please let us know.
4: Given R1 tries to keep OpenStack compatibility, it is relatively straightforward for most cloud providers who support OpenStack already. Eric and Andrew will work on a proposal to incorporate Azure into R1.
past committers’ meeting (Beijing time from 11:00PM to 12:27PM, July 3), the team come to below agreements:
(1) Implementation for backward compatibility, which primarily for compatibility with vanilla OpenStack and VF-C:
The team feels that it may not be practical for SO, APP-C, VF-C, and DCAE team to make significant changes to their SBI in R1, so this approach is proposed to allow these components to integrate with Multi VIM/Cloud with relatively small changes considering they all rely on OpenStack API directly or indirectly. Also, as some of these components today rely on OpenStack Kilo version, the team will need to look into version compatibility with the more recent versions such as Mitaka and Ocata. VF-C could continue to leverage Multi VIM/Cloud.
(2) provide a framework to provide restful services:
In addition to backward compatibility, some new capabilities are expected to be introduced in R1 of Multi VIM/Cloud. Cloud provider registration into A&AI is an obvious must-have. VES integration is also planned in R1 for pushing FCAPS data from cloud providers into DCAE.
To support backward compatibility, the framework will provide primarily OpenStack API pass-through/proxy functions in R1. There are still various implementation details need to be flushed out, which is likely the case with most projects at this stage. The team will follow-up to identify the tasks and move ahead towards to support all these components. We do hope everyone to use, but not required for R1 and other components may or may not use it in R1 based on their own discretion.
Ultimately, the team would like to have all these components, SO, APP-C, VF-C, DCAE, SDN-C, to take advantage of a common API layer. The complete design of the common API layer is likely to be realized through the course of a few ONAP releases, and could involve code refactoring amongst some or all of these components. The plan is to work with all these teams to make sure the approach has been fully vetted and the transition does not break their functionality. 5: Once we have finalized the use case (epic and story), architecture, and API design, we will start mapping out release milestones.