[onap-discuss] July Virtual Developers Event Material and Survey

[Kenny Paul]

I have uploaded all of the presentations that I’ve been provided and the 
recordings for the Main Bridge and Bridge#1, (I do not have the Bridge#1 
recordings available to me yet).
If you have not already sent me your presentation materials, please do so.

Also I have posted a feedback survey to the event page so that we can get a 
better understanding of how you feel it went and what we can do to improve 
things in the future.
It is only 10 questions. I would greatly appreciate it if you can please take a 
moment to fill it out. https://www.surveymonkey.com/r/VY5C9XN 


Thank you!

Best Regards, 
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

[huang.zhuoyao]

Briand,

Is that means a new Jira issue about this should be raised before 
Funtionality Frezze August 3rd ?

Thank you!
















黄卓垚huangzhuoyao






职位position 
承载网管开发部/有线研究院/有线产品经营部Strategy & IT-IT Dept.









深圳市南山区科技南路55号中兴通讯研发大楼33楼 
33/F, R Building, ZTE Corporation Hi-tech Road South, 
Hi-tech Industrial Park Nanshan District, Shenzhen, P..R.China, 518057 
T: +86 755    F: +86 755  
M: +86 xxx 
E: huang.zhuo...@zte.com.cn 
www.zte.com.cn

 



原始邮件



发件人： 
收件人： 
抄送人：黄卓垚10112215  
日 期 ：2017年07月27日 00:26
主 题 ：RE: [onap-discuss] Here is a question about SDN-C adapter,wouldyouplease 
help me about it? Thank you!







Yes. Exactly.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 12:23 PM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would 
youplease help me about it? Thank you!




 


Brian, 



 



From your point, I think vendors should raise their input requirements , then 
SDNC get the parameters from somewhere and transfer them to the specific 
adapter via DG config node, right?





 Chengli 




 On 26 Jul 2017, at 11:57 PM, FREEMAN, BRIAN D  wrote:



Chengli,


 


I was thinking it would be option 2 – the adapters can be vendor specific since 
we will know the equipment type based on VIM inventory data as part of the DG.


 


It would be nice to have common inputs but we have had to deal with that before 
on other adapters. Its two separate config nodes btw – a WAN-VendorA config 
node and DCGW-VendorB config node.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 11:16 AM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would you 
please help me about it? Thank you!




 


Hi Brian,



 


As my understanding, Maybe we have two options to integrate 3rd SDN controller 
with SDN-C, please correct me if I am wrong.



Option 1, SDN-C can define the common interfaces should be followed by vendors 
adaptor, then the vendors can provide their specific adaptors to translate the 
common interfaces to their own special ones exposed by their commercial SDN 
controllers.



I think that is why Zhuoyao ask for your help to provide some inputs to 
adaptors. Is that correct, Zhuoyao?



 






Option 2, vendors can exposed their SDN controller(local controller/WAN 
controller) special north bound APIs directly to SDN-C, the config node of DG 
inside SDN-C can invoke the APIs directly. then there is no need to do the 
translation  in the adaptor. 







 


Also I know that no matter which one will be chosen, we still need some inputs 
to instance the network connection service between DCs.



The inputs may come from the network model or as the input parameters to the 
network instantiation action. What’s your suggestion?



 


Regards,



Chengli



 


在 2017年7月26日，下午8:05，FREEMAN,  BRIAN D  写道：



 


+1 onap-discuss



 


It hasnt been defined because we were waiting for input from Chengli on what 
API was expected to be used. We were told it would be a REST API to the vendor 
controller.



 


Chengli,



 


Could you add an example to the VoLTE wiki page like you did for the Overlay 
API ?



 


Brian



 


 


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Tuesday, July 25, 2017 11:14 PM
 To: FREEMAN, BRIAN D 
 Cc: TIMONEY, DAN  bo.kai...@zte.com.cn zhang.suj...@zte.com.cn 
feng.j...@zte.com.cn
 Subject: Here is a question about SDN-C adapter, would you please help me 
about it? Thank you!



 


Hi, Brian


 


Here is a question about SDN-C adapter, would you please help me about it?


Has the input of adapter responsible for underlay L3VPN between PEs been 
defined yet? If yes, is it  based on E2E model? And how we can know more detail 
about it? 


 


Thank you!


 


 


 


 


 


黄卓垚huangzhuoyao


 


职位position 
 承载网管开发部/有线研究院/有线产品经营部Strategy  & IT-IT Dept.


 







 深圳市南山区科技南路55号中兴通讯研发大楼33楼 
 33/F, R Building, ZTE Corporation Hi-tech Road South, 
 Hi-tech Industrial Park Nanshan District, Shenzhen, P..R.China, 518057 
 T: +86 755    F: +86  755  
 M: +86 xxx 
 E: huang.zhuo...@zte.com.cn 
 www.zte.com.cn



 








___
 onap-discuss mailing list
 onap-discuss@lists.onap.org
 https://lists.onap.org/mailman/listinfo/onap-discuss___
onap-discuss mailing list
onap-discuss@lists.onap.org

Re: [onap-discuss] [multicloud][so] block issue between SO and Mutl VIM/Cloud

[DeWayne Filppi]

Hi,
 It was my my understanding (told directly by Danny) that multi-VIM would
have an API interface and a HEAT interface, so there should be no blocker.
Aria can use an existing Openstack plugin.  TOSCA models more than
infrastructure and instantiates individual infrastructure components based
on relationships or requirements and capabilities.  Each TOSCA element has
associated actions, which include API calls, in addition to a runtime
state.  There is no phase in a deployment where all the infrastructure is
gathered up together where a HEAT template could be constructed, unless
something very ugly on the modeling side was done.  Again, given that there
is no blocker due to the fact that multi-VIM will have an API proxy.
Monday I'm only available after 11am PDT.

- DeWayne

On Thu, Jul 27, 2017 at 10:53 PM, Xinhui Li  wrote:

> Once on use case discussion meeting, I heard that adoption of heat is in
> order to avoid separated calls to nova, cinder, … and so on which are
> always evolving. Heat behaves as orchestrator of infrastructure layer. Is
> there any Heat adapter or converter to help this?
>
>
>
> Considering the function freeze date is close, we have to settle down the
> interface between two parties. Can you propose some slot next Monday to
> discuss the block issue? Thanks.
>
>
>
> Xinhui
>
>
>
> *From: *DeWayne Filppi 
> *Date: *Friday, 28 July 2017 at 10:55 AM
> *To: *Xinhui Li 
> *Cc: *"Jinxin (Saw)" , "wangchen...@chinamobile.com" <
> wangchen...@chinamobile.com>, "yangyan...@chinamobile.com" <
> yangyan...@chinamobile.com>, "zhonghe...@boco.com.cn" <
> zhonghe...@boco.com.cn>, Danny Lin , Ethan Lynn <
> ethanly...@vmware.com>, "Christopher Donley (Chris)" <
> christopher.don...@huawei.com>, DeWayne Filppi ,
> Byung-Woo Jun , "zhanganb...@chinamobile.com"
> , "wu.li...@zte.com.cn" ,
> "denghui (L)" , "DAUGHERTY, ROBERT E" <
> rd4...@att.com>, "zhang.zh...@zte.com.cn" ,
> Lingli Deng , "BULLARD, GIL" ,
> Chenchuanyu , "yangyuan...@boco.com.cn" <
> yangyuan...@boco.com.cn>, "Yang, Bin" , Andrew
> Philip , "Zengjianguo (OSS Design)" <
> zengjian...@huawei.com>, Seshu m , "CHOMA, JOHN
> S" 
> *Subject: *Re: Sync up between SO and Mutl VIM/Cloud
>
>
>
> Hi,
>
>
>
>  I think it makes more sense for the Tosca orchestrator to use the
> multivim api endpoint directly rather than Heat.
>
>
>
> DeWayne
>
>
>
> On Jul 27, 2017 7:23 PM, "Xinhui Li"  wrote:
>
> Hi Dewayne,
>
>
>
> We are looking forward to your sharing about this question.
>
>
>
> Thanks,
>
>
>
> Xinhui
>
>
>
> *From: *Seshu m 
> *Date: *Thursday, 20 July 2017 at 9:56 PM
> *To: *Xinhui Li , Danny Lin ,
> "Jinxin (Saw)" , "Zengjianguo (OSS Design)" <
> zengjian...@huawei.com>, Andrew Philip , "Yang,
> Bin" , "zhanganb...@chinamobile.com" <
> zhanganb...@chinamobile.com>, Ethan Lynn , "CHOMA,
> JOHN S" , DeWayne Filppi ,
> Byung-Woo Jun , "wangchen...@chinamobile.com"
> , "zhonghe...@boco.com.cn" <
> zhonghe...@boco.com.cn>, "zhang.zh...@zte.com.cn" ,
> Chenchuanyu , "yangyan...@chinamobile.com" <
> yangyan...@chinamobile.com>, "DAUGHERTY, ROBERT E" ,
> Lingli Deng , "wu.li...@zte.com.cn" <
> wu.li...@zte.com.cn>, "yangyuan...@boco.com.cn" ,
> "BULLARD, GIL" , "denghui (L)" ,
> "Christopher Donley (Chris)" 
> *Subject: *RE: Sync up between SO and Mutl VIM/Cloud
>
>
>
> Hi Dewayne,
>
>
>
> We have had a question to clarify for the VCPE Usecase w.r.t the way SO
> would pass the data to cloud.
>
> 1. Currently its confirmed by the Multi Vim that APPC would interact with
> Multi VIm only for the healing flow.
>
> 2. This would bring the same question we had last SO meeting on how ARIA
> engine based flow works with Heat calls, where,
>
>  I remember you were provinding some way the output of ARIA could be
> convereted to Heat.
>
>
>
> Please provide us your views
>
>
>
> Best Regards,
>
> Seshu
>
> 
> **
>  This email and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained here in any way

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

