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

[Seshu m]

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] Versioning for Amsterdam

[zhao.huabing]

Hi Gildas,






I suggest we align the versioning mechanism of the deliverable with REST API 
version.






I didn't go to the versioning discussion during the virtual developer meeting. 
But from what I learned by this mail, I think there is no conflict between what 
you folks are suggesting and the REST API versioning mechanism 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification+for+ONAP#RESTfulAPIDesignSpecificationforONAP-Versioning







What do you think?






BR,


Huabing



Original Mail



Sender:  
To:  
CC:  
Date: 2017/07/27 22:36
Subject: Re: [onap-discuss] Versioning for Amsterdam






Hi Gildas, 
 
What process to you recommend so that we can settle on this? Do we need to go 
through TSC?
 
On Jul 21, 2017, at 6:22 PM, Gildas Lanilis  wrote:
 


I see Olivier is leading a session on versioning, excellent I will attend. I 
won't have time to cover this during Release Planning.
 
Looks like there is a trend toward option 2 (multiple version of jars files 
embedded within 1 docker image) with some good reasons. Thinking loud, as all 
projects will be a Docker image, when we will release these Docker images in  
November, I will be incline to mark these Docker images as version 1.0.0. for 
Amsterdam and later 2.0.0 for Beijing (and of course with semantic versioning 
if we need in the middle to deliver patches).
 
So we will end up with Something like:
 
Amsterdam Release:1.0.0
 
AAI Docker Image: 1.0.0

 AAI cpt 1: 2.0.3

 AAI cpt2: 1.4.2

 AAI cpt3: 0.0.9

 Other stuff: 1.2.6
 
AAFDocker Image: 1.0.0

 AAI cpt 1: 2.0.3

 AAI cpt2: 2.4.2

 AAI cpt3: 1.0.9

Other stuff: 1.2.7
 
Beijing: 2.0.0
 
AAI Docker Image: 2.0.0

 AAI cpt1: 2.5.3

 AAI cpt2: 2.4.2

 AAI cpt3: 1.0.9

 Other stuff: 1.2.8
 
AAF Docker Image: 2.0.0

 AAF cpt1: 2.9.3

 AAF cpt2: 3.5.2

 AAF cpt3: 1.0.9

Other stuff: 2.2.6
  
Let me know if that resonate to you or if I should stop and go in weekend J
 
Thanks,

Gildas

ONAP Release Manager

1 415 238 6287
  
-Original Message- From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Andrew Grimberg Sent: 
Thursday, July 20, 2017 11:00 AM To: Gary Wu  Cc: 
onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Versioning for Amsterdam
 
It's the same process we would follow for a single simultaneous release.

The difference is that each component would be (and presently ONAP does

this) producing their own staging repository.
 
So, the release is then a matter of identifying which repositories are part of 
the release and doing the artifact signing on those and releases in nexus to 
the release repository.
 
The Simultaneous Release would be more of an identifying what components are 
actually part of the tested SR and potentially some final single produced 
downloadable object that doesn't do the build, but just incorporates the 
individually  released components.
 
LF Release Engineering (RelEng) has been fixing up our release scripts dealing 
with this sort of thing. They are now part of the lftools python project [0] 
[1] (installable via PyPi). ODL itself has started down the road of individual  
components being able to release off sync from each other with the current 
Nitrogen release cycle. The odlparent project has already had at least 3 
different releases in the middle of the cycle! We expect that the next project 
up the stack (yangtools) will  do that with the Oxygen release as they 
transition to SemVer which really is a requirement for this to work correctly.
 
We have additional work coming that will allow us to automate the artifact 
signing and will therefore allow us to move more of the release processes into 
the hands of the community itself instead of relying on RelEng for so much  of 
it.
 
-Andy-
 
[0] https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/lftools

[1] https://github.com/lfit/releng-lftools
 
On 07/20/2017 10:41 AM, Gary Wu wrote:

> Hi Andy,

> 

> Can you chime in on how the release process would work (vis-à-vis use of 
> staging repos, artifact signings, etc.) if ONAP  decides to have independent 
> version numbers and possibly independent release cycles for each module?

> 

> Thanks,

> Gary

> 

> 

> -Original Message-

> From: onap-discuss-boun...@lists.onap.org

> [mailto:onap-discuss-boun...@lists.onap.org]  On Behalf Of Gino Fraboni

> Sent: Thursday, July 20, 2017 7:04 AM

> To: SPATSCHECK, OLIVER (OLIVER)   Yunxia

> Chen 

> Cc: onap-discuss@lists.onap.org

> Subject: Re: [onap-discuss] Versioning for Amsterdam

> 

> 

> I'll throw in my +1 for version 2 as well.

> And semantic versioning makes complete sense to me.

> 

> 

> Gino Fraboni

> 

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

[zhao.huabing]

Thanks, Helen.







Original Mail



Sender:  
To: zhaohuabing10201488 
CC:  
Date: 2017/07/28 10:20
Subject: Re: [onap-discuss] [all] [integration] [bootstrap] 
vagrant-onapprojectavailable into Integration repo







Hi, Huabing,


