It sounds like the immediate-term goal is just to provide a nearly-transparent wrapper around OpenStack API structures. This would evidently leverage Keystone (or some service-catalog function that is very Keystone-like) to return appropriate endpoints based on metadata according to "specific parameters (coming from AAI)".
That said, it's not clear how we intend to bridge this approach to multi-VIM scenarios in the sense of providers that aren't OpenStack or even OpenStack-like. It makes sense that the crawl-walk-run approach would dictate doing what we already know how to do (OpenStack API) first – but it is important to keep an eye on the near-horizon, where commercial CSPs and other private-cloud implementations are going to be of direct relevance. Is there a notion that it’d be possible over time to create OpenStack-like wrappers over other infrastructure providers, create custom Heat resources, and so on? Or are we more aligned with a move toward provider-neutral data models and abstracted API adapters? As a matter of personal opinion, I’d prefer the latter… but there could be fair reasons to take a different approach. Thanks! --Claude From: <[email protected]> on behalf of "[email protected]" <[email protected]> Date: Wednesday, July 5, 2017 at 12:40 PM To: "[email protected]" <[email protected]> Subject: [onap-discuss] [multicloud] Multi-VIM API We need to clarify the API definition. The Multi-VIM will be used by SO, APPC, VFC for Infra Resource and VNF LCM. SO, APPC, VFC will not use OpenStack direct API to request resource creation (using Heat or Nova API). SO, APPC & VFC will request the Multi-VIM API (to be defined). SO, APPC, VFC require some specific parameters (coming from AAI) to route towards the right VIM It is key to define the multi-VIM northbound API for the various components that will consume it. Regards, Eric _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