[huang.zhuoyao]

Hi Dan,


Is that necessary to raise a new Jira issue about it before Funtionality 
Frezze August 3rd ?


Thank you!



















黄卓垚huangzhuoyao






职位position 
承载网管开发部/有线研究院/有线产品经营部Strategy & IT-IT Dept.









深圳市南山区科技南路55号中兴通讯研发大楼33楼 
33/F, R Building, ZTE Corporation Hi-tech Road South, 
Hi-tech Industrial Park Nanshan District, Shenzhen, P..R.China, 518057 
T: +86 755    F: +86 755  
M: +86 xxx 
E: huang.zhuo...@zte.com.cn 
www.zte.com.cn

 



原始邮件



发件人：黄卓垚10112215
收件人： 
抄送人：   

日 期 ：2017年07月28日 09:03
主 题 ：答复: RE: [onap-discuss] Here is a question about SDN-C 
adapter,wouldyouplease help me about it? Thank you!






Briand,

Is that means a new Jira issue about this should be raised before 
Funtionality Frezze August 3rd ?

Thank you!
















黄卓垚huangzhuoyao






职位position 
承载网管开发部/有线研究院/有线产品经营部Strategy & IT-IT Dept.









深圳市南山区科技南路55号中兴通讯研发大楼33楼 
33/F, R Building, ZTE Corporation Hi-tech Road South, 
Hi-tech Industrial Park Nanshan District, Shenzhen, P..R.China, 518057 
T: +86 755    F: +86 755  
M: +86 xxx 
E: huang.zhuo...@zte.com.cn 
www.zte.com.cn

 












发件人： 
收件人： 
抄送人：黄卓垚10112215  
日 期 ：2017年07月27日 00:26
主 题 ：RE: [onap-discuss] Here is a question about SDN-C adapter,wouldyouplease 
help me about it? Thank you!







Yes. Exactly.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 12:23 PM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would 
youplease help me about it? Thank you!




 


Brian, 



 



From your point, I think vendors should raise their input requirements , then 
SDNC get the parameters from somewhere and transfer them to the specific 
adapter via DG config node, right?





 Chengli 




 On 26 Jul 2017, at 11:57 PM, FREEMAN, BRIAN D  wrote:



Chengli,


 


I was thinking it would be option 2 – the adapters can be vendor specific since 
we will know the equipment type based on VIM inventory data as part of the DG.


 


It would be nice to have common inputs but we have had to deal with that before 
on other adapters. Its two separate config nodes btw – a WAN-VendorA config 
node and DCGW-VendorB config node.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 11:16 AM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would you 
please help me about it? Thank you!




 


Hi Brian,



 


As my understanding, Maybe we have two options to integrate 3rd SDN controller 
with SDN-C, please correct me if I am wrong.



Option 1, SDN-C can define the common interfaces should be followed by vendors 
adaptor, then the vendors can provide their specific adaptors to translate the 
common interfaces to their own special ones exposed by their commercial SDN 
controllers.



I think that is why Zhuoyao ask for your help to provide some inputs to 
adaptors. Is that correct, Zhuoyao?



 






Option 2, vendors can exposed their SDN controller(local controller/WAN 
controller) special north bound APIs directly to SDN-C, the config node of DG 
inside SDN-C can invoke the APIs directly. then there is no need to do the 
translation  in the adaptor. 







 


Also I know that no matter which one will be chosen, we still need some inputs 
to instance the network connection service between DCs.



The inputs may come from the network model or as the input parameters to the 
network instantiation action. What’s your suggestion?



 


Regards,



Chengli



 


在 2017年7月26日，下午8:05，FREEMAN,  BRIAN D  写道：



 


+1 onap-discuss



 


It hasnt been defined because we were waiting for input from Chengli on what 
API was expected to be used. We were told it would be a REST API to the vendor 
controller.



 


Chengli,



 


Could you add an example to the VoLTE wiki page like you did for the Overlay 
API ?



 


Brian



 


 


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Tuesday, July 25, 2017 11:14 PM
 To: FREEMAN, BRIAN D 
 Cc: TIMONEY, DAN  bo.kai...@zte.com.cn zhang.suj...@zte.com.cn 
feng.j...@zte.com.cn
 Subject: Here is a question about SDN-C adapter, would you please help me 
about it? Thank you!



 


Hi, Brian


 


Here is a question about SDN-C adapter, would you please help me about it?


Has the input of adapter responsible for underlay L3VPN between PEs been 
defined 

Re: [onap-discuss] 答复: [Modeling][vfc] TOSCA Parser API Requirements

[Arthur Berezin]

Hi Yan,

I would like to follow up on this thread and gather feedback from the
discussion here.

The main request that comes up from the requirements document is to bring
back support for a REST API to ARIA, exactly as it was previously exposed
to Open-O NFVO, is this correct?

We are working on creating a native REST API to ARIA, and the
work-in-progress is expected to land soon.

ARIA is a Python TOSCA SDK so it natively supports using Python objects, To
get a complete Python reference documentation for ARIA you can just clone
the upstream project and build the Spinx docs

# git clone https://github.com/apache/incubator-ariatosca.git
# make docs
# firefox docs/html/index.html

The cool part is that it's that ARIA can execute the TOSCA Template based
workflows. Here is a basic hello world example of this works:


First, provide ARIA with the ARIA "hello world" service-template and name
it (e.g. my-service-template):

aria service-templates store examples/hello-world/helloworld.yaml
my-service-template

Now create a service based on this service-template and name it (e.g.
my-service):

aria services create my-service -t my-service-template

Finally, start a install workflow execution on my-service like so:

aria executions start install -s my-service

You should now have a simple web server running on your local machine. You
can try visiting http://localhost:9090 to view our deployed application.
-

Additionally, we want to have the ability to consume ARIA as a Java
in-process library and handle in-memory TOSCA objects, to traverse and
extract information natively in Java.

Currently, ARIA supports a complete CLI that can, among other things, emit
JSON based on the parsed graph. ARIA also allows accessing its storage
layer which is based on SQL, the SQL tier is another option for in-process
Java integration as this allows native access to all the TOSCA related
objects and artifacts, traversing thru the graph and others.

# aria service-templates show --json helloworld


I'm happy to provide reference examples for Java.


Arthur


On Mon, Jul 17, 2017 at 1:01 PM Kapeluto, Zahi  wrote:

> Hi Yan,
>
> My feedback:
>
>   *   Most of the ONAP components, some of them already consume our TOSCA
> parser (MSO, SDN-C, VID, SDN-GC), are Java-based hence require Java
> language invoke.
>   *   The common use-case we found is that components would like to
> consume the parser in-process, i.e. get it as a library rather than a
> service.
>   *   Our parser creates an in-memory JAVA representation of the model.
> The consuming component can then traverse over it and extract the
> information it needs. Can you explain why you would need JSON output?
>
> Here are the repos of out TOSCA parser:
> https://gerrit.onap.org/r/#/admin/projects/sdc/jtosca;
> https://gerrit.onap.org/r/#/admin/projects/sdc/sdc-tosca. We can discuss
> further if you’re interested in design concepts and architecture.
>
> Thanks,
> Zahi Kapeluto
> Lead Architect, Network Communications LOB
> AT Network Applications Development · SD
> Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
> ·
> Mobile: +972 (54) 6636831 <+972%2054-663-6831>
> Office: +972 (3) 9280064 <+972%203-928-0064>
>
> From:  on behalf of 杨艳 <
> yangya...@chinamobile.com>
> Date: Friday, 14 July 2017 at 3:15
> To: 'Thomas Nadeau' , "'denghui \\(L\\)'" <
> denghu...@huawei.com>, 'onap-discuss' 
> Subject: [onap-discuss] 答复: [Modeling][vfc] TOSCA Parser API Requirements
>
> Hi Tom,
>
> Thanks for your suggestion, I have uploaded the document to the wiki
> https://wiki.onap.org/display/DW/VF-C+R1+Deliverables<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_VF-2DC-2BR1-2BDeliverables=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=Tb4B9h_-wR6nA2dMKyowUg=5Bw4qKyovq7EervinsZZT6r_C95YpsK1FjWB9Gbig8Q=DUEr4Tfnyhij1etU9TdUQu7-q9nZZpl9IpSmsbMeNWI=>,
> If there is any feedback that need to update the document, I will update to
> the wiki page.
>
> Best Regards,
> Yan
> 发件人: Thomas Nadeau [mailto:thomas.nad...@amdocs.com]
> 发送时间: 2017年7月13日 19:14
> 收件人: 杨艳; 'denghui \\(L\\)'; onap-discuss
> 主题: RE: [onap-discuss] [Modeling][vfc] TOSCA Parser API Requirements
>
> Can you please post the document onto Jira somewhere rather than mailing
> it around?  That will allow everyone to look at the same version until its
> changed.
>
> --Tom
>
>
> From: onap-discuss-boun...@lists.onap.org [mailto:
> onap-discuss-boun...@lists.onap.org] On Behalf Of ??
> Sent: Thursday, July 13, 2017 6:53 AM
> To: 'denghui \\(L\\)' ; onap-discuss <
> onap-discuss@lists.onap.org>
> Subject: Re: [onap-discuss] [Modeling][vfc] TOSCA Parser API Requirements
>
>
>
>
> Very sorry,I forgot to add the attachment in last email.
>
>
>
> Best Regards,
>
> Yan
>
> 邮件原文
> 发件人："杨艳" 