Yes, at this moment, the tools that Victor and his team are developing are used 
for Developer to start their development and testing environment fast. It is 
part of Integration project.   


 


Regards,


 



Helen Chen


 



From:  on behalf of 
"zhao.huab...@zte.com.cn" 
 Date: Thursday, July 27, 2017 at 6:02 PM
 To: "victor.mora...@intel.com" 
 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

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

[Yunxia Chen]

Hi, Huabing,
Yes, at this moment, the tools that Victor and his team are developing are used 
for Developer to start their development and testing environment fast. It is 
part of Integration project.

Regards,

Helen Chen

From:  on behalf of 
"zhao.huab...@zte.com.cn" 
Date: Thursday, July 27, 2017 at 6:02 PM
To: "victor.mora...@intel.com" 
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

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

[zhao.huabing]

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

Re: [onap-discuss] Architecture Progress

[Christopher Donley (Chris)]

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; Alla Goldner; Pasi Vaananen; 
onap-discuss@lists.onap.org
Cc : onap-tsc
Objet : Re: [onap-tsc] [onap-discuss] Architecture Progress

Tom,

I fully agree with your comments about top-down management. The architecture 
subcommittee is here to support and advise the projects, not command the 
projects.  I also agree with your point about this being a desired target 
state.  But I want to clarify that the projects have been involved in the 
creation of the long-term architecture.  This has not been an isolated exercise.

I'd like to provide more context on how we reached this point.  During the 
merger 

Re: [onap-discuss] Architecture Progress

[jamil.chawki]

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; Alla Goldner; Pasi Vaananen; onap-discuss@lists.onap.org
Cc : onap-tsc
Objet : Re: [onap-tsc] [onap-discuss] Architecture Progress

Tom,

I fully agree with your comments about top-down management. The architecture 
subcommittee is here to support and advise the projects, not command the 
projects.  I also agree with your point about this being a desired target 
state.  But I want to clarify that the projects have been involved in the 
creation of the long-term architecture.  This has not been an isolated exercise.

I'd like to provide more context on how we reached this point.  During the 
merger process, AT and China Mobile reached agreement on an initial set of 
modules to be included in ONAP (8 from ECOMP and 3 from OPEN-O, including SO, 
APP-C, and VF-C, which have been challenging to integrate because of 
overlapping functionality).  These are written into the ONAP Charter.  A small 
group of people then negotiated an initial R1 architecture and presented it at 
ONS. It was also addressed in subsequent developer meetings prior to the 
formation of the architecture subcommittee. We are not diverging from that in 
the Amsterdam timeframe because we heard feedback from projects that their 
release plans were already based on the initial architecture, and divergence 
would add delay and risk into the release.

Over the course of the last four weeks or so, the architecture subcommittee 
considered multiple proposals to resolve the overlap from multiple operators 
and from the affected projects.  In the short term, there is a lot of 
divergence. Some operators prefer the APP-C approach and some prefer the VF-C 
approach (some want both).  When we broke down each of the components and 
analyzed the functionality in each, a path for harmonization did appear, and is 
reflected in the R2 target that I shared.  We saw variants of the consensus 
approach in multiple proposals, including the one Jamil referenced and one from 
the SO project. We heard favorable comments from other project teams, as well. 
Projects were engaged 

[onap-discuss] VoLTE use case status review

[Yang Xu (Yang, Fixed Network)]

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="Yang Xu (Yang, Fixed Network)":MAILTO:yang@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=onap-discu
 s...@lists.onap.org:MAILTO:onap-discuss@lists.onap.org
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=yangyanyj@
 chinamobile.com:MAILTO:yangya...@chinamobile.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=fu.guangro
 n...@zte.com.cn:MAILTO:fu.guangr...@zte.com.cn
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Seshu m:MA
 ILTO:seshu.kuma...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=lji@resear
 ch.att.com:MAILTO:l...@research.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=zhao.huabi
 n...@zte.com.cn:MAILTO:zhao.huab...@zte.com.cn
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=zhang.maop
 e...@zte.com.cn:MAILTO:zhang.maope...@zte.com.cn
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="SPATSCHECK
 , OLIVER":MAILTO:spat...@research.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=Kang Xi:MA
 ILTO:kang...@huawei.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="BULLARD, G
 IL":MAILTO:wb5...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="ROSE, DANI
 EL V":MAILTO:dr6...@att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='rshacham@
 research.att.com':MAILTO:rshac...@research.att.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=denglingli
 @chinamobile.com:MAILTO:denglin...@chinamobile.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Chengli Wa
 ng:MAILTO:wangchen...@chinamobile.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=zk093v@att
 .com:MAILTO:zk0...@att.com
