Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

In the 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. 


  • No labels