Re: [onap-discuss] [Integration][Policy] Design and distribution of policies

[Kang Xi]

Pam,

Thanks. I’ve added the information on the wiki page. Please check and make 
necessary changes.
https://wiki.onap.org/display/DW/Use+Case+Related+Important+Questions+and+Answers

Regards,
Kang


From: DRAGOSH, PAMELA L (PAM) [mailto:pdrag...@research.att.com]
Sent: Friday, July 28, 2017 10:37
To: Kang Xi ; 'onap-discuss@lists.onap.org' 

Cc: SHACHAM, RON (RON) ; KLUGER, YOAV 
; Alla Goldner ; LANDO, 
MICHAEL ; Yunxia Chen ; TAYLOR, JON 
; michal.pawlows...@orange.com; FREEMAN, BRIAN D 
; LEFEVRE, CATHERINE ; SPATSCHECK, OLIVER 
(OLIVER) 
Subject: Re: [Integration][Policy] Design and distribution of policies

Kang,

The Policy GUI has a tab where you can deploy a policy into a PDP. Yes the 
Policy GUI is available via the Portal Dashboard.

Regards,

Pam

From: Kang Xi >
Date: Friday, July 28, 2017 at 10:13 AM
To: "DRAGOSH, PAMELA L (PAM)" 
>, 
"'onap-discuss@lists.onap.org'" 
>
Cc: "SHACHAM, RON (RON)" 
>, "KLUGER, YOAV" 
>, Alla Goldner 
>, "LANDO, MICHAEL" 
>, Yunxia Chen 
>, "TAYLOR, JON" 
>, 
"michal.pawlows...@orange.com" 
>, "FREEMAN, 
BRIAN D" >, "LEFEVRE, CATHERINE" 
>, "SPATSCHECK, OLIVER 
(OLIVER)" >
Subject: RE: [Integration][Policy] Design and distribution of policies

Hi Pam,

Thanks for the answer. For non-control loop policies, after they are created in 
the Policy GUI, how are they deployed? Also is the Policy GUI available for 
testing? Do we have sample designs? Thanks.

Regards,
Kang

From: DRAGOSH, PAMELA L (PAM) [mailto:pdrag...@research.att.com]
Sent: Friday, July 28, 2017 8:06
To: Kang Xi >; 
'onap-discuss@lists.onap.org' 
>
Cc: SHACHAM, RON (RON) 
>; KLUGER, YOAV 
>; Alla Goldner 
>; LANDO, MICHAEL 
>; Yunxia Chen 
>; TAYLOR, JON 
>; 
michal.pawlows...@orange.com; FREEMAN, 
BRIAN D >; LEFEVRE, CATHERINE 
>; SPATSCHECK, OLIVER (OLIVER) 
>
Subject: Re: [Integration][Policy] Design and distribution of policies

Kang,


1.  All policies created for control loop control are created by the CLAMP 
project using the Policy API.