DESCRIPTION;LANGUAGE=en-US:When: Friday\, July 28\, 2017 8:00 AM-9:00 AM (U
 TC-05:00) Eastern Time (US & Canada).\nWhere: https://zoom.us/j/44
 \n\nNote: The GMT offset above does not reflect daylight saving time adjus
 tments.\n\n*~*~*~*~*~*~*~*~*~*\n\nAll\,\n\nWe will provide VoLTE use case 
 status update and review the blocking issues related to the use case. The 
 blocking issues are listed on https://wiki.onap.org/display/DW/July+Virtua
 l+Developers+Event+Blockers.\n\nAlso\, we will discuss our plan moving for
 ward.\n\n-
 --
 ---\nJoin from PC\, Mac\, Linux\, iOS or Android: https://zoom.us/j/44
 \n\nOr iPhone one-tap (US Toll): +16465588656\,44# or +140
 86380968\,44#\n\nOr Telephone:\nDial: +1 646 558 8656 (US Toll) or
  +1 408 638 0968 (US Toll)\nMeeting ID: 44  8\nInternational numbe
 rs available: https://zoom.us/zoomconference?m=CqsAwHx4CSyRanCfPHKBvf6Vslg
 csn86\n\n\n\n\n\n
SUMMARY;LANGUAGE=en-US:VoLTE use case status review
DTSTART;TZID=Eastern Standard Time:20170728T08
DTEND;TZID=Eastern Standard Time:20170728T09
UID:04008200E00074C5B7101A82E008C0DC5986C006D301000
 01000FD58B8CDF141CE4188D133CA55FBDDB9
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20170727T152117Z
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:1698396129
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

Re: [onap-discuss] [aai] A local dev setup guide

[Morales, Victor]

Hey Jimmy,

The approach that we have in vagrant-onap is to sync source code folders 
between the host and guest machines[1].  The purpose of this is to install, 
build and deploy things in the VM but use IDE and gerrit ssh keys of the host 
machine at the same, this could facilitate the recreation of Dev Environments 
with the execution of two command (vagrant destroy –f  && vagrant up 
) without losing changes in the source code and keeping the same 
gerrit keys to submit changes.  Maybe this approach can help you to reduce 
memory needed.

Thanks
Victor Morales

[1] https://git.onap.org/integration/tree/bootstrap/vagrant-onap/Vagrantfile#n96


From: "FORSYTH, JAMES" 
Date: Wednesday, July 26, 2017 at 6:22 PM
To: Victor Morales , "'onap-discuss@lists.onap.org'" 

Cc: "PRESSLEY, VIVIAN A" 
Subject: RE: [onap-discuss] [aai] A local dev setup guide

Hi, Victor,

I think 4GB would work to run the services and the graphdb; probably want more 
if as a dev you want to run an IDE/chrome/postman alongside, so probably 
minimum 8GB for that purpose.  I’ll adjust my VM settings down and see how it 
goes ☺

Thanks,
jimmy

From: Morales, Victor [mailto:victor.mora...@intel.com]
Sent: Wednesday, July 26, 2017 6:29 PM
To: FORSYTH, JAMES ; 'onap-discuss@lists.onap.org' 

Cc: PRESSLEY, VIVIAN A 
Subject: Re: [onap-discuss] [aai] A local dev setup guide

Hi Jimmy,

Thanks for sharing this guide, I’ve plans to include those instructions into 
the bootstrap project, to be more precisely in this script

https://git.onap.org/integration/tree/bootstrap/vagrant-onap/lib/aai

I noticed that you suggest to use 16 GB of RAM, did you try with less memory? 
Or in other words, what’s the minimum amount of memory required?

Thanks
Victor Morales
irc: electrocucaracha

From: 
>
 on behalf of "FORSYTH, JAMES" >
Date: Wednesday, July 26, 2017 at 4:09 PM
To: "'onap-discuss@lists.onap.org'" 
>
Cc: "PRESSLEY, VIVIAN A" >
Subject: [onap-discuss] [aai] A local dev setup guide

Hi, All,

As agreed during the VF-C/A session of the Virtual Developer’s Event, I have 
a local dev setup guide page posted under the A page on the wiki, complete 
with Postman example scripts for exercising the resources and aai-traverals 
microservices:

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

I welcome feedback and hope that at least our A devs are able to try this 
out locally.

I am in the process of creating a tutorial which illustrates modifying the 
schema, adding a new node type and adding attributes to existing types – look 
for that tomorrow.

Thanks,
jimmy




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

Re: [onap-discuss] [development] Development practices subcommittee?

[Vitaliy Emporopulo]

Thank you Victor!

From: Morales, Victor [mailto:victor.mora...@intel.com]
Sent: Thursday, July 27, 2017 17:38
To: Vitaliy Emporopulo ; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [development] Development practices subcommittee?

Hi Vitaliy

These are my two cents on this.  AFAIK there is no a dedicated subcommittee 
that is in charge of collecting development tools and practices as a goal, but 
there is an initiative named Bootstrap[1] which is targeting to help new 
developers to work in ONAP.  One of the tools that we have is ONAP on Vagrant 
[2] which is an ongoing effort to provide a development environment and try to 
unify those practices.  Any feedback it’s always welcome from reviewing code to 
propose things in the roadmap, the Integration team meets every Tuesday or you 
can reach them using the #onap-int IRC channel[3]

Regards/Saludos
Victor Morales
irc: electrocucaracha

[1] https://wiki.onap.org/pages/viewpage.action?pageId=8226978
[2] https://lists.onap.org/pipermail/onap-discuss/2017-July/002725.html
[3] https://wiki.onap.org/display/DW/Integration+Weekly+Meeting


From: 
>
 on behalf of Vitaliy Emporopulo 
