Re: [onap-discuss] MultiVIM identity url and underlying VIM identity url, RE:08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2

[li.zi30]

Hi Guys,




I found that you are talking about about the VIM information can be both 
inputed by ESR and VID. I feel confusing too. So hope this problem could be 
clarified at VID weekly meeting. The meeting information attaches bellow.




Thanks,

LiZi




[vid] Team ONAP5 Mon UTC 13:00 / China 21:00 / Eastern 09:00 / Pacific 06:00

MondayUTC 01:00 PMChina 09:00 PMEastern 09:00 AMPacific 06:00 AM

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


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


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


Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
+1 855 880 1246 (US Toll Free)
+1 877 369 0926 (US Toll Free)
Meeting ID: 167 433 926
International numbers available: 
https://zoom.us/zoomconference?m=mwsbUS78bJnISsV3I53VPekYg0oefEud











原始邮件



发件人： <bin.y...@windriver.com>
收件人： <rx1...@att.com> <lxin...@vmware.com> <ts4...@att.com> <vg4...@att.com> 
<sa4...@att.com> <ry3...@att.com> <js9...@att.com> <rk5...@att.com> 
<bh5...@att.com> <cl6...@intl.att.com> <marcus.willi...@intel.com> 
<alex....@intel.com> <ah4...@att.com> <vr7...@att.com> <pn8...@att.com> 
<pb0...@att.com> <kw5...@att.com>李滋00164331 <ethanly...@vmware.com> 
<ha0...@att.com> <bf1...@att.com> <pm3...@att.com> <alex....@intel.com> 
<av...@amdocs.com>
抄送人： <pdrag...@research.att.com> <c...@research.att.com> <jc2...@att.com> 
<gn4...@intl.att.com> <bf1...@att.com>
日 期 ：2017年08月18日 10:20
主 题 ：RE: MultiVIM identity url and underlying VIM identity url, RE:08/15/17 - 
APPC/CDP-PAL/MultVIM - Touch Base 2







Hi Randa,


 


               That’s great. I like this approach.


 


               And the last point is not about APP-C to “support different  
types of cloud providers or different flavors of cloud” , My point is that 
there seems be some inconsistent between ESR and VID. I believe both of them 
provide portal to  register/input VIM’s information (identity 
url/username/password) and perhaps store those information differently, that 
might impact APP-C indirectly since eventually APP-C or policy will need to 
read these information. I saw Lizi (ESR PTL) had reached out  to VID team to 
sync with each other, so let’s see how this discrepancy being resolved. For 
now, we don’t have to worry about that too much.


 


Best Regards,


Bin Yang,    Solution Readiness Team,    Wind River


Direct +86,10,84777126    Mobile +86,13811391682    Fax +86,10,64398189


Skype: yangbincs993



 



From: MAHER, RANDA [mailto:rx1...@att.com] 
 Sent: Friday, August 18, 2017 9:21 AM
 To: Yang, Bin Xinhui Li SMITH, TYLER A GUDISENA, VARUNESHWAR ADDAGADA, SATISH 
YOUNG, RYAN J SEABOLT, SCOTT KOYA, RAMPRASAD HU, BIN LEFEVRE, CATHERINE 
'marcus.willi...@intel.com' VUL, ALEXANDER HAY, AARON DAVANGERE RAJASEKHAR, 
VEERENDRA  NGUYEN, PHIL BRADY, PATRICK D WONNELL, SKIP li.z...@zte.com.cn Ethan 
Lynn ANAPAN-LAVALLE, HECTOR A FREEMAN, BRIAN D MILLER, PAUL VUL, ALEXANDER 
av...@amdocs.com
 Cc: DRAGOSH, PAM GAO, CHENFEI CHOU, JOSEPH Y NGUEKO, GERVAIS-MARTIAL FREEMAN, 
BRIAN D
 Subject: RE: MultiVIM identity url and underlying VIM identity url, RE: 
08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2




 


Hi Bin,


For tomorrow’s meeting , Ryan and Scott will step through how it works in APPC 
using an incoming request to illustrate the key points. I think that may be the 
 best way to approach this.  We will also record the session.


 


I have also invited Pam from Policy team to join the call, if she can make it, 
since for the vCPE use case, APPC will be triggered via Policy as part of the  
closed loop and in that scenario, the full url would be passed to APPC by 
Policy. Changes to the URL will impact Policy and I’m assuming the changes to 
AAI are already in discussions with that team.


 


I’m not sure I completely follow all your points below, but if you’re referring 
to scope that would support different types of cloud providers or different  
flavors of cloud, etc..., then I agree with you, that is much larger challenge 
and taking it to architecture subcommittee may be the right place to start.


 


Thanks, Randa


 