a.  NOTE: CLAMP is also the component that subsequently “deploys” all 
control loop policies since it is responsible for deploying the control loop. 
What that means exactly is that CLAMP calls the Policy API to “deploy” (which 
means the runtime policies are pushed to the appropriate Policy Decisions 
Engines for enforcement.

2.  All non-control loop policies will be created in the Policy GUI via the 
Portal Dashboard.

Integration of the Policy GUI with SDC is not planned for R1.

Thanks,

Pam


From: Kang Xi >
Date: Thursday, July 27, 2017 at 10:47 PM
To: "DRAGOSH, PAMELA L (PAM)" 
>, 
"'onap-discuss@lists.onap.org'" 
>
Cc: "SHACHAM, RON (RON)" 
>, "KLUGER, YOAV" 
>, Alla Goldner 
>, "LANDO, MICHAEL" 
>, Yunxia Chen 
>, "TAYLOR, JON" 
>, 
"michal.pawlows...@orange.com" 
>, "FREEMAN, 

[onap-discuss] [integration] Poll on docker image builds

[Gary Wu]

Hi PTLs,

Previously in OPEN-O, the docker images for all microservices were built in a 
standard manner by the Integration team, and the Docker image definitions were 
source controlled in the integration repo.  This, among other things, allowed 
us to have a consistent Docker image layout, and made mass changes across 
docker images much easier.

A quick poll for projects that are new to ONAP or seeded from OPEN-O:  Can you 
let us know if you would like the Integration team to handle the docker image 
builds for you in a similar manner as before in OPEN-O?  Or would you prefer to 
build the docker images yourself?

For projects that came from ECOMP:  Please let us know if you might be 
interested in having your docker images built using the same standardized 
mechanism, and we will collect your requirements to make sure that this process 
can work for your project as well.

Thanks,
Gary


___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [Integration][Policy] Design and distribution of policies

[DRAGOSH, PAMELA L (PAM)]

Kang,

The Policy GUI has a tab where you can deploy a policy into a PDP. Yes the 
Policy GUI is available via the Portal Dashboard.

Regards,

Pam

From: Kang Xi 
Date: Friday, July 28, 2017 at 10:13 AM
To: "DRAGOSH, PAMELA L (PAM)" , 
"'onap-discuss@lists.onap.org'" 
Cc: "SHACHAM, RON (RON)" , "KLUGER, YOAV" 
, Alla Goldner , "LANDO, 
MICHAEL" , Yunxia Chen , "TAYLOR, 
JON" , "michal.pawlows...@orange.com" 
, "FREEMAN, BRIAN D" , "LEFEVRE, 
CATHERINE" , "SPATSCHECK, OLIVER (OLIVER)" 

Subject: RE: [Integration][Policy] Design and distribution of policies

Hi Pam,

Thanks for the answer. For non-control loop policies, after they are created in 
the Policy GUI, how are they deployed? Also is the Policy GUI available for 
testing? Do we have sample designs? Thanks.

Regards,
Kang

From: DRAGOSH, PAMELA L (PAM) [mailto:pdrag...@research.att.com]
Sent: Friday, July 28, 2017 8:06
To: Kang Xi ; 'onap-discuss@lists.onap.org' 

Cc: SHACHAM, RON (RON) ; KLUGER, YOAV 
; Alla Goldner ; LANDO, 
MICHAEL ; Yunxia Chen ; TAYLOR, JON 
; michal.pawlows...@orange.com; FREEMAN, BRIAN D 
; LEFEVRE, CATHERINE ; SPATSCHECK, OLIVER 
(OLIVER) 
Subject: Re: [Integration][Policy] Design and distribution of policies

Kang,


1.   All policies created for control loop control are created by the CLAMP 
project using the Policy API.

a.   NOTE: CLAMP is also the component that subsequently “deploys” all 
control loop policies since it is responsible for deploying the control loop. 
What that means exactly is that CLAMP calls the Policy API to “deploy” (which 
means the runtime policies are pushed to the appropriate Policy Decisions 
Engines for enforcement.

2.   All non-control loop policies will be created in the Policy GUI via 
the Portal Dashboard.

Integration of the Policy GUI with SDC is not planned for R1.

Thanks,

Pam


From: Kang Xi >
Date: Thursday, July 27, 2017 at 10:47 PM
To: "DRAGOSH, PAMELA L (PAM)" 
>, 
"'onap-discuss@lists.onap.org'" 
>
Cc: "SHACHAM, RON (RON)" 
>, "KLUGER, YOAV" 
>, Alla Goldner 
>, "LANDO, MICHAEL" 
>, Yunxia Chen 
>, "TAYLOR, JON" 
>, 
"michal.pawlows...@orange.com" 
>, "FREEMAN, 
BRIAN D" >, "LEFEVRE, CATHERINE" 
>, "SPATSCHECK, OLIVER 
(OLIVER)" >
Subject: [Integration][Policy] Design and distribution of policies

Hi Pam and Policy Team,

Would you please help on the following questions regarding the creation and 
distribution of policies?

-  For all policies related to closed loop control, do we use the CLAMP 
GUI to create them and then distribute them directly to the Policy module?

-  For policies not related to closed loop control, what tool do we use 
to create them and how to distribute them to the Policy module?

I notice that the Policy wiki page includes the following in its scope “Policy 
Design GUI - work with SDC project to integrate the Policy Design GUI during 
VNF/Service design for capturing Policy Expressions”. Is it R1 target to 
integrate policy design into SDC?

We have created Question 22 on the following page to collect information 
related to all the tools/UIs. We would like to list the required input, output, 
sample files, availability of the tools, and major functions under development 
for R1. Would appreciate if you could provide the above information either by 
email or posting directly on the wiki.

Re: [onap-discuss] [Integration][Policy] Design and distribution of policies

[Kang Xi]

Hi Pam,

Thanks for the answer. For non-control loop policies, after they are created in 
the Policy GUI, how are they deployed? Also is the Policy GUI available for 
testing? Do we have sample designs? Thanks.

Regards,
Kang

From: DRAGOSH, PAMELA L (PAM) [mailto:pdrag...@research.att.com]
Sent: Friday, July 28, 2017 8:06
To: Kang Xi ; 'onap-discuss@lists.onap.org' 

Cc: SHACHAM, RON (RON) ; KLUGER, YOAV 
; Alla Goldner ; LANDO, 
MICHAEL ; Yunxia Chen ; TAYLOR, JON 
; michal.pawlows...@orange.com; FREEMAN, BRIAN D 
; LEFEVRE, CATHERINE ; SPATSCHECK, OLIVER 
(OLIVER) 
Subject: Re: [Integration][Policy] Design and distribution of policies

Kang,


1.  All policies created for control loop control are created by the CLAMP 
project using the Policy API.

a.  NOTE: CLAMP is also the component that subsequently “deploys” all 
control loop policies since it is responsible for deploying the control loop. 
What that means exactly is that CLAMP calls the Policy API to “deploy” (which 
means the runtime policies are pushed to the appropriate Policy Decisions 
Engines for enforcement.

2.  All non-control loop policies will be created in the Policy GUI via the 
Portal Dashboard.

Integration of the Policy GUI with SDC is not planned for R1.

Thanks,

Pam


From: Kang Xi >
Date: Thursday, July 27, 2017 at 10:47 PM
To: "DRAGOSH, PAMELA L (PAM)" 
>, 
"'onap-discuss@lists.onap.org'" 
>
Cc: "SHACHAM, RON (RON)" 
>, "KLUGER, YOAV" 
>, Alla Goldner 
>, "LANDO, MICHAEL" 
>, Yunxia Chen 
>, "TAYLOR, JON" 
>, 
"michal.pawlows...@orange.com" 
>, "FREEMAN, 
BRIAN D" >, "LEFEVRE, CATHERINE" 
>, "SPATSCHECK, OLIVER 
(OLIVER)" >
Subject: [Integration][Policy] Design and distribution of policies

Hi Pam and Policy Team,

Would you please help on the following questions regarding the creation and 
distribution of policies?

-For all policies related to closed loop control, do we use the CLAMP 
GUI to create them and then distribute them directly to the Policy module?

-For policies not related to closed loop control, what tool do we use 
to create them and how to distribute them to the Policy module?

I notice that the Policy wiki page includes the following in its scope “Policy 
Design GUI - work with SDC project to integrate the Policy Design GUI during 
VNF/Service design for capturing Policy Expressions”. Is it R1 target to 
integrate policy design into SDC?

We have created Question 22 on the following page to collect information 
related to all the tools/UIs. We would like to list the required input, output, 
sample files, availability of the tools, and major functions under development 
for R1. Would appreciate if you could provide the above information either by 
email or posting directly on the wiki.
https://wiki.onap.org/display/DW/Use+Case+Related+Important+Questions+and+Answers

Regards,
Kang

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Architecture Progress

[jamil.chawki]

Dear Chris
Éric will participate to the architecture meeting
Regards
Jamil

Le 27 juil. 2017 à 20:22, Christopher Donley (Chris) 
> a écrit :

Dear Jamil,

Thank you for sharing.  I’d like to invite you to present your concerns 
regarding the Release 2+ framework on Tuesday’s ARC call so that we can 
consider them as a committee. Would 30 minutes be sufficient?

Regarding Release 1, we are a week out from the functionality freeze milestone. 
 We have heard from the projects that their R1 plans are locked in, and any 
significant changes will delay the release, which is why the committee agreed 
to proceed with the baseline.  We don’t want to put undue risk on the release 
date.  However, the projects are aware of the longer-term target, and did agree 
to look at their code and try to identify any “baby steps” they could take in 
that direction for the Amsterdam release.

Chris

From: jamil.cha...@orange.com 
[mailto:jamil.cha...@orange.com]
Sent: Thursday, July 27, 2017 9:46 AM
To: Christopher Donley (Chris) 
>; Thomas 
Nadeau >; Alla 
Goldner >; Pasi 
Vaananen >; 
onap-discuss@lists.onap.org; Phil Robb 
>; 
kp...@linuxfoundation.org; MAZIN E GILBERT 
(ma...@research.att.com) 
>; 
vb1...@att.com; 'BARTOLI, PAUL D' 
(pb2...@att.com) >
Cc: onap-tsc >
Subject: RE: [onap-discuss] Architecture Progress
Importance: High

Dear Chris and ONAP community
I understand and appreciate your leadership of this subcommittee to align 
different position and I would to clarify some points:

1- Yes the VFC is mentioned in the ONAP charter but without any explanation 
about the functionality of this component which to my knowledge it is not part 
of the Open-o and we have discovered it during the ONS 2017. Comparing to 
Ecomp, we have a clear documented white paper describing overall architecture 
and technical components.

2- Concerning the AT /China Mobile agreement, I would like to clarify 
that ONAP is a merge between the OpenEcomp project proposal supported by some 
members and the Open-O project and not an AT/China Mobile project. Phil and 
Kenny I would like you as LF to clarify this point as my understanding the ONAP 
project is governed by a clear charter  and not by some company agreement or 
discussion.

3- I would like to remember the community that the TSC decision, during the 
last F2F meeting in China, was to approve the APPC, VFC and SO provisionally 
waiting  an alignment from the architecture point of view  : the TSC approved 
the VF-C (APPC/SO) Projects as an incubation projects within ONAP provisional 
on alignment with the overall architecture if such dependencies are identified

http://ircbot.wl.linuxfoundation.org/meetings/onap-meeting/2017/onap-meeting.2017-06-08-01.38.log.html

http://ircbot.wl.linuxfoundation.org/meetings/onap-meeting/2017/onap-meeting.2017-06-09-01.07.html

4- My expectation was to have a feedback from the architecture subcommittee 
to the TSC on this alignment and to have a final approval of these 3 projects. 
Phil and Kenny I would like to raise this question during the next TSC meeting 
and also to indicate in the wiki that these 3 projects are provisionally 
approved.

5- We have clearly identified an overlapping problem between APP-C, VF-C 
and between VF-C and SO (as VF-C is also an NFVO) and the conclusion was to 
wait Rel-2  or Rel-3 in order to find a solution. This will mean that we have a 
high risk to not deliver a useful Rel-1 and this risk was clearly viewed during 
the virtual meeting discussion on DCAE and SDC.

6- I think we have a time to converge rapidly our view by merging  APPC and 
VFC and having one integrated orchestrator, as proposed by Vimal,  before to be 
late.
The industry is waiting our Rel-1 and unfortunately, as Justin Paul said in his 
Linkedin post, ONAP leads, but its not over 'til the fat lady sings… and we may 
not have any song …
https://www.linkedin.com/pulse/nfv-orchestration-onap-leads-its-over-til-fat-lady-sings-paul?trk=v-feed=v-feed=urn%3Ali%3Apage%3Ad_flagship3_search_srp_content%3B19yY4VKdyLkiQWwvYF88Qg%3D%3D

Regards
Jamil

De : onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] De la part de Christopher Donley 
(Chris)
Envoyé : lundi 24 juillet 2017 23:40
À : Thomas Nadeau; 

[onap-discuss] [integration][sdc] Support of vCPE model in SDC

[Kang Xi]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Kang Xi:MAILTO:kang...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="KLUGER, YO
 AV":MAILTO:yoav.klu...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Alla Goldn
 er:MAILTO:alla.gold...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Lando,Mich
 ael":MAILTO:ml6...@intl.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Yunxia Che
 n:MAILTO:helen.c...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="TAYLOR, JO
 N":MAILTO:jon.tay...@amdocs.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Michal.Paw
 lows...@orange.com:MAILTO:michal.pawlows...@orange.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="FREEMAN, B
 RIAN D":MAILTO:bf1...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Lefevre, C
 atherine":MAILTO:cl6...@intl.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="SPATSCHECK
 , OLIVER  (OLIVER)":MAILTO:spat...@research.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="BULLARD, G
 IL":MAILTO:wb5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Eden.Rozin
 @att.com:MAILTO:eden.ro...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Zahi.Kapel
 u...@att.com:MAILTO:zahi.kapel...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='onap-disc
 u...@lists.onap.org':MAILTO:onap-discuss@lists.onap.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=denghui (L
 ):MAILTO:denghu...@huawei.com
DESCRIPTION;LANGUAGE=en-US:Hi Michael and SDC team\,\n\nWe would like to di
 scuss the vCPE service model created by Gil with you to check if the desig
 n could be fully supported in SDC. In case this time is not good we can ce
 rtainly change.\n\nThanks\,\nKang\n\n\n\n
SUMMARY;LANGUAGE=en-US:[integration][sdc] Support of vCPE model in SDC
DTSTART;TZID=Eastern Standard Time:20170801T11
DTEND;TZID=Eastern Standard Time:20170801T12
UID:04008200E00074C5B7101A82E0083072AD3A2B07D301000
 0100012D8BD657201FF48AE9353B1716EC7F8
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20170728T025357Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:https://zoom.us/j/44
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:-1145341983
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [integration][so] Tools to create work flows for SO?

[Kang Xi]

Hi Seshu,

For vCPE we have multiple work flows to instantiate the different parts of the 
service. What tool will be used to create such flows and how are those flows be 
distributed to SO? Are we going to use Camunda, import the output bpm files to 
SDC and let SDC package them in csar, which is then distributed to SO?

We have created Question 22 on the following page to collect information 
related to all the tools/UIs. We would like to list the required input, output, 
sample files, availability of the tools, and major functions under development 
for R1. Would appreciate if you could provide the above information either by 
email or posting directly on the wiki.
https://wiki.onap.org/display/DW/Use+Case+Related+Important+Questions+and+Answers

Regards,
Kang


___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [Integration][Policy] Design and distribution of policies

[Kang Xi]

Hi Pam and Policy Team,

Would you please help on the following questions regarding the creation and 
distribution of policies?

-For all policies related to closed loop control, do we use the CLAMP 
GUI to create them and then distribute them directly to the Policy module?

-For policies not related to closed loop control, what tool do we use 
to create them and how to distribute them to the Policy module?

I notice that the Policy wiki page includes the following in its scope "Policy 
Design GUI - work with SDC project to integrate the Policy Design GUI during 
VNF/Service design for capturing Policy Expressions". Is it R1 target to 
integrate policy design into SDC?

We have created Question 22 on the following page to collect information 
related to all the tools/UIs. We would like to list the required input, output, 
sample files, availability of the tools, and major functions under development 
for R1. Would appreciate if you could provide the above information either by 
email or posting directly on the wiki.
https://wiki.onap.org/display/DW/Use+Case+Related+Important+Questions+and+Answers

Regards,
Kang

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [so] Need re-schedule the SO weekly meeting

[Kenny Paul]

Hi Seshu,
I understand completely. Given the number of meetings already scheduled on 
Wednesdays I may need to juggle some of the other bridge numbers around, but it 
is doable.
If you can, please submit this request via the meeting page and just note that 
it is a schedule change in the message.
That will ensure that your request doesn’t fall through the cracks.

Thanks!


Best Regards, 
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

> On Jul 27, 2017, at 10:49 PM, Seshu m  wrote:
> 
> Dear Kenny
>  
> To avoid the conflict with the Usecase committee Meeting, SO team has decided 
> to have the weekly meetings scheduled at 6:30 am PST every Wednesday.
> Request to kindly change the bridge, also request to provide the recording 
> access for the same.
>  
> Best Regards,
> Seshu
> **
>  This email and its attachments contain confidential information from HUAWEI, 
> which is intended only for the person or entity whose address is listed 
> above. Any use of the information contained here in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or dissemination) 
> by persons other than the intended recipient(s) is prohibited. If you receive 
> this email in error, please notify the sender by phone or email immediately 
> and delete it!
>  
> *

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [multicloud][so] block issue between SO and Mutl VIM/Cloud

