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: <onap-discuss-boun...@lists.onap.org> on behalf of
"eric.deb...@orange.com" <eric.deb...@orange.com>
Date: Wednesday, July 5, 2017 at 12:40 PM
To: "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>
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
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