From: Yang, Bin [mailto:bin.y...@windriver.com] 
 Sent: Wednesday, August 16, 2017 7:05 PM
 To: MAHER, RANDA <rx1...@att.com> Xinhui Li <lxin...@vmware.com> SMITH, TYLER 
A <ts4...@att.com> GUDISENA, VARUNESHWAR <vg4...@att.com>  ADDAGADA, SATISH 
<sa4...@att.com> YOUNG, RYAN J <ry3...@att.com> SEABOLT, SCOTT <js9...@att.com> 
KOYA, RAMPRASAD <rk5...@att.com>  HU, BIN <bh5...@att.com> LEFEVRE, CATHERINE 
<cl6...@intl.att.com> 'marcus.willi...@intel.com' <marcus.willi...@intel.com> 
VUL, ALEXANDER  <alex....@intel.com> HAY, AARON <ah4...@att.com> DAVANGERE 
RAJASEKHAR, VEERENDRA <vr7...@att.com> NGUYEN, PHIL <pn8...@att.com>  BRADY, 
PATRICK D <pb0...@att.com> WONNELL, SKIP <kw5...@att.com> li.z...@zte.com.cn 
Ethan Lynn <ethanly...@vmware.com> ANAPAN-LAVALLE, HECTOR A <ha0...@att.com> 
FREEMAN, BRIAN D <bf1...@att.com>  MILLER, PAUL <pm3...@att.com> VUL, ALEXANDER 
<alex....@intel.com> av...@amdocs.com
 Subject: RE: MultiVIM identity url and underlying VIM identity url, RE: 
08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2




 


Hi Randa,


 


               It will helpful to understand the context if you could give the 
concrete example of “full URL”, “incoming request”  “additional version in the  
URL” .


               If the full URL is for accessing MultiVIM identity service like 
“http://msb.onap.org:80/api/multicloud/v0/{cloudowner}_{region}/identity/v3”,  
I think it is available from cloud-region of AAI, you don’t need do extra 
transforming, but just pass it to CDP-PAL.


 


Since the intention we support “backward compatible API” is to minimize the 
burden on APPC by making MultiVIM as transparent as possible,  I hope all 
stakeholders (MultiVIM,APPC, AAI, ESR, VID, etc.) could coordinate to achieve 
that. I think something which make things complicated is beyond scope of APP-C 
and MultiVIM, the VIM information is the very example. If necessary, we can 
bring that question/issue  to Arch subcommittee and see how it could be 
resolved. But that will take much effort and time as well to discuss/negotiate 
between teams, so personally I hesitate to do that in R1. Please let me know 
your thoughts.


 


Thanks.


 


Best Regards,


Bin Yang,    Solution Readiness Team,    Wind River


Direct +86,10,84777126    Mobile +86,13811391682    Fax +86,10,64398189


Skype: yangbincs993



 



From: MAHER, RANDA [mailto:rx1...@att.com] 
 Sent: Thursday, August 17, 2017 5:40 AM
 To: Xinhui Li Yang, Bin SMITH, TYLER A GUDISENA, VARUNESHWAR ADDAGADA, SATISH 
YOUNG, RYAN J SEABOLT, SCOTT KOYA, RAMPRASAD HU, BIN LEFEVRE, CATHERINE 
'marcus.willi...@intel.com' VUL, ALEXANDER HAY, AARON DAVANGERE RAJASEKHAR, 
VEERENDRA  NGUYEN, PHIL BRADY, PATRICK D WONNELL, SKIP li.z...@zte.com.cn Ethan 
Lynn ANAPAN-LAVALLE, HECTOR A FREEMAN, BRIAN D MILLER, PAUL VUL, ALEXANDER 
av...@amdocs.com
 Subject: RE: MultiVIM identity url and underlying VIM identity url, RE: 
08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2




 


Hello Bin,


 


For APPC, the assumption is that the full URL would be coming from A&AI or the 
incoming request  APPC would pass that down to CDP-PAL.


The initial assumption for APPC was that MultiVIM would be transparent, but 
then we understood that we needed to support an additional version in the URL, 
so  we prepared to make some changes to support different format on URL.  
Anything other than these base assumptions,  we cannot support in R1. I don’t 
have capacity


 


We can discuss this in more details tomorrow on touch base call and go through 
each of the points below.


 


Thanks, Randa


 



From: Xinhui Li [mailto:lxin...@vmware.com] 
 Sent: Wednesday, August 16, 2017 6:42 AM
 To: Yang, Bin <bin.y...@windriver.com> MAHER, RANDA <rx1...@att.com> SMITH, 