[Xinhui Li]

Thanks for more explanation, DeWayne. To ensure the M2 freeze date delivery, we 
need to nail down the functionality/APIs Aria flow will use. That is the reason 
why we think need the meeting.

From Multi VIM/Cloud side, the team would like to support OpenStack compatible 
API for practicality of integration with the tight schedule of R1. Heat will be 
delivered as below meeting notes of the earlier discussion with SO team.

Considering not less team mates locates in UTC+8, hope 20:00 works for you, 
Seshu and most of us.

Thanks,

Xinhui

From: DeWayne Filppi 
Date: Friday, 28 July 2017 at 11:21 PM
To: Xinhui Li 
Cc: "Jinxin (Saw)" , "wangchen...@chinamobile.com" 
, "yangyan...@chinamobile.com" 
, "zhonghe...@boco.com.cn" 
, Danny Lin , Ethan Lynn 
, "Christopher Donley (Chris)" 
, DeWayne Filppi , 
Byung-Woo Jun , "zhanganb...@chinamobile.com" 
, "wu.li...@zte.com.cn" , 
"denghui (L)" , "DAUGHERTY, ROBERT E" , 
"zhang.zh...@zte.com.cn" , Lingli Deng 
, "BULLARD, GIL" , Chenchuanyu 
, "yangyuan...@boco.com.cn" , 
"Yang, Bin" , Andrew Philip , 
"Zengjianguo (OSS Design)" , Seshu m 
, "CHOMA, JOHN S" , 
"onap-discuss@lists.onap.org" 
Subject: Re: [onap-discuss][multicloud][so] block issue between SO and Mutl 
VIM/Cloud

Hi,
 It was my my understanding (told directly by Danny) that multi-VIM would have 
an API interface and a HEAT interface, so there should be no blocker.  Aria can 
use an existing Openstack plugin.  TOSCA models more than infrastructure and 
instantiates individual infrastructure components based on relationships or 
requirements and capabilities.  Each TOSCA element has associated actions, 
which include API calls, in addition to a runtime state.  There is no phase in 
a deployment where all the infrastructure is gathered up together where a HEAT 
template could be constructed, unless something very ugly on the modeling side 
was done.  Again, given that there is no blocker due to the fact that multi-VIM 
will have an API proxy.  Monday I'm only available after 11am PDT.

- DeWayne

On Thu, Jul 27, 2017 at 10:53 PM, Xinhui Li 
> wrote:
Once on use case discussion meeting, I heard that adoption of heat is in order 
to avoid separated calls to nova, cinder, … and so on which are always 
evolving. Heat behaves as orchestrator of infrastructure layer. Is there any 
Heat adapter or converter to help this?

Considering the function freeze date is close, we have to settle down the 
interface between two parties. Can you propose some slot next Monday to discuss 
the block issue? Thanks.

Xinhui

From: DeWayne Filppi >
Date: Friday, 28 July 2017 at 10:55 AM
To: Xinhui Li >
Cc: "Jinxin (Saw)" >, 
"wangchen...@chinamobile.com" 
>, 
"yangyan...@chinamobile.com" 
>, 
"zhonghe...@boco.com.cn" 
>, Danny Lin 
>, Ethan Lynn 
>, "Christopher Donley 
(Chris)" >, 
DeWayne Filppi >, 
Byung-Woo Jun >, 
"zhanganb...@chinamobile.com" 
>, 
"wu.li...@zte.com.cn" 
>, "denghui (L)" 
>, "DAUGHERTY, ROBERT E" 
>, 
"zhang.zh...@zte.com.cn" 
>, Lingli Deng 
>, "BULLARD, GIL" 
>, Chenchuanyu 
>, 
"yangyuan...@boco.com.cn" 

Re: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap projectavailable into Integration repo

[Morales, Victor]

Viswa,

We have focused more in testing and improving the components individually.  
Last time that I tested the All in One configuration was having some issues in 
several dependencies, besides that port conflict that you mentioned.

Regards/Saludos
Victor Morales

From: Viswa KSP 
Date: Friday, July 28, 2017 at 10:26 AM
To: Victor Morales 
Cc: "zhao.huab...@zte.com.cn" , 
"onap-discuss@lists.onap.org" 
Subject: Re: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap 
projectavailable into Integration repo

Victor,

Would this tool be able to stand up all components of ONAP in single 12GB 
Ubuntu instance ( just going with the minimum reqs published in 
read.me ).

Last I heard there were port conflicts to bring-up all components within single 
machine. Was that resolved?

BR,
Viswa

On Fri, Jul 28, 2017 at 8:21 PM, Morales, Victor 
> wrote:
Hey Huabing,

That’s true, this tool clones/pulls source code, compile java artifacts, build 
docker images, etc.

Regards/Saludos
Victor Morales