>
Date: Thursday, July 27, 2017 at 2:31 AM
To: "onap-discuss@lists.onap.org" 
>
Subject: [onap-discuss] [development] Development practices subcommittee?

Hello fellow ONAPers,

Following yesterday’s great session about typical development setups, I have a 
few questions.


1.  Is there a dedicated subcommittee for development practices?

2.  On the one hand, there’s apparently a roadmap for unification of 
development tools and practices, but on the other hand it’s not clear who leads 
the effort. There’s not much discussion on the [development] topic in this 
mailing list either.

3.  I have a few thoughts I’d like to share about the proposed roadmap. 
What would be the right forum to discuss them?

Best regards,
Vitaliy Emporopulo
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-discuss] [development] Development practices subcommittee?

[Morales, Victor]

Hi Vitaliy

These are my two cents on this.  AFAIK there is no a dedicated subcommittee 
that is in charge of collecting development tools and practices as a goal, but 
there is an initiative named Bootstrap[1] which is targeting to help new 
developers to work in ONAP.  One of the tools that we have is ONAP on Vagrant 
[2] which is an ongoing effort to provide a development environment and try to 
unify those practices.  Any feedback it’s always welcome from reviewing code to 
propose things in the roadmap, the Integration team meets every Tuesday or you 
can reach them using the #onap-int IRC channel[3]

Regards/Saludos
Victor Morales
irc: electrocucaracha

[1] https://wiki.onap.org/pages/viewpage.action?pageId=8226978
[2] https://lists.onap.org/pipermail/onap-discuss/2017-July/002725.html
[3] https://wiki.onap.org/display/DW/Integration+Weekly+Meeting


From:  on behalf of Vitaliy Emporopulo 

Date: Thursday, July 27, 2017 at 2:31 AM
To: "onap-discuss@lists.onap.org" 
Subject: [onap-discuss] [development] Development practices subcommittee?

Hello fellow ONAPers,

Following yesterday’s great session about typical development setups, I have a 
few questions.


1.   Is there a dedicated subcommittee for development practices?

2.   On the one hand, there’s apparently a roadmap for unification of 
development tools and practices, but on the other hand it’s not clear who leads 
the effort. There’s not much discussion on the [development] topic in this 
mailing list either.

3.   I have a few thoughts I’d like to share about the proposed roadmap. 
What would be the right forum to discuss them?

Best regards,
Vitaliy Emporopulo
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Versioning for Amsterdam

[Sauvageau, David]

Hi Gildas,

What process to you recommend so that we can settle on this? Do we need to go 
through TSC?

On Jul 21, 2017, at 6:22 PM, Gildas Lanilis 
> wrote:

I see Olivier is leading a session on versioning, excellent I will attend. I 
won't have time to cover this during Release Planning.

Looks like there is a trend toward option 2 (multiple version of jars files 
embedded within 1 docker image) with some good reasons. Thinking loud, as all 
projects will be a Docker image, when we will release these Docker images in 
November, I will be incline to mark these Docker images as version 1.0.0. for 
Amsterdam and later 2.0.0 for Beijing (and of course with semantic versioning 
if we need in the middle to deliver patches).

So we will end up with Something like:

Amsterdam Release:1.0.0

AAI Docker Image: 1.0.0
 AAI cpt 1: 2.0.3
 AAI cpt2: 1.4.2
 AAI cpt3: 0.0.9
 Other stuff: 1.2.6

AAFDocker Image: 1.0.0
 AAI cpt 1: 2.0.3
 AAI cpt2: 2.4.2
 AAI cpt3: 1.0.9
Other stuff: 1.2.7

Beijing: 2.0.0

AAI Docker Image: 2.0.0
 AAI cpt1: 2.5.3
 AAI cpt2: 2.4.2
 AAI cpt3: 1.0.9
 Other stuff: 1.2.8

AAF Docker Image: 2.0.0
 AAF cpt1: 2.9.3
 AAF cpt2: 3.5.2
 AAF cpt3: 1.0.9
Other stuff: 2.2.6


Let me know if that resonate to you or if I should stop and go in weekend ☺

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287


-Original Message-
From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Andrew Grimberg
Sent: Thursday, July 20, 2017 11:00 AM
To: Gary Wu >
Cc: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] Versioning for Amsterdam

It's the same process we would follow for a single simultaneous release.
The difference is that each component would be (and presently ONAP does
this) producing their own staging repository.

So, the release is then a matter of identifying which repositories are part of 
the release and doing the artifact signing on those and releases in nexus to 
the release repository.

The Simultaneous Release would be more of an identifying what components are 
actually part of the tested SR and potentially some final single produced 
downloadable object that doesn't do the build, but just incorporates the 
individually released components.

LF Release Engineering (RelEng) has been fixing up our release scripts dealing 
with this sort of thing. They are now part of the lftools python project [0] 
[1] (installable via PyPi). ODL itself has started down the road of individual 
components being able to release off sync from each other with the current 
Nitrogen release cycle. The odlparent project has already had at least 3 
different releases in the middle of the cycle! We expect that the next project 
up the stack (yangtools) will do that with the Oxygen release as they 
transition to SemVer which really is a requirement for this to work correctly.