TYLER A <ts4...@att.com> GUDISENA, VARUNESHWAR <vg4...@att.com>  ADDAGADA, 
SATISH <sa4...@att.com> YOUNG, RYAN J <ry3...@att.com> SEABOLT, SCOTT 
<js9...@att.com> KOYA, RAMPRASAD <rk5...@att.com>  HU, BIN <bh5...@att.com> 
LEFEVRE, CATHERINE <cl6...@intl.att.com> 'marcus.willi...@intel.com' 
<marcus.willi...@intel.com> VUL, ALEXANDER  <alex....@intel.com> HAY, AARON 
<ah4...@att.com> DAVANGERE RAJASEKHAR, VEERENDRA <vr7...@att.com> NGUYEN, PHIL 
<pn8...@att.com>  BRADY, PATRICK D <pb0...@att.com> WONNELL, SKIP 
<kw5...@att.com> li.z...@zte.com.cn Ethan Lynn <ethanly...@vmware.com>
 Subject: Re: MultiVIM identity url and underlying VIM identity url, RE: 
08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2




 


+ Lizi, PTL of ESR


+ Ethan, focal for AAI integration


 



From: "Yang, Bin" <bin.y...@windriver.com>
 Date: Wednesday, 16 August 2017 at 6:06 PM
 To: "MAHER, RANDA" <rx1...@att.com>, "SMITH, TYLER A" <ts4...@att.com>, Xinhui 
Li <lxin...@vmware.com>, "GUDISENA, VARUNESHWAR" <vg4...@att.com>,  "ADDAGADA, 
SATISH" <sa4...@att.com>, "YOUNG, RYAN J" <ry3...@att.com>, "SEABOLT, SCOTT" 
<js9...@att.com>, "KOYA, RAMPRASAD" <rk5...@att.com>,  "HU, BIN" 
<bh5...@att.com>, "LEFEVRE, CATHERINE" <cl6...@intl.att.com>, 
"'marcus.willi...@intel.com'" <marcus.willi...@intel.com>, "VUL,  ALEXANDER" 
<alex....@intel.com>, "HAY, AARON" <ah4...@att.com>, "DAVANGERE RAJASEKHAR, 
VEERENDRA" <vr7...@att.com>, "NGUYEN, PHIL" <pn8...@att.com>,  "BRADY, PATRICK 
D" <pb0...@att.com>, "WONNELL, SKIP" <kw5...@att.com>
 Subject: MultiVIM identity url and underlying VIM identity url, RE: 08/15/17 - 
APPC/CDP-PAL/MultVIM - Touch Base 2



 


Hi Randa and all,


 


               My questions or concerns are listed as below, maybe I didn’t 
catch the whole context since I was PTO last week, anyway it is good to double 
check  :


 


1, How does APP-C specify underlying VIM while issue request to MultiVIM.


So far my understanding is that APP-C will get the underlying VIM’s information 
( identity url/username/password) by looking up A&AI with the VNFID, So I guess 
 APP-C will pass these set of metadata to MultiVIM, is that correct? If I guess 
right, the “provider.MultiVIMProxy.identity.url” in the table below might refer 
to underlying  VIM’s identity url, not the MultiVIM’s identity url.


o     

CDP-PAL

In order to make expected 8/20 deadline, we will implement the following 
solution.

We will take in the following properties (actual values are subject to change, 
based upon discussion):


 


Property


Value Type


provider.isMultiVIMProxy


True/False


provider.multivimproxy.identity.password


String


provider.MultiVIMProxy.identity.url


URL


provider.multivimproxy.identity.username


String


provider.MultiVIMProxy.service.url


URL


·         Based upon those properties, we will route our API calls through the 
Mult


2, How does APP-C get the MultiVIM’s identity url?


The possible way I can see is that: by looking up A&AI,  APP-C look into the 
cloud-region via the VNFID, and with the cloud-region, you can fetch the 
MultiVIM’s  identity url.


               VNFID -> cloud-region -> MultiVIM identity url


 


Please refer to the proposed scheme change, the identity-url in cloud-region is 
the one you can use to interact with MultiVIM:


 


cloud-region


 


 


 


cloud-owner and cloud-region-id as compound key


 


cloud-owner


onap:cloud-owner


str


cloud owner name, e.g. att-aic


 


openo:vendor


 


 


 


cloud-region-id


onap:cloud-region-id


str


RegionOne


 


cloud-type


onap:cloud-type


str


type of the cloud, decides which multicloud plugin to use, openstack-ocata


 


openo:type


 


 


 


identity-url


onap:identity-url


str


http://msb.onap.org:80/api/multicloud/v0/{cloudowner}_{region}/identity/v3


 


 


If we are aligned with assumptions above, then I would like to point out 
another possible gap between APP-C and MultiVIM


 


3, what is the detail of identity API


The API detail concerns how APP-C(CDP-PAL) could pass the underlying VIM 
information .