From: "zhao.huab...@zte.com.cn" 
>
Date: Thursday, July 27, 2017 at 8:02 PM
To: Victor Morales >
Cc: "onap-discuss@lists.onap.org" 
>
Subject: Re:[onap-discuss] [all] [integration] [bootstrap] vagrant-onap 
projectavailable into Integration repo


Hi Victor,



Thanks for bring this useful tool to ONAPer !



I'd like to understand the relationship between this project and OOM.

It seems that this project just intend to provide a handy development 
environment for ONAP developer and will not be part of OOM, which aim to the 
production deployment. Do I understand correctly?



Thanks,

Huabing


Original Mail
Sender:  >;
To:  >;
Date: 2017/07/27 06:57
Subject: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap 
projectavailable into Integration repo


ONAPers,

The vagrant-onap project started as an alternative to deploy ONAP services in 
Virtual Machines hosted locally without the need of an OpenStack deployment.  
After several changes and additions to this project,  its goal has changed to 
provision a Development Environment.  Its current implementation support 
different providers (like VirtualBox, Libvirt and OpenStack) and has been 
tested in some OS(like Ubuntu, Mac OS).  This is an ongoing effort to collect 
instructions  and standardize the methods to build and compile ONAP artifacts, 
as you can expect there are many things that are still missed so I encourage to 
everyone to take a look of the scripts placed into lib folder[1] and improve 
the documentation[2][3]. We have plans  to add more Unit Tests to this 
project[4] to validate any change.

Thanks
Victor Morales
irc: electrocucaracha

[1] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/lib
[2] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/README.md
[3] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/doc/source
[4] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/tests





___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap projectavailable into Integration repo

[Viswa KSP]

Victor,

Would this tool be able to stand up all components of ONAP in single 12GB
Ubuntu instance ( just going with the minimum reqs published in read.me ).

Last I heard there were port conflicts to bring-up all components within
single machine. Was that resolved?

BR,
Viswa

On Fri, Jul 28, 2017 at 8:21 PM, Morales, Victor 
wrote:

> Hey Huabing,
>
>
>
> That’s true, this tool clones/pulls source code, compile java artifacts,
> build docker images, etc.
>
>
>
> Regards/Saludos
>
> Victor Morales
>
>
>
> *From: *"zhao.huab...@zte.com.cn" 
> *Date: *Thursday, July 27, 2017 at 8:02 PM
> *To: *Victor Morales 
> *Cc: *"onap-discuss@lists.onap.org" 
> *Subject: *Re:[onap-discuss] [all] [integration] [bootstrap] vagrant-onap
> projectavailable into Integration repo
>
>
>
> Hi Victor,
>
>
>
> Thanks for bring this useful tool to ONAPer !
>
>
>
> I'd like to understand the relationship between this project and OOM.
>
> It seems that this project just intend to provide a handy development
> environment for ONAP developer and will not be part of OOM, which aim to
> the production deployment. Do I understand correctly?
>
>
>
> Thanks,
>
> Huabing
>
>
>
> Original Mail
>
> *Sender: * ;
>
> *To: * ;
>
> *Date: *2017/07/27 06:57
>
> *Subject: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap
> projectavailable into Integration repo*
>
>
>
> ONAPers,
>
>
>
> The vagrant-onap project started as an alternative to deploy ONAP services
> in Virtual Machines hosted locally without the need of an OpenStack
> deployment.  After several changes and additions to this project,  its goal
> has changed to provision a Development Environment.  Its current
> implementation support different providers (like VirtualBox, Libvirt and
> OpenStack) and has been tested in some OS(like Ubuntu, Mac OS).  This is an
> ongoing effort to collect instructions  and standardize the methods to
> build and compile ONAP artifacts, as you can expect there are many things
> that are still missed so I encourage to everyone to take a look of the
> scripts placed into lib folder[1] and improve the documentation[2][3]. We
> have plans  to add more Unit Tests to this project[4] to validate any
> change.
>
>
>
> Thanks
>
> Victor Morales
>
> irc: electrocucaracha
>
>
>
> [1] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/lib
>
> [2] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/README.md
>
> [3] https://git.onap.org/integration/tree/bootstrap/
> vagrant-onap/doc/source
>
> [4] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/tests
>
>
>
>
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap projectavailable into Integration repo

[Morales, Victor]

Hey Huabing,

That’s true, this tool clones/pulls source code, compile java artifacts, build 
docker images, etc.

Regards/Saludos
Victor Morales

From: "zhao.huab...@zte.com.cn" 
Date: Thursday, July 27, 2017 at 8:02 PM
To: Victor Morales 
Cc: "onap-discuss@lists.onap.org" 
Subject: Re:[onap-discuss] [all] [integration] [bootstrap] vagrant-onap 
projectavailable into Integration repo


Hi Victor,



Thanks for bring this useful tool to ONAPer !



I'd like to understand the relationship between this project and OOM.

It seems that this project just intend to provide a handy development 
environment for ONAP developer and will not be part of OOM, which aim to the 
production deployment. Do I understand correctly?



Thanks,

Huabing


Original Mail
Sender:  ;
To:  ;
Date: 2017/07/27 06:57
Subject: [onap-discuss] [all] [integration] [bootstrap] vagrant-onap 
projectavailable into Integration repo


ONAPers,

The vagrant-onap project started as an alternative to deploy ONAP services in 
Virtual Machines hosted locally without the need of an OpenStack deployment.  
After several changes and additions to this project,  its goal has changed to 
provision a Development Environment.  Its current implementation support 
different providers (like VirtualBox, Libvirt and OpenStack) and has been 
tested in some OS(like Ubuntu, Mac OS).  This is an ongoing effort to collect 
instructions  and standardize the methods to build and compile ONAP artifacts, 
as you can expect there are many things that are still missed so I encourage to 
everyone to take a look of the scripts placed into lib folder[1] and improve 
the documentation[2][3]. We have plans  to add more Unit Tests to this 
project[4] to validate any change.

Thanks
Victor Morales
irc: electrocucaracha

[1] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/lib
[2] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/README.md
[3] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/doc/source
[4] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/tests




___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [aai] A PTL vacation

[FORSYTH, JAMES]

Hi, Everyone,

I will be on vacation until 8/8.  In my absence, Steve Blimkie has my proxy.

Thanks,
jimmy
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [VFC][AAI]A & VF-C Discussion

[FORSYTH, JAMES]

All,

Instructions for updating A schema for new node types and attributes are 
complete, you can find them here:

https://wiki.onap.org/pages/viewpage.action?pageId=10783023

Thanks,
jimmy

From: Gaoweitao (Victor, MANO) [mailto:victor@huawei.com]
Sent: Thursday, July 27, 2017 6:47 AM
To: kp...@linuxfoundation.org; FORSYTH, JAMES ; 杨艳 

Cc: onap-discuss@lists.onap.org
Subject: [VFC][AAI]A & VF-C Discussion

Hi Jimmy, Kenny, Yan,

As we discussed last night, Jimmy will provide the instruction 
for adding new node and attributes in A Scheme before this week.

The principle for adding new attributes and nodes is:

・ If multi nodes share same attributes, new node keep the attributes is 
needed , and adding relationship between new node and related nodes

・ Reuse A original node/attributes as much as possible

Cause multi-project will use A for instances persistence via API that 
automatically generate by A scheme, If we change the A scheme, We also 
need:

1.   From modeling perspective, please modeling subcommittee coordinate the 
AAI modeling

2.   From A perspective, please ARC subcommittee coordinate the impacts 
across the projects

Attachment is the excel that I presented last night.

BR
Victor
*
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使
用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通
知发件人并删除本邮件！
*

*
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person
or entity whose address is listed above. Any use of the information contained 
herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s)
is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!
*

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] 答复: [holmes][clamp][dcae][aai]Holmes Gaps to Get Over

[JI, LUSHENG (LUSHENG)]

Tao,

Thanks for your email.

The API doc will be provided on the schedule mentioned in my previous email to 
Guangrong.

Because DCAE is a large system, it has a large set of APIs as well.  Some are 
used for designed interactions with other ONAP components, some are for testing 
and dev purposes and likely be "undocumented".  Documentation will also be 
prioritized.  Those APIs needed for R1 uses will have priority.

Since this is the first communication from UI, we will need to understand your 
use plan so we can work together to make sure DCAE APIs support the needs of 
UI.  I would suggest we set up a focus meeting to further the discussion.

Thanks,
Lusheng Ji
ONAP DCAE PTL


 Original message 
From: shentao 
Date: 7/28/17 8:45 AM (GMT-05:00)
To: "JI, LUSHENG (LUSHENG)" , fu.guangr...@zte.com.cn, 
"NGUEKO, GERVAIS-MARTIAL" , "SHACHAM, RON (RON)" 
, "FORSYTH, JAMES" , "KOYA, 
RAMPRASAD" , don...@raisecom.com, zhang...@chinamobile.com
Cc: onap-discuss@lists.onap.org
Subject: 答复: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over

Hi，Lusheng

Usecase UI have the same question like Guangrong about DCAE API.
We are going to provide UI functions about alarms and performance.
I’d like to know what kind of data we could get from DCAE so that we can design 
our UI pages.
Could you provide a document about DCAE API details or a list of APIs which 
DCAE is going to provide for R1.

Best regards,
Tao


发件人: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] 代表 JI, LUSHENG (LUSHENG)
发送时间: 2017年7月27日 11:44
收件人: fu.guangr...@zte.com.cn; NGUEKO, GERVAIS-MARTIAL; SHACHAM, RON (RON); 
FORSYTH, JAMES; KOYA, RAMPRASAD
抄送: onap-discuss@lists.onap.org
主题: Re: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over

Please see in-line
Lusheng

From: "fu.guangr...@zte.com.cn" 
>
Date: Wednesday, July 26, 2017 at 10:45 PM
To: "JI, LUSHENG (LUSHENG)" 
>, "NGUEKO, 
GERVAIS-MARTIAL" >, RON SHACHAM 
>, "FORSYTH, JAMES" 
>, "KOYA, RAMPRASAD" 
>
Cc: "onap-discuss@lists.onap.org" 
>, 
"denglin...@chinamobile.com" 
>, 
"liuyuan...@chinamobile.com" 
>
Subject: [holmes][clamp][dcae][aai]Holmes Gaps to Get Over


1. Documentation - API descriptions and Dev Guides have to be provided, either 
formal or informal, as long as they are helpful for developers. We are now 
expecting documentation from projects listed below:

- DMaaP (Message from @Varun Gudisena: documents to be provided by August 3rd)

- DCAE

[lji]  We have provided sample code snippets and descriptions on DCAE project 
wiki under “microservice on-boarding”.  You have agreed on today’s call that 
this info, together with the JSON example for the #2 item below, would be 
sufficient for you to start working.  We plan to provide high level API 
descriptions by M2.  Full API specifications by M3.

- CLAMP

- A

If you have already provided them, please kindly let me know the link. If not, 
please provide a time point for the provision of those formal or informal 
documents.



2. @Lusheng: I will send our configuration json file to you asap. As agreed, 
please help to give the corresponding configurations inside DCAE back to us so 
that we could start to work on parsing the them in Holmes.



3. @Lusheng: As for the communication between DCAE components and other ONAP 
components outside DCAE, I still suggestion that DCAE to be integated with MSB. 
No matter whose responsiblity(DCAE or OOM) it is, we'd better figure out a way 
for this.

[lji] Yes there needs to be a better way for information sharing in control 
plane.  DMaaP at least provides a platform for data plane communication across 
different components.  In general, ONAP lacks such a system wide unified 
run-time configuration sharing method/platform.  So far two candidate methods 
within ONAP scope that I am aware of are via OOM or via MSB, -- and they both 
use Consul so it makes even more sense to harmonize there.  As for DCAE, 
because DCAE’s service discovery mechanism is inherited from OOM code base, 
practically it is difficult for DCAE alone to support a discovery mechanism not 
aligned with OOM.

4. @Lusheng: To my understanding, all A APIs which are intended for external 
use are RESTful. So I'm still sort 

[onap-discuss] [VoLTE][Control Loop] VoLTE Use Case Control Loop Automation followup discussion

[Liu Yuan]

Hi,

We would like to arrange a follow up discussion in next week before the M2. I 
create a doodle page to try to find a suitable time for this discussion. Please 
feedback it in this week. I will send the invitation email by next week.
https://doodle.com/poll/hexcq3bzpfwkvb2u 

For the blockers written on the wiki, some of them still do not have feedback. 
Please kindly help, thanks a lot.

The remaining blockers:
1. nf / nfc naming standard of VES
2. Code: message get from and back to DMaaP -> Please DCAE team point the 
repository
3. Holmes team should provide the JSON components specification to DCAE team, 
and consider the rules, the DMaaP message, etc.

New blockers: maybe who want to discuss something.

Regards,
Yuan


刘媛 / Liu Yuan
网络技术研究所 / Department of Network Technology
中国移动通信研究院 / China Mobile Research Institute
Mobile: +86 15810024078
Email: liuyuan...@chinamobile.com 
 
From: Liu Yuan
Date: 2017-07-25 21:36
To: DRAGOSH, PAMELA L (PAM); l...@research.att.com; NGUEKO, GERVAIS-MARTIAL; 
yangyanyj; fu.guangrong; kpaul
CC: onap-discuss; onap-tsc
Subject: Re: [onap-discuss] [onap-tsc] VoLTE Use Case Control Loop Automation 
session
Thanks for joining the discussion. The slides is in the attachment, and I have 
updated the gaps in the following link. 

https://wiki.onap.org/display/DW/July+Virtual+Developers+Event+Blockers 

For the following action, hope the requirement of the examples can be provide 
in this week. Then, we can have a further discussion in the next week.

Thanks,
Yuan


刘媛 / Liu Yuan
网络技术研究所 / Department of Network Technology
中国移动通信研究院 / China Mobile Research Institute
Mobile: +86 15810024078
Email: liuyuan...@chinamobile.com 
 
From: Liu Yuan
Date: 2017-07-25 15:06
To: DRAGOSH, PAMELA L (PAM); l...@research.att.com; NGUEKO, GERVAIS-MARTIAL; 
yangyanyj; fu.guangrong; kpaul
CC: onap-discuss; onap-tsc
Subject: Re: [onap-tsc] [onap-discuss] VoLTE Use Case Control Loop Automation 
session
Hi,

In the next virtual developer event VoLTE Use Case Control Loop Automation 
session, I plan to have a brief introduction based on the attachment slides. 
The control loop flows and related files are from CLAMP, DCAE, and Policy team 
in the wiki, some gaps are from Holmes team. We try to collect and find the 
gaps among different projects to ensure the VoLTE use case control loop deliver 
on time in R1. I will try to keep the presentation short and give more time for 
discussion.

Hi Kenny,

Would you mind add PTLs (as below) of related projects into the panel list. I 
think the discussion needs them. Thanks.
CLAMP: Gervais-Martial Ngueko
DCAE: Lushang Ji
Holmes: Guangrong Fu
Policy: Pamela Dragosh
VF-C: Yan Yang

If anyone who wants to join the discussion online, I guess Kenny can help us to 
unmute you. Thanks.

Regards,
Yuan


刘媛 / Liu Yuan
网络技术研究所 / Department of Network Technology
中国移动通信研究院 / China Mobile Research Institute
Mobile: +86 15810024078
Email: liuyuan...@chinamobile.com 
 
From: Liu Yuan
Date: 2017-07-18 18:03
To: DRAGOSH, PAMELA L (PAM); l...@research.att.com; NGUEKO, GERVAIS-MARTIAL; 
yangyanyj; fu.guangrong
CC: onap-discuss; onap-tsc
Subject: Re: [onap-discuss] [onap-tsc] What Do You Need From The July 
Developers Event?
Hi,

I add a topic about the VoLTE Use Case Control Loop Automation in the following 
link. For meeting the requirements of VoLTE use case, it is time to discuss the 
control loop for fault correlation and auto-healing in a more detail level. So, 
we would like to invite CLAMP, DCAE, Policy, Holmes, VF-C and other related 
projects to join in the topic. Thanks.

https://wiki.onap.org/pages/viewpage.action?pageId=8232264 
VoLTE Use Case Control Loop Automation 
Description:  In the Amsterdam release, VoLTE use case has a requirement on 
fault correlation and auto-healing, which is closely related to Control loop, 
including but not limited to CLAMP, DCAE, Policy, Holmes, and VF-C projects. 
During the previously discussion in the weekly meeting, the workflow of control 
loop has been introduced, but some actual example files are not provided. It is 
time to design the control loop for VoLTE use case to ensure deliver on time. 
Here are the gaps need to discuss.
Examples of DCAE template, CLAMP/Cloudify Blueprint, Config Policy, Operational 
Policy and related files needed to be designed and used in the control loop. If 
a series of practical examples can be provided, like all related examples of 
the vFW demo, which is better for us to understand.
Developer guidelines to design the control loop to achieve the requirement of 
VoLTE. Demo of the entire process, e.g. create, deploy, etc., which is a better 
way help us to learn, if it can be provided.
Holmes deployment, integrated with DCAE or separately deployment, e.g. 
workflow, DCAE Template, API, etc.
The solution of design, creating and distributing Holmes rules, e.g. refer to 
Policy, or other solutions, etc.
The requirement of Policy to invoke the API of VF-C.
The API document of VES collector in DCAE is 

[onap-discuss] 答复: [holmes][clamp][dcae][aai]Holmes Gaps to Get Over

[shentao]

Hi，Lusheng

 

Usecase UI have the same question like Guangrong about DCAE API.

We are going to provide UI functions about alarms and performance.

I’d like to know what kind of data we could get from DCAE so that we can design 
our UI pages.

Could you provide a document about DCAE API details or a list of APIs which 
DCAE is going to provide for R1.

 

Best regards,

Tao

 

 