We have additional work coming that will allow us to automate the artifact 
signing and will therefore allow us to move more of the release processes into 
the hands of the community itself instead of relying on RelEng for so much of 
it.

-Andy-

[0] https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/lftools
[1] https://github.com/lfit/releng-lftools

On 07/20/2017 10:41 AM, Gary Wu wrote:
> Hi Andy,
>
> Can you chime in on how the release process would work (vis-à-vis use of 
> staging repos, artifact signings, etc.) if ONAP decides to have independent 
> version numbers and possibly independent release cycles for each module?
>
> Thanks,
> Gary
>
>
> -Original Message-
> From: 
> onap-discuss-boun...@lists.onap.org
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gino Fraboni
> Sent: Thursday, July 20, 2017 7:04 AM
> To: SPATSCHECK, OLIVER (OLIVER) 
> >; Yunxia
> Chen >
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] Versioning for Amsterdam
>
>
> I'll throw in my +1 for version 2 as well.
> And semantic versioning makes complete sense to me.
>
>
> Gino Fraboni
> Senior Software Developer
> Amdocs Data Experience
>
>
>
> A Platinum member of ONAP
> Read the latest on Amdocs.com and the Amdocs blog network 
> – and follow us on Facebook, Twitter, LinkedIn and YouTube.
>
>
>
> -Original Message-
> From: 
> onap-discuss-boun...@lists.onap.org
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SPATSCHECK,
> OLIVER (OLIVER)
> Sent: Thursday, July 20, 2017 9:54 AM
> To: Yunxia Chen 

[onap-discuss] [aai] API Integration with MSB

[C.T. Paterson]

Hey folks,

I took an action on this week's PTL call to pull together the story for
what we need to do for MSB integration for the AAI APIs, and assess a plan
on whether/when we could get the work done.  Toward the end of the PTL it
sounded like this was optional for Amsterdam, but probably worth looking at.

I think most of the information we need to put together is following an
example at
https://wiki.onap.org/display/DW/ONAP+Services+List#ONAPServicesList-A
(provided by Huabing).  It's probably worth finishing up the table for the
APIs we have for the services (resources, traversal, synapse/data-router,
search, babel, ESR).  Could I ask folks responsible for those items fill in
the table?

What's not clear to me is the specific mechanics of how that data gets
handed between the microservice and MSB?  Murali/Steve, are you able to
shed any more light?  A config file?  A REST call from the service to the
MSB when it comes up?

Please weigh in with your thoughts / knowledge.

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

Re: [onap-discuss] [MSB][OOM]The July Virtual Developers Event Topic : OOM & MSB Interaction

[Sauvageau, David]

Thanks John
And generally speaking let's make sure cloudify remains an option for the 
operators, and not a mandatory component as I believe most operators won't need 
that scale

Envoyé de mon iPhone

Le 26 juil. 2017 à 18:06, NG, JOHN > a 
écrit :

Hi David,
We added a list of user stories to the OOM JIRA.  Not all the user stories will 
make the Amsterdam release by the Functionality Freeze date.  But some will 
make it – especially Consul, component/service registration, state monitoring, 
and TOSCA/Cloudify creating the rest of the OOM modules.  I will update you on 
the demo and seed code.

John

---
John Ng
AT Labs – D2 Architecture
200 Laurel Ave, D5-3D16
Middletown, NJ 07748
+1 732 420 3742
+1 732 310 3253 (mobile)
joh...@att.com
---

From: Sauvageau, David [mailto:david.sauvag...@bell.ca]
Sent: Wednesday, July 26, 2017 7:39 AM
To: NG, JOHN >
Cc: zhao.huab...@zte.com.cn; LUCAS, JACK 
>; HU, JUN NICOLAS 
>; BENNETT, RICH 
>; TORAB, HABIB M 
>; 
roger.maitl...@amdocs.com; MURRAY, JOHN 
>; 
meng.zhaoxi...@zte.com.cn; RATH, CHRISTOPHER 
A >; GAULD, ANDREW G 
>; 
onap-discuss@lists.onap.org
Subject: Re: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction

Hi John

Let’s recap what was discussed and agreed as a team:
* For Amsterdam release, Kubernetes is the first OOM technical implementation 
to be created. This is the seed code available and what the team agreed to work 
on
* The cloudily implementation has not been demoed yet and no seed code 
available. It was agreed by the team that cloudily would be a stretch target.

I want to make sure we align to what the OOM team has agreed to deliver.

Comments?


On Jul 25, 2017, at 6:39 PM, NG, JOHN > 
wrote:

Huabing,
Ok, let’s focus on Consul integration for the Amsterdam release …

-  In Day 0 OOM instantiation, Cloudify is the first OOM module to be 
created.

-  Cloudify creates Consul as the next OOM module.   Cloudify registers 
itself in Consul.

-  Cloudify then creates the rest of the OOM modules (Postgres, API 
Handler, Dashboard), and registers each module in Consul.  And Consul starts 
performing health checks against them.

-  OOM instantiation is now complete.

-  OOM deploys MSB as one of the first ONAP components.  OOM 
provides/configures MSB with the location of the Consul API for access and 
discovery.