The proposal MultiVIM preferred is to leverage the cloud-owner and 
cloud-region-id properties of cloud-region: (I refer it as a VIM_ID in the form 
of {cloudowner}_{region}).  So APP-C (CDP-PAL) puts them into the identity url 
like: 
http://msb.onap.org:80/api/multicloud/v0/{cloudowner}_{region}/identity/v3  , 
with this approach, APP-C(CDP-PAL) don’t need to pass the 
“provider.MultiVIMProxy.identity.url” (neither the associated 
username/password) , but just pass the cloud-owner  and cloud-region-id in the 
url.


 


However, it APP-C prefer the original way, that is , passing the underlying 
VIM’s identity url/username/password to MultiVIM in the request body, that is 
OK. 


My point is : this is be finalized and documented so that we can integrate each 
other smoothly.


 


 


BTW, another context  or myth (the information I got so far) that you might be 
interested to know is: Both ESR and VID provide portal to let user input VIM’s  
information(underlying VIM’s identity url,username/password,etc). So I guess 
there will be duplicated (if they do not collide) copies of information for a 
single underlying VIM: one is in the cloud-region->auth_info, another one might 
be somewhere associated  with the vnf  (Please correct me if my guess is 
wrong).  If my guess is correct, I think it makes little sense. Ideally I 
suppose ESR is the place to register an underlying VIM, and VID should select 
from the list of underlying VIM registered via ESR.  


 


 


 


 


Best Regards,


Bin Yang,    Solution Readiness Team,    Wind River


Direct +86,10,84777126    Mobile +86,13811391682    Fax +86,10,64398189


Skype: yangbincs993



 



From: MAHER, RANDA [mailto:rx1...@att.com] 
 Sent: Wednesday, August 16, 2017 9:33 AM
 To: SMITH, TYLER A 'Xinhui Li' Yang, Bin GUDISENA, VARUNESHWAR ADDAGADA, 
SATISH YOUNG, RYAN J SEABOLT, SCOTT KOYA, RAMPRASAD HU, BIN LEFEVRE, CATHERINE 
'marcus.willi...@intel.com' VUL, ALEXANDER HAY, AARON DAVANGERE RAJASEKHAR, 
VEERENDRA  NGUYEN, PHIL BRADY, PATRICK D WONNELL, SKIP
 Subject: 08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2




 


 All – here are my notes.


Also, for convenience, attached is xls updates last week by Tyler for openstack 
operation for Priority 1 items. 


These notes will also be posted here shortly: 
https://wiki.onap.org/display/DW/APPC+Meeting+Minutes 


Randa


 


 


08/15/17 - APPC/CDP-PAL/MultVIM - Touch Base 2




Monday, August 14, 2017


2:54 PM




Participants:


RANDA MAHER <rx1...@us.att.com> HAY, AARON <ah4...@att.com> TYLER SMITH 
<ts4...@us.att.com>  Marcus Williams <marcus.willi...@intel.com> SEABOLT, SCOTT 
<js9...@att.com> GUDISENA, VARUNESHWAR <vg4...@att.com> Veer Rajasekhar 
<vr7...@us.att.com>  ADDAGADA, SATISH <sa4...@att.com> Bin Yang 
<bin.y...@windriver.com> YOUNG, RYAN J <ry3...@att.com> xinhui li 
<lxin...@vmware.com>


 


Action Items


·       Need to confirm URL for testing - Randa & Xinhui to follow-up with 
Helen 


·       Tyler will work on Priority 2 items for openstack mapping by Thrus., 
8/17,


·       Ryan and Tyler to discuss how to handle endpoints and come back with 
expectations/assumptions to get all aligned.


·       Bin Yang to document all his questions/concerns and send in advance of 
this meeting so that we can discuss. There is an open action item on what 
exactly is getting populated  in A&AI. APPC get URL from A&AI.


 


Action Items from last week:


·       Confirm with MultiVIM team base url (Varun sent an email on this)


o    Please confirm the base url: base multicloud api call looks like : 
msb.onap.org:80/api/multicloud/v0/


o    Status: CLOSED. Confirm by Xinhui 


·         <<Re  APPC  - CDP PAL - MultiVIM Architecture Diagram.msg>>


Notes:


·       APPC Story:  APPC-131  - Ryan working on this one…


·       Tyler - coding change small, but testing is the larger scope- need to 
validate the various use cases


·       Bin - there are a lot of other dependencies that need to be in place 
before we can integrate test with MultiVIM: ESR, A&AI - However, to validate 
flow from APPC/CDP-PAL to  MultiVIM, we don't see a full blown end to end flow. 
Can we manually populate data in A&AI? AppC will look for URL for MultiVIM in 
A&AI


·       APPC does not hard code URL, it expects to get it with the reqeust


·       Need more clarification from MultiVIM team on plans to register with 
A&AI and what MSB has to do with plans - this was not clear. APPC assumption 
has always been that the full URL would be coming from A&AI or the incoming 
request anything else would need to be reassessed if it can fit into R1 at this 
stage.
_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss