The table bellow describes the problem and how it is or isn’t  addressed today

Stephen:

Based on the above, I understand that the Functionality that ESR provides is to enable a common means to input the addressing information required to enable ONAP to contact these external systems.  That functionality does seem like a good idea.  If we turn our attention to what is required, this seems to required:

• A means to input the addressing information
• A place to store the addressing information
• A means for the ONAP modules to retrieve this information.

A assume the means to input the addressing information should be using the SDC environment, I mean it isn't optimal to have another creation environment with a different look and feel.

Part of the discussion as I understand is to store this information into A&AI, actually it is kind of static inventory information - is this a decent fit - it could be better than having yet another storage to deal with.

If the above was correct, then I guess that ESR somewhat becomes a proxy for the address information, is that required or could that be directly retrieved from the storage instead, and the ESR project focusses on creating the module required in SDC to input the data and place it in the storage instead of having a proxy?

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

RE: Stephen

Actually, SDC has nothing to do with ESR. SDC runs at the design time, while ESR runs at the run time. ESR provide a portal for user to input the external system address information. 

The data stored to A&AI from ESR included the addresses information and the status of external system. In my opinion, it is just like the instance data stored in A&AI.

We have reached an agreement with Jimmy(the PTL of A&AI) that ESR team will be committed to working the necessary A&AI features and interface agreements to support making A&AI the datastore for ESR data.  The portal and update functions can be a separate microservice and would use A&AI as the database.

ESR meeting information

Time: wednesday(9 PM China, 1 PM UTC, 9 AM US/Eastern, 5th July )

ONAP Meeting 7 is inviting you to a scheduled Zoom meeting.

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/434830725

Or iPhone one-tap (US Toll):  +16465588656,,434830725# or +14086380968,,434830725#

Or Telephone:
   Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
   +1 855 880 1246 (US Toll Free)
   +1 877 369 0926 (US Toll Free)
   Meeting ID: 434 830 725
   International numbers available: https://zoom.us/zoomconference?m=Va3Jg8p0-BZUnCV0JLW90sn3ozepN21M

Attached is the comments about ESR:

Email from LIZI: Call for feedback about interaction with External Register System

After discussion about the ESR in the subgroup in the F2F meeting in Beijin. We got a consquence that ESR is necessary. But since we do not clear about the business detail of other projects, such as VID/Multi-VIM/VF-C/SO/SDN-C etc. So we may do not clear that which projects will interact with ESR or whether the project has seed code of the function which ESR supplies. This is why I am reaching out.

Here, I would like to emphasize about the scope of ESR again, and do some clarification about some points. 

1. ESR will supplies both portal and API to manage(register/query/delete/update) the external system,  but will not deploy the external system. (Here external system means that the systems already exsist somewhere, but not included in ONAP, such as VIM/VNFM/EMS/vendor SDN controller)

2. ESR will check whether the external systems are reachable, but will not do the fault analysis.

For the project description and the scope of ESR, you may visit https://wiki.onap.org/pages/viewpage.action?pageId=5734948 

The sequence diagram bellow shows what we think about the interaction between ESR and other components in high level. But we still need to confirm it with VID/A&AI/Multi-VIM/SO/VF-C/APP-C/SDN-C team in the detail business scenario.

Here I listed a table about the ONAP project and its related external systems (if I am wrong please correct me). 

Briefly, according to the comments about ESR in the F2F meeting in Beijin. I need you guys give a feedback about whether your components will interact with ESR about the external systems OR how the function of ESR is realized in your component( if you do have the function of 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. 

This needs to be filled out:

e.g.

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

LiZi: 

Yes, we will fix our seed code to support the consistent authentication based on the Portal SDK

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)

LiZi: 

ESR will not be located and responsible for the communication between controllers. But just supplies a way to tell the other components where the vendor SDN controllers are, and also the basic information which will be used while contact with the vendor controller. 

The vendor sdn controler which is managed by VIM do not fit for ESR. But I am wondering whether there is any vendor SDN controller was managed by ONAP SDNC. In my opinion those vendor sdnc which managed by ONAP SDNC may be valid for ESR.

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.