-  OOM then continues to deploy the rest of the ONAP components and 
modules, and registers them with Consul.
Comments?

John

---
John Ng
AT Labs – D2 Architecture
200 Laurel Ave, D5-3D16
Middletown, NJ 07748
+1 732 420 3742
+1 732 310 3253 (mobile)
joh...@att.com
---

From: zhao.huab...@zte.com.cn 
[mailto:zhao.huab...@zte.com.cn]
Sent: Monday, July 24, 2017 9:48 PM
To: NG, JOHN >
Cc: LUCAS, JACK >; 
HU, JUN NICOLAS >; BENNETT, RICH 
>; 
david.sauvag...@bell.ca; TORAB, HABIB M 
>; 
roger.maitl...@amdocs.com; MURRAY, JOHN 
>; 
meng.zhaoxi...@zte.com.cn; RATH, CHRISTOPHER 
A >; GAULD, ANDREW G 
>; 
onap-discuss@lists.onap.org
Subject: Re:RE: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction

Hi John,

I'm afraid that I can't agree that.

There is a clear boundary between OOM and MSB and their project scopes are 
totally different. I think these have already been fully discussed in the 
community in the last few months and approved by TSC at the Beijing meeting.

Right now our first priority should be the release goal of Amsterdam and we 
should focus on our last agreement - the integration point at Consul. Given 
that MSB is providing Microservice Infrastructure for ONAP components, I hope 
we can do it ASAP.

Thanks,
Huabing

Re: [onap-discuss] [MSB][OOM]The July Virtual Developers Event Topic : OOM & MSB Interaction

[NG, JOHN]

Hi David,
We added a list of user stories to the OOM JIRA.  Not all the user stories will 
make the Amsterdam release by the Functionality Freeze date.  But some will 
make it – especially Consul, component/service registration, state monitoring, 
and TOSCA/Cloudify creating the rest of the OOM modules.  I will update you on 
the demo and seed code.

John

---
John Ng
AT Labs – D2 Architecture
200 Laurel Ave, D5-3D16
Middletown, NJ 07748
+1 732 420 3742
+1 732 310 3253 (mobile)
joh...@att.com
---

From: Sauvageau, David [mailto:david.sauvag...@bell.ca]
Sent: Wednesday, July 26, 2017 7:39 AM
To: NG, JOHN 
Cc: zhao.huab...@zte.com.cn; LUCAS, JACK ; HU, JUN 
NICOLAS ; BENNETT, RICH ; TORAB, HABIB M 
; roger.maitl...@amdocs.com; MURRAY, JOHN 
; meng.zhaoxi...@zte.com.cn; RATH, CHRISTOPHER A 
; GAULD, ANDREW G ; 
onap-discuss@lists.onap.org
Subject: Re: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction

Hi John

Let’s recap what was discussed and agreed as a team:
* For Amsterdam release, Kubernetes is the first OOM technical implementation 
to be created. This is the seed code available and what the team agreed to work 
on
* The cloudily implementation has not been demoed yet and no seed code 
available. It was agreed by the team that cloudily would be a stretch target.

I want to make sure we align to what the OOM team has agreed to deliver.

Comments?


On Jul 25, 2017, at 6:39 PM, NG, JOHN > 
wrote:

Huabing,
Ok, let’s focus on Consul integration for the Amsterdam release …

-  In Day 0 OOM instantiation, Cloudify is the first OOM module to be 
created.

-  Cloudify creates Consul as the next OOM module.   Cloudify registers 
itself in Consul.

-  Cloudify then creates the rest of the OOM modules (Postgres, API 
Handler, Dashboard), and registers each module in Consul.  And Consul starts 
performing health checks against them.

-  OOM instantiation is now complete.

-  OOM deploys MSB as one of the first ONAP components.  OOM 
provides/configures MSB with the location of the Consul API for access and 
discovery.

-  OOM then continues to deploy the rest of the ONAP components and 
modules, and registers them with Consul.
Comments?

John

---
John Ng
AT Labs – D2 Architecture
200 Laurel Ave, D5-3D16
Middletown, NJ 07748
+1 732 420 3742
+1 732 310 3253 (mobile)
joh...@att.com
---

From: zhao.huab...@zte.com.cn 
[mailto:zhao.huab...@zte.com.cn]
Sent: Monday, July 24, 2017 9:48 PM
To: NG, JOHN >
Cc: LUCAS, JACK >; 
HU, JUN NICOLAS >; BENNETT, RICH 
>; 
david.sauvag...@bell.ca; TORAB, HABIB M 
>; 
roger.maitl...@amdocs.com; MURRAY, JOHN 
>; 
meng.zhaoxi...@zte.com.cn; RATH, CHRISTOPHER 
A >; GAULD, ANDREW G 
>; 
onap-discuss@lists.onap.org
Subject: Re:RE: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction

Hi John,

I'm afraid that I can't agree that.

There is a clear boundary between OOM and MSB and their project scopes are 
totally different. I think these have already been fully discussed in the 
community in the last few months and approved by TSC at the Beijing meeting.

Right now our first priority should be the release goal of Amsterdam and we 
should focus on our last agreement - the integration point at Consul. Given 
that MSB is providing Microservice Infrastructure for ONAP components, I hope 
we can do it ASAP.

Thanks,
Huabing


Original Mail
Sender:  >;
To: zhaohuabing10201488; 
>; 
>; 
>; 
>; 
>; 
>; 
>;MengZhaoXing10024238; 
>; 
>;
CC:  

[onap-discuss] MSO Arquillian unit tests

[Eyal Holzman]

Hello All,

I would happy to get details/document materials on the MSO(SO) Arquillian unit 
tests.
It seems that MSO can build docker images for Arquillian tests and use that 
test frame work.
But I would like to know

* what kind of tests should be implemented in Arquillian

* How to deploy mso arquillian docker

* how to run and debug arquillian test

Thanks,

Eyal Holzmann

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

[onap-discuss] Invitation: [appc] [multicloud] CDP-PAL changes @ Fri Jul 28, 2017 7am - 8am (PDT) (onap-discuss@lists.onap.org)

[kpaul]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170728T14Z
DTEND:20170728T15Z
DTSTAMP:20170727T132625Z
ORGANIZER;CN=ONAP Meetings and Events:mailto:linuxfoundation.org_1rmtb5tpr3
 uc8f76fmflplo...@group.calendar.google.com
UID:2iqon51jse8kalc7i58r2q1...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=vg4...@att.com;X-NUM-GUESTS=0:mailto:vg4...@att.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=onap-discuss@lists.onap.org;X-NUM-GUESTS=0:mailto:onap-discuss@list
 s.onap.org
CREATED:20170727T132625Z
DESCRIPTION:Hi there\, \n\nONAP Meeting 4 is inviting you to a scheduled Zo
 om meeting. \n\nJoin from PC\, Mac\, Linux\, iOS or Android: https://zoom.u
 s/j/434492494\n\nOr iPhone one-tap (US Toll):  +14086380968\,\,434492494# o
 r +16465588656\,\,434492494#\n\nOr Telephone:\nDial: +1 408 638 0968 (U
 S Toll) or +1 646 558 8656 (US Toll)\n+1 855 880 1246 (US Toll Free)\n 
+1 877 369 0926 (US Toll Free)\nMeeting ID: 434 492 494\nInterna
 tional numbers available: https://zoom.us/zoomconference?m=4mMgoGvlidnZC3lN
 bSXxjQxXkgtFGkgS\n\n\n\nView your event at https://www.google.com/calendar/
 event?action=VIEW=Mmlxb241MWpzZThrYWxjN2k1OHIycTFxbjAgb25hcC1kaXNjdXNzQ
 Gxpc3RzLm9uYXAub3Jn=NzIjbGludXhmb3VuZGF0aW9uLm9yZ18xcm10YjV0cHIzdWM4Zjc
 2Zm1mbHBsb2k4OEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNzU5ZDRkMDEzMTZiYTgzMDBlMT
 ZkMjRmNGQwZjg4NDQ3YWQyNzdhMg=America/Los_Angeles=en.
LAST-MODIFIED:20170727T132625Z
LOCATION:https://zoom.us/j/434492494
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[appc] [multicloud] CDP-PAL changes
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] help recording meeting 4 session

[JI, LUSHENG (LUSHENG)]

Hello,

Could the host of ONAP meeting 4 (https://zoom.us/j/824147956) help recording 
the current meeting (DCAE weekly)?

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

[onap-discuss] SDNC AAI-Service adaptor issue

[Prashant Kumar]

Hi ,

I am facing an issue when I am trying to get an AAI resource using AAI-service 
adaptor.

I am getting bad request error due to following code which is adding a request 
property/header


In AAIservice. getConfiguredConnection (URL http_req_url, String method)


con.setRequestProperty(MetricLogger.REQUEST_ID, ml.getRequestID());

This is the code where we are getting error bad request. When I commented this 
code it passed successfully.
Can you please tell me if we need this property or I am missing something here?




Thanks & Regards,
Prashant Kumar
Amdocs-DVCI,Pune
+91-20-4015 5606 (desk)
+91-95525 17927 (mobile)

[cid:image001.png@01D2AEFA.18825F60]

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement, you may review at 
https://www.amdocs.com/about/email-disclaimer 


Amdocs Development Centre India Private Limited having CIN: 
U72200PN2004PTC0188320 converted into Amdocs Development Centre India LLP (A 
limited liability partner­ship with LLP Identification Number: AAI-6901 
effective 28th Feb 2017)
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

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

[Gaoweitao (Victor, MANO)]

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!
*



VF-C  AAI Comparsion V0.1.xlsx
Description: VF-C  AAI Comparsion V0.1.xlsx
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: SDC Questions( SDC Integration slides)

[zhang.maopeng1]

hi SDC team, VFC team,




Here is the analysis results from VFC team and please the SDC team 
confirms with it. 


No


Gaps


Action Owner


 When/Dead Line


1


Import VNF TOSCA Package into SDC Catalog, which supports TOSCA NFV Profile


SDC/Catalog


VoLTE Case profiles has been provided,   Profile need to be confirmed by SDC 
Team this week



2


NS package design supports CSAR and TOSCA NFV template


SDC/Catalog


VoLTE Case profiles has been provided,   Profile need to be confirmed by SDC 
Team this week


3


VNF Distribution


Usecase UI


Usecase UI will be in charge of this function


4


NS/VNF package info query with CSARID


SDC/Catalog


Provided in the API DOC


5


NS/VNF package info query with filter conditions


SDC/Catalog


Provided in the API DOC






Note:


How does the SDC Resource / Service Categories fits to the  the VoLTE case? for 
exmaple spgw/ims etc in which Categories/subCategory? this week


6


Http server to download NS/VNF CSAR packages or templates


SDC/Catalog


Provided in the API DOC


7


SDC Reg/Notify supports TOSCA CSAR packages and interfaces


SDC/Catalog


Not Provided in the API   DOC, need  to be added in the document or provided 
elsewhere by SDC team this week.  


8


VNF distribution function and interfaces


VFC


VNF Distribution has been showed in   the P4


the interfaces referenece:


https://wiki.open-o.org/display/NFVO/NFVO%3ANSLCM+API+Definition 5.1  


9


Provide NS/VNF TOSCA NFV Profile


Model/VFC/SDC


https://gerrit.open-o.org/r/#/admin/projects/modelling-csar


https://gerrit.open-o.org/r/#/admin/projects/modelling-specs


10


Model Parsers integrates with the SDC package output


Model/SDC


Need the SDC team output the TOSCA  Package this week.





I also add the key issues in the wiki:


https://wiki.onap.org/display/DW/July+Virtual+Developers+Event+Blockers 
SDC/VFC integration topic




 Identify the gaps before the functional freeze milestone, here are the 
action items and date.

Need to confirm whether supports importing VNF TOSCA packages into SDC  
 - by 07/28

VoLTE Case TOSCA NFV profiles has been provided, needs the SDC team output the 
TOSCA Packages according to the VoLTE Case -by 07/28

 Need  to provide  reg/notify interfaces in the API document.  -by 07/28

How does the SDC Resource / Service Categories fits to the  the VoLTE case? for 
exmaple spgw/ims etc in which Categories/subCategory?-by 07/28





  We hope the teams from each side can together resolve those issues ASAP, 
thank you.




Best Regards

Maopeng



原始邮件



发件人：张茂鹏10030173
收件人： 
抄送人：  
日 期 ：2017年07月27日 09:32
主 题 ：SDC Questions( SDC Integration slides)






hi kenny, SDC team, VFC team,




The attachment is  SDC Integration slides in the SDC Question topic.




 The CSAR model can be got from the OpenO model as reference. URL is the 
below:

   https://gerrit.open-o.org/r/#/admin/projects/modelling-csar 

   https://gerrit.open-o.org/r/#/admin/projects/modelling-specs 




 Today I will analyze the interfaces provided by SDC team, hope we can 
together make the usecase successful.

 Thanks




Best Regards

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

[onap-discuss] [development] Development practices subcommittee?

[Vitaliy Emporopulo]

Hello fellow ONAPers,

Following yesterday's great session about typical development setups, I have a 
few questions.


1. Is there a dedicated subcommittee for development practices?

2. On the one hand, there's apparently a roadmap for unification of 
development tools and practices, but on the other hand it's not clear who leads 
the effort. There's not much discussion on the [development] topic in this 
mailing list either.

3. I have a few thoughts I'd like to share about the proposed roadmap. What 
would be the right forum to discuss them?

Best regards,
Vitaliy Emporopulo
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

[onap-discuss] [PTLs][MSB] Need your action: Fill In ONAP Microservices Information for MSB Integration with your project

[zhao.huabing]

Dear PTLs,

 

ONAP services need to be registered to MSB to leverage the service 
discovery/routing/LB capabilities of MSB. I created a wiki page to collect all 
the service end points information of ONAP.

 https://wiki.onap.org/display/DW/ONAP+Services+List 




Could you please review them and fill in the table of your project? If you have 
any questions, please let me know, I can organize a meeting for MSB demo and 
introduce the MSB Integration procedure. It's easy and has no invasion to the 
existing codes of each project.


 

Thanks,

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

Re: [onap-discuss] [aai] A local dev setup guide

[Murali p]

Jimmy,

Thanks for sharing and your effort.

I am able to setup successfully.

Few suggestions:


1)  Step 5.h, 5.i  can be run only after Step 6 (after compiling the code)

2)  It would be great if we can have a small video for Step 10.



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FORSYTH, JAMES
Sent: 27 July 2017 02:39
To: 'onap-discuss@lists.onap.org' 
Cc: PRESSLEY, VIVIAN A 
Subject: [onap-discuss] [aai] A local dev setup guide

Hi, All,

As agreed during the VF-C/A session of the Virtual Developer's Event, I have 
a local dev setup guide page posted under the A page on the wiki, complete 
with Postman example scripts for exercising the resources and aai-traverals 
microservices:

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

I welcome feedback and hope that at least our A devs are able to try this 
out locally.

I am in the process of creating a tutorial which illustrates modifying the 
schema, adding a new node type and adding attributes to existing types - look 
for that tomorrow.

Thanks,
jimmy




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