发件人: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] 代表 JI, LUSHENG (LUSHENG)
发送时间: 2017年7月27日 11:44
收件人: fu.guangr...@zte.com.cn; NGUEKO, GERVAIS-MARTIAL; SHACHAM, RON (RON); 
FORSYTH, JAMES; KOYA, RAMPRASAD
抄送: onap-discuss@lists.onap.org
主题: Re: [onap-discuss] [holmes][clamp][dcae][aai]Holmes Gaps to Get Over

 

Please see in-line

Lusheng

 

From: "fu.guangr...@zte.com.cn" 
Date: Wednesday, July 26, 2017 at 10:45 PM
To: "JI, LUSHENG (LUSHENG)" , "NGUEKO, GERVAIS-MARTIAL" 
, RON SHACHAM , "FORSYTH, 
JAMES" , "KOYA, RAMPRASAD" 
Cc: "onap-discuss@lists.onap.org" , 
"denglin...@chinamobile.com" , 
"liuyuan...@chinamobile.com" 
Subject: [holmes][clamp][dcae][aai]Holmes Gaps to Get Over

 

1. Documentation - API descriptions and Dev Guides have to be provided, either 
formal or informal, as long as they are helpful for developers. We are now 
expecting documentation from projects listed below:

- DMaaP (Message from @Varun Gudisena: documents to be provided by August 3rd)

- DCAE  

[lji]  We have provided sample code snippets and descriptions on DCAE project 
wiki under “microservice on-boarding”.  You have agreed on today’s call that 
this info, together with the JSON example for the #2 item below, would be 
sufficient for you to start working.  We plan to provide high level API 
descriptions by M2.  Full API specifications by M3.

- CLAMP

- A

If you have already provided them, please kindly let me know the link. If not, 
please provide a time point for the provision of those formal or informal 
documents.

 

2. @Lusheng: I will send our configuration json file to you asap. As agreed, 
please help to give the corresponding configurations inside DCAE back to us so 
that we could start to work on parsing the them in Holmes.

 

3. @Lusheng: As for the communication between DCAE components and other ONAP 
components outside DCAE, I still suggestion that DCAE to be integated with MSB. 
No matter whose responsiblity(DCAE or OOM) it is, we'd better figure out a way 
for this.

[lji] Yes there needs to be a better way for information sharing in control 
plane.  DMaaP at least provides a platform for data plane communication across 
different components.  In general, ONAP lacks such a system wide unified 
run-time configuration sharing method/platform.  So far two candidate methods 
within ONAP scope that I am aware of are via OOM or via MSB, -- and they both 
use Consul so it makes even more sense to harmonize there.  As for DCAE, 
because DCAE’s service discovery mechanism is inherited from OOM code base, 
practically it is difficult for DCAE alone to support a discovery mechanism not 
aligned with OOM. 

4. @Lusheng: To my understanding, all A APIs which are intended for external 
use are RESTful. So I'm still sort of confused of what you said at the virtual 
meeting that "A will distribute the topology information to a certain 
topic". I think we still need to call the RESTful APIs of A to get the 
resource information needed for alarm correlation. Actually you have provided a 
way to configure the address of A by hard coding them into the 
configuration, but it is based on the prerequisite that we are aware of the url 
of A in advance, which I think is impossible for us during the onboarding 
phase.

[lji] To my understanding A supports two ways for sharing inventory info.  
One is that it actively announces updates on a DMaaP topic.  Two is it 
passively waits for other parties to make RestAPI calls to retrieve inventory. 
What I do not know is whether they turn both on for ONAP configuration.  For 
your use case it does sound like the second method is more suitable.  Either 
way we need to know the parameters, the message topic v.s. API entry point.  I 
think whatever that deployment plan of A is will drive how such parameters 
are shared and used.  If the plan is to use well-known topic and API entry 
(e.g. via well-known host name), we can have those hard-coded as part of 
configuration.  If dynamic, this becomes the ONAP level control plane info 
sharing problem we are discussing under #3.

5. @Ron @Martial: If we are going to support dynamic design and deployment of 
rules during the run time, what do you expect from Holmes? Do you have any 
requirements on Holmes? If there's any, please send them to me. I'll add them 
to our plan if time permits.

 

 

 

 

Re: [onap-discuss] [integration] Update POM to inherit from oparent

[Kanagaraj Manickam]

Hi Gary,

I have  enabled for CLI project.

Thanks
Kanagaraj M

***
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！**

***
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 
this e-mail in error, please notify the sender by phone or email immediately 
and delete it!
***

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu
Sent: Thursday, July 27, 2017 11:43 PM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] [integration] Update POM to inherit from oparent

Hello PTLs,

O-Parent (repo: oparent) is a parent POM that centrally defines shared 
configuration items such as Nexus (distributionManagement) location, license 
checks, coding style checks, sonar setup, etc.  
https://wiki.onap.org/pages/viewpage.action?pageId=10783020.  The ultimate goal 
is ensure consistency across ONAP projects, and free individual projects from 
redundant work whenever the standard configurations need to be changed.

To make this work, we request the following help from each project:
1.   Modify POMs to inherit from oparent,
2.   Remove applicable local configuration properties in individual POM 
files

To inherit from oparent:  modify the project’s POM to ensure that all POM files 
ultimately inherit from


org.onap.oparent
oparent
1.0.0-SNAPSHOT


If your seed code came from OPEN-O, note that the groupId has been changed to 
org.onap instead of org.openo.


Once the above is done, please also remove any local definitions within the 
project POMs around distributionManagement, coding styles, etc., so that those 
properties are derived from oparent instead.

Please let the Integration team know if you run into anything that would 
require changes or enhancements to the oparent POMs.

Thanks,
Gary




___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [multicloud][so] block issue between SO and Mutl VIM/Cloud

[Xinhui Li]

Once on use case discussion meeting, I heard that adoption of heat is in order 
to avoid separated calls to nova, cinder, … and so on which are always 
evolving. Heat behaves as orchestrator of infrastructure layer.

To help R1, is there any Heat adapter or converter? Considering the function 
freeze date is very close, we have to settle down the interface between two 
parties. Can you propose some slot next Monday to discuss the block issue?

Thanks,

Xinhui

From: DeWayne Filppi 
Date: Friday, 28 July 2017 at 10:55 AM
To: Xinhui Li 
Cc: "Jinxin (Saw)" , "wangchen...@chinamobile.com" 
, "yangyan...@chinamobile.com" 
, "zhonghe...@boco.com.cn" 
, Danny Lin , Ethan Lynn 
, "Christopher Donley (Chris)" 
, DeWayne Filppi , 
Byung-Woo Jun , "zhanganb...@chinamobile.com" 
, "wu.li...@zte.com.cn" , 
"denghui (L)" , "DAUGHERTY, ROBERT E" , 
"zhang.zh...@zte.com.cn" , Lingli Deng 
, "BULLARD, GIL" , Chenchuanyu 
, "yangyuan...@boco.com.cn" , 
"Yang, Bin" , Andrew Philip , 
"Zengjianguo (OSS Design)" , Seshu m 
, "CHOMA, JOHN S" 
Subject: Re: Sync up between SO and Mutl VIM/Cloud

Hi,

 I think it makes more sense for the Tosca orchestrator to use the multivim api 
endpoint directly rather than Heat.

DeWayne

On Jul 27, 2017 7:23 PM, "Xinhui Li" 
> wrote:
Hi Dewayne,

We are looking forward to your sharing about this question.

Thanks,

Xinhui

From: Seshu m >
Date: Thursday, 20 July 2017 at 9:56 PM
To: Xinhui Li >, Danny Lin 
>, "Jinxin (Saw)" 
>, "Zengjianguo (OSS Design)" 
>, Andrew Philip 
>, "Yang, Bin" 
>, 
"zhanganb...@chinamobile.com" 
>, Ethan Lynn 
>, "CHOMA, JOHN S" 
>, DeWayne Filppi 
>, Byung-Woo Jun 
>, 
"wangchen...@chinamobile.com" 
>, 
"zhonghe...@boco.com.cn" 
>, 
"zhang.zh...@zte.com.cn" 
>, Chenchuanyu 
>, 
"yangyan...@chinamobile.com" 
>, "DAUGHERTY, 
ROBERT E" >, Lingli Deng 
>, 
"wu.li...@zte.com.cn" 
>, 
"yangyuan...@boco.com.cn" 
>, "BULLARD, GIL" 
>, "denghui (L)" 
>, "Christopher Donley 
(Chris)" >
Subject: RE: Sync up between SO and Mutl VIM/Cloud

Hi Dewayne,

We have had a question to clarify for the VCPE Usecase w.r.t the way SO would 
pass the data to cloud.
1. Currently its confirmed by the Multi Vim that APPC would interact with Multi 
VIm only for the healing flow.
2. This would bring the same question we had last SO meeting on how ARIA engine 
based flow works with Heat calls, where,
 I remember you were provinding some way the output of ARIA could be convereted 
to Heat.

Please provide us your views

Best Regards,
Seshu
**
 This email and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained here in any way (including, but not 
limited to, total or partial disclosure, reproduction,