The table bellow describes the problem and how it is or isn’t addressed today
Scenario | External system to be provisioned | Baseline approach | Reflections |
|---|---|---|---|
Connection to cloud infra | Address and capabilities of VIM managers (e.g. openstack port) | Mult-VIM: will register infrastructure site/location/region and their attributes and capabilities in A&AI, including compute, storage, networking (including local and vendor SDN controllers) etc. | |
| VID: manually input the VIM addresses and connection information to the portal, and sent this info to MSO which later call controllers which interact with all of these systems (VNFMS , VIM , EMS) | |||
| VF-C: query VIM addresses from ESR | |||
| SO: ? | |||
Connection to transport | SDN controller address’s and capabilities | ONAP SDN-C: ? | |
Connecting to S-VNFM | S-VNFM and capabilites | VF-C: query S-VNFM addresses from ESR | |
| Connection to EMS | EMS address and capabilities | APP-C: ? | |
| Other |
Attached is the comments about ESR:
Stephen:
I think its best to take a step-back a little before any assumptions on the architecture. The intention behind the ESR was to be able provision ONAP with external addresses that it may need to contact. In the breakout, I think it was clear that ONAP needs to be provisioned with external addresses, the question came to how, what can be done in the baselines and what are the system impacts. Then it was such that either this can be done in the baseline or it can’t, and if it can is there a better way to do it.
I feel it would be good to start the table with the scenario, what needs to be provisioned, statements about whether this can be done in the baselines, and if so how.
e.g.
+--------------------------------------+---------------------------------------------------------------------+-----------------------------------------------------------------------------------+-------------------------------------------------------------------+
! Scenario ! External System to be provisioned ! Baseline approach ! Reflections !
+--------------------------------------+---------------------------------------------------------------------+-----------------------------------------------------------------------------------+-------------------------------------------------------------------+
! Connecting to cloud infra ! Address and capabilities of VIM managers ! ? ! !
! ! (e.g. openstack port) ! ! !
+--------------------------------------+---------------------------------------------------------------------+-----------------------------------------------------------------------------------+-------------------------------------------------------------------+
! connecting to transport ! SDN controller address’s and capabilities ! ? ! !
+--------------------------------------+---------------------------------------------------------------------+-----------------------------------------------------------------------------------+-------------------------------------------------------------------+
! connecting to S-VNFM ! S-VNFM and capabilities ! ? ! !
+--------------------------------------+---------------------------------------------------------------------+-----------------------------------------------------------------------------------+-------------------------------------------------------------------+
! other ! ! ? ! !
+--------------------------------------+---------------------------------------------------------------------+-----------------------------------------------------------------------------------+-------------------------------------------------------------------+
Mazin gilbert:
ONAP Portal provides an SDK to develop portals so that we have consistent authentication and common functions across ONAP. Have you check it out?
Also if this is a subproject of A&AI, it does not seem that way from the functional architecture
Brian:
This table is confusing since it is using the term SDN-C for both the ONAP SDNC and VIM sdn local controllers.
Its not clear to me that the sdn controllers are valid ESR end points since in fact we could be using BGP and non-rest api interfaces for some of the communication between controllers depending on the network function being used.
When the network function is associated with non-real time provisioning we also likely would not have a direct SDNC to local controller interface but rather use the HEAT /ARM template interfaces to communicate the information needed to the local controller on required networking (OS::Neutron for instance in HEAT)
HU BIN:
Agree with Brian, and the table is confusing.
The Provider Registry in the Multi-VIM will register infrastructure site/location/region and their attributes and capabilities in A&AI, including compute, storage, networking (including local and vendor SDN controllers) etc.
See https://wiki.onap.org/pages/viewpage.action?pageId=3247262
So we have an interface to A&AI for registration.
While I understand that ESR intends to be a subproject of A&AI, ESR and A&AI should work out details about how ESR can be an effective component in A&AI. From Multi-VIM perspective, we will register to A&AI unless more details have worked by A&AI and ESR for such registration interface.
Avi :
Additionally , in the table VID is mentioned to integrate with VIM , VNFM etc, which in fact in calls MSO which later call controllers which interact with all of these systems (VNFMS , VIM , EMS).
Claude:
Seems like there are provider-related data elements that might not fit “logically” into an A&AI schema…
Examples:
. access-control and policy things -- credentials/certs, rights profiles, provider-granted entitlements, even perhaps session keys (noting that some of this falls under the existing category of “registration”)
. resource or capability indicators that describe *potential* capabilities -- “GPU can be requested”, “maximum cores/instance = 64”, …
Does it make sense to persist these sorts of things directly within A&AI, or in some external store that is referred to by A&AI-resident objects -- perhaps there’s one for each cloud service provider, its regions/zones, and so on -- so that there’s always a way to discover functionality and apply local policy, but in a way that couples fairly loosely with A&AI?
Brian RE Claude:
But why wouldnt that just be different data models in A&AI for the domain that you indicated ?
We dont need more data stores.