Re: [onap-discuss] 答复: Re: About workflow engine

[zhao.huabing]

Hi Zohar,




We have discussed within SDC team about the design time workflow tool, I can 
show the workflow designer demo in this meeting if you folks are interested.




Thanks,

Huabing







Original Mail



Sender:  
To: ZhangMaoPeng10030173 
CC:  
Date: 2017/07/24 18:58
Subject: Re: [onap-discuss]答复: Re:  About workflow engine 







Hi All


 


We need to have the first meeting this week, let's start with a hour.


I’ve created a doodle scheduling assistant here 
https://doodle.com/poll/zsg9i959suy7f3d7 please mark the slots of your 
convenience today.


 


NOTE all times where set at UTC+3 time zone (not sure id doodle is timezone 
aware)


 


Today EOD I’ll set a meeting to the time convenient to most people


 


Thank you all Z


 


 


From: zhang.maope...@zte.com.cn [mailto:zhang.maope...@zte.com.cn] 
 Sent: Friday, July 21, 2017 10:01 AM
 To: zk0...@intl.att.com
 Cc: seshu.kuma...@huawei.com onap-discuss@lists.onap.org Zohar Sacks 

 Subject: 答复: Re: 答复: Re: [onap-discuss] About workflow engine 


 

Hi Zahi

 

   The meeting time may conflict with the virtual development meeting. 

   IMHO, I think both the design-time and runtime are important.

   We can talk the requirement from the design-time, and also want to discuss 
the possiblity that make the workflow engine  as mirco service and make the 
designer more easy。

 

Best Regards

Maopeng


原始邮件



发件人： 



收件人：张茂鹏10030173



抄送人：    




日 期 ：2017年07月20日 20:59



主 题 ：Re: 答复: Re: [onap-discuss] About workflow engine 




 


I would like to focus our discussion on design-time change management workflows 
(e.g., pause, upgrade etc.) and how current tooling fits into the overall SDC 
architecture and UX.
 
 Can I set a meeting for next Tuesday, 17:00 UTC+3?
 
 Zahi Kapeluto
 Lead Architect, Network Communications LOB
 AT Network Applications Development · SD
 Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
 ·
 Mobile: +972 (54) 6636831
 Office: +972 (3) 9280064
 
 From: "zhang.maope...@zte.com.cn" 
 Date: Thursday, 20 July 2017 at 4:54
 To: ZAHI KAPELUTO 
 Cc: "seshu.kuma...@huawei.com" , 
"onap-discuss@lists.onap.org" , "SACKS, ZOHAR" 

 Subject: 答复: Re: [onap-discuss] About workflow engine
 
 
 Hi Zahi
 
 
 
 Yes, definite.  Workflow engines have different workflow templates. If 
the workflow is designed by user via SDC,  it will effect SDC.
 
 In my mind, some workflow is used by user, maybe some workflow is used 
only by the code developer as well, such as Camunda offline tools, DG offline 
tools,
 
 However  if the workflow design for user can be integrated with SDC 
via portal SDK, It will be greater.
 
 
 
 Best Regards
 
 Maopeng
 原始邮件
 发件人： 
 收件人：张茂鹏10030173  
 抄送人： 
 日 期 ：2017年07月20日 02:27
 主 题 ：Re: [onap-discuss] About workflow engine
 
 
 Can we also have a discussion about the workflow designer (which should be 
part of SDC), its capabilities, proposed architecture etc.?
 
 Zahi Kapeluto
 Lead Architect, Network Communications LOB
 AT Network Applications Development · SD
 Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
 ·
 Mobile: +972 (54) 6636831
 Office: +972 (3) 9280064
 
 From:  on behalf of 
"zhang.maope...@zte.com.cn" 
 Date: Wednesday, 19 July 2017 at 12:46
 To: "seshu.kuma...@huawei.com" , 
"onap-discuss@lists.onap.org" 
 Subject: [onap-discuss] About workflow engine
 
 
 Hi seshu and guys
 
 
 
About the workflow engine(WFE) usage, I have an idea and want to share in 
the community, If I am wrong, please correct me.
 
In the SO or controllers projects of ONAP,  there are many opensource party 
workflow engines, such as Camunda, MSO, DG, aria tosca workflow engine, ...etc.
 
Most of those workflow engines now bind to the project.
 
Workflow engines self are independant fucntion and can be decoupled with 
the specific project logic functions.
 
Could the projects make them as micro service? If some projects use the 
same one,  the WFE instance could be shared among them.
 
If possible, we can create an group or wiki page to discuss the issue.
 
Thanks all.
 
 
 
 Best Regards
 
 Maopeng
 
 
 
 
 
 
 
 
 
 
 
 
 


 





 



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

Re: [onap-discuss] [oom][msb][cli] ONAP component health status

[zhao.huabing]

Hi Kanagaraj,




Yes, you are correct. OOM will be responsible for the health status of each 
service and will also update into MSB.




BR,

Huabing



Original Mail



Sender:  
To:  
CC:  
Date: 2017/07/24 23:57
Subject: [onap-discuss] [oom][msb][cli] ONAP component health status







Dear OOM & MSB team,


 


From CLI, we are planning to provide the commands to report health status for 
each ONAP component, which currently provides a specific REST API for querying 
their health status.


Based on my understanding , in release A, I think that OOM will register all 
micro-services into MSB and from where, all other services/users will discover 
the details of a given micro-service.


As part of it, I have following question:


 


Will OOM update health status of each service will also updated into MSB?  
Thanks.


 


Regards


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!
***___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Draft of TSC Charter Section 5.4.1 Changes

[GILBERT, MAZIN E (MAZIN E)]

Thank you Kenny,

I encourage the ONAP community to review the proposed changes below and provide 
feedback.
We want to finalize this in one week. The TSC will then review and vote.

Mazin



On Jul 24, 2017, at 5:53 PM, Kenny Paul 
> wrote:

The proposed changes to Section 5.4.1 have been posted to the TSC wiki page
 
https://wiki.onap.org/pages/viewpage.action?pageId=4719160

Sorry for the delay but I did not have an editable version of Charter v.7.1 
available to me to redlined and I got that this morning.

What is reflected in the v7.2.1 draft are:
- numbering changes to facilitate a line-by-line vote as was recommended by Ed 
Warnicke
- a page break for the sake of readability
- the text discussed at the July 20th TSC meeting below:

5.4.1.2 Each subcommittee may elect a Chair or Vice-Chair who is responsible 
for leading meetings and representing the subcommittee to the TSC.

5.4.1.3 The Chair or Vice-Chair will be elected by members of the subcommittee 
as of the date the nomination process starts for the election.

5.4.1.4 Voting for a Chair or Vice-Chair not limited to member companies 
however only 1 Subcommittee member from each company, or group of related 
companies (as defined in section 7.4 of the ONAP Project Charter) may vote in 
the election.


Not reflected in this draft is language around from Rajesh Gadiyar, Susana 
Sabater and Bob Monkman around the diversity of participation in leadership 
positions.
I did not include this as A) the language had been inadvertently omitted from 
the discussion and B) the intended scope of those provisions extends beyond the 
specific changes to the topic of Steering Committee elections to also include 
PTL and Community Coordinator roles.  I will with Susana, Bob and Rajesh on the 
specific language around that to be presented at the August 3rd TSC meeting.

Please let me know if you have any questions.

Best Regards,
-kenny

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

___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=UNKen1fs4ejCf862AlleVo3HNxfdUuBM8SAbP3PFpe4=LRP_uTu46KNtzOcv6P8g10MJ2bJjK5l1E3ilxUYG4AM=

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

Re: [onap-discuss] [DCAE] DCAE 1.0.0

[Michael O'Brien]

Shankar,
   Hi, as Marco mentions in a 1.0.0 ONAP environment DCAE only works in 
Rackspace so far, in 1.1 it works in both.
   We had a similar question on the 18th from Serkant.  I checked the page 
below in anticipation of editing it but I will leave the clause as-is

DCAE-VERSION

1.1.0

Note only 1.1.0 version is working outside of Rackspace


   There is a video of closed-loop (requires DCAE) for 1.0.0 on Rackspace at
https://wiki.onap.org/display/DW/Installing+and+Running+the+ONAP+Demos
Closed loop partial details
https://wiki.onap.org/display/DW/Tutorial%3A+Verifying+and+Observing+a+deployed+Service+Instance
   thank you
   /michael


From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of PLATANIA, MARCO 
(MARCO)
Sent: Monday, July 24, 2017 16:02
To: Cipher Cipher ; 
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [DCAE] DCAE 1.0.0

Hello Shankar,

You are right. DCAE (and MSO) have been modified to work in vanilla OpenStack 
since seed code 1.1.0 (current master branch). Seed code release 1.0.0 supports 
Rackspace only.

Please refer to the wiki page below for information about ONAP installation in 
vanilla OpenStack: 
https://wiki.onap.org/display/DW/ONAP+Installation+in+Vanilla+OpenStack

Thanks,
Marco


From: 
>
 on behalf of Cipher Cipher 
>
Date: Monday, July 24, 2017 at 3:08 PM
To: "onap-discuss@lists.onap.org" 
>
Subject: [onap-discuss] [DCAE] DCAE 1.0.0

Hey,

According to the DCAE controller 
guide(https://wiki.onap.org/display/DW/DCAE+Controller+Development+Guide),
 it doesn't work in release-1.0.0. But I have already ONAP release-1.0.0 up and 
running, so to make DCAE working, we have to replace ONAP with new version? or 
is there any alternatives?

Cheers
Shankar
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] Draft of TSC Charter Section 5.4.1 Changes

[Kenny Paul]

The proposed changes to Section 5.4.1 have been posted to the TSC wiki page
 https://wiki.onap.org/pages/viewpage.action?pageId=4719160 


Sorry for the delay but I did not have an editable version of Charter v.7.1 
available to me to redlined and I got that this morning. 

What is reflected in the v7.2.1 draft are:
- numbering changes to facilitate a line-by-line vote as was recommended by Ed 
Warnicke
- a page break for the sake of readability
- the text discussed at the July 20th TSC meeting below:

5.4.1.2 Each subcommittee may elect a Chair or Vice-Chair who is responsible 
for leading meetings and representing the subcommittee to the TSC.

5.4.1.3 The Chair or Vice-Chair will be elected by members of the subcommittee 
as of the date the nomination process starts for the election.

5.4.1.4 Voting for a Chair or Vice-Chair not limited to member companies 
however only 1 Subcommittee member from each company, or group of related 
companies (as defined in section 7.4 of the ONAP Project Charter) may vote in 
the election.


Not reflected in this draft is language around from Rajesh Gadiyar, Susana 
Sabater and Bob Monkman around the diversity of participation in leadership 
positions.  
I did not include this as A) the language had been inadvertently omitted from 
the discussion and B) the intended scope of those provisions extends beyond the 
specific changes to the topic of Steering Committee elections to also include 
PTL and Community Coordinator roles.  I will with Susana, Bob and Rajesh on the 
specific language around that to be presented at the August 3rd TSC meeting.

Please let me know if you have any questions.

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

Re: [onap-discuss] vCPE use case review at virtual developer event

[Kang Xi]

Hi All,

In tomorrow's virtual develop event vCPE session, I plan to give a quick 
presentation of the architecture on the wiki, the service model and flows from 
Gil's slides, and closed loop design from Ron's slides. Given that we only have 
50min, I'll keep the presentation short and give more time for open 
discussions. Most likely we won't have enough time to completely answer all 
possible questions but I'll write them down to help continue the discussions 
offline. If you have any questions/comments that you want to share in advance, 
please feel free to reply this email before the meeting.

Useful materials:

-Use case wiki page: 
https://wiki.onap.org/pages/viewpage.action?pageId=3246168

-Important questions: 
https://wiki.onap.org/display/DW/Use+Case+Related+Important+Questions+and+Answers

Regards,
Kang

From: Kang Xi
Sent: Thursday, July 20, 2017 15:40
To: 'onap-discuss@lists.onap.org' 
Cc: 'SHACHAM, RON (RON)' ; NGUEKO, GERVAIS-MARTIAL 
; DRAGOSH, PAMELA L (PAM) ; 
Pawłowski Michał 1 - Korpo ; TAYLOR, JON 
; Alla Goldner ; Yunxia Chen 
; Yang Xu (Yang, Fixed Network) ; 
KLUGER, YOAV ; Seshu m ; 
denghui (L) ; Zhou, Danny ; 
'FREEMAN, BRIAN D' ; SPATSCHECK, OLIVER 
; Lefevre, Catherine ; Chong Li 
; Mengqiang ; ROSE, DANIEL V 
; TIMONEY, DAN ; 'GUPTA, ALOK' 
; KLEIN, REUBEN ; MAHER, RANDA 
Subject: vCPE use case review at virtual developer event

Hi All,

We will have a vCPE use case review in next week's virtual developer event. 
Please sign up at the following link if you are interested. Thanks.
https://wiki.onap.org/pages/viewpage.action?pageId=8232264


Regards,
Kang

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

[onap-discuss] [DCAE] DCAE 1.0.0

[Cipher Cipher]

Hey,

According to the DCAE controller guide(
https://wiki.onap.org/display/DW/DCAE+Controller+Development+Guide), it
doesn't work in release-1.0.0. But I have already ONAP release-1.0.0 up and
running, so to make DCAE working, we have to replace ONAP with new version?
or is there any alternatives?

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

Re: [onap-discuss] Architecture Progress

[Thomas Nadeau]

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of denghui (L)
Sent: Saturday, July 22, 2017 6:52 AM
To: Alla Goldner ; Pasi Vaananen 
; onap-discuss@lists.onap.org
Cc: onap-tsc 
Subject: Re: [onap-discuss] Architecture Progress

Hi all

I guess that people are confusing about the interface of VNF  with ONAP 
architecture,
Interface between VNF and ONAP is quite simple : Heat(ECOMP) or TOSCA(OPEN-O), 
it has nothing with architecture discussion.

I agree with Chris's suggestion here, either you need to understand the 
implementation or join architecture call.

TOM: I'd say that its actually both.

--Tom



Best regards,

DENG Hui

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Saturday, July 22, 2017 1:56 PM
To: Pasi Vaananen >; 
onap-discuss@lists.onap.org
Cc: onap-tsc >
Subject: Re: [onap-discuss] Architecture Progress

Hi Pasi, Jamil, Chris, all,

I fully agree with Pasi's view.
When we started this work ,the assumption was that whatever our merged 
architecture will look like internally, we should deliver a single set of 
interfaces between the VNFs and ONAP.
And this is not what we are having right now with R1 proposed architecture.
Also, indeed, if we allow interfaces' divergence for R1, it is going to be hard 
to reverse later. One possible outcome is that some of VNF vendors would want 
to wait until the divergences are resolved. The other possible outcome is that 
we continue proceeding with 2 different tracks within ONAP - one coming from 
Open-O and the other one coming from ecomp, and each one of VNF vendors making 
a decision which track they want/need to support, in some cases having a need 
to support both thus doubling the effort. The latter is clearly not the optimal 
way forward, and not what we want to achieve with ONAP, we should try to see 
how we avoid it at least in a longer term, in my view. The former may be 
significantly improved and timelines may be shortened, if we manage to work on 
it effectively now and provide the shortest path to get there from the current 
state - and Vimal's proposal of target merged architecture looks like a great 
step towards it, preserving all functionality coming from APPC and VF-C, but 
making a single set of external interfaces. I think we should give a very high 
priority to those discussions and handle them now, in parallel to R1 work.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image002.png@01D30485.543CD270]

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Pasi Vaananen
Sent: Friday, July 21, 2017 11:15 PM
To: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] Architecture Progress


Hi Jamil,

In ONAP F2F in New Jersey, there was what I thought was "agreement" that there 
is to be only one set of VNFDs / interfaces for ONAP. If that is strictly 
enforced (like I think it should be, as these collectively form the "interface" 
between the VNF vendors and ONAP - if the overlap would be e.g. on NS level 
descriptors, it would not be as bad, as those could be considered to be system 
internal and therefore not as much of inter-operability problem), then having 
two parallel implementations means that they would need to do exactly the same 
things, and be essentially "indistinguishable" from each other even on their 
behaviors associated with these descriptors and interfaces.

Obviously, strict enforcement of this would imply about 100% overlap on the 
associated development, testing, etc. activities (minus any sharing of code 
between the teams). And, in addition, coordination between the two teams to 
accomplish the required level of agreement in absence of the independent / 
detailed specification that is to be implemented, which would further slow 
things down.

If ONAP community chooses to allow divergence here for r1, it is going to be 
hard to reverse later (assuming that someone would pick sides and actually 
deploy the result - more likely outcome is that VNF vendors would want to wait 
until the divergences are resolved, i.e. R2 at the earliest per current 
"plan"). It is also going to be difficult to "push back" on e.g. ETSI and OASIS 
on descriptors etc. if ONAP community itself cant get into one opinion on what 
to push.

I like Vimal's "Target Merged Architecture" slide #3 at high level - what is 
the shortest path to get there from the current state ?

Regards,

Pasi

On 07/21/2017 03:09 PM, jamil.cha...@orange.com 
wrote:
Hi Chris
I have participated 

[onap-discuss] [oom] Application deployment configuration template

[Avi Chapnick]

Dear OOM members,

Following our meeting last week , I have updated OOM wiki with the proposal 
presentation and added section which describe the application deployment 
configuration template yaml file. (page  5-6)

I will appreciate your review and comments before working with the components 
for creating the per application files.

https://wiki.onap.org/pages/worddav/preview.action?fileName=ONAP+CM+v3.pptx=8229355


Thanks,

Avi Chapnick

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] Robot vm script automation

[Michael O'Brien]

Brian,
   Yes, thanks for the info.  I was aware that env data is overridden - but 
from a design perspective I understood the intent that env should override 
preload.  However in view of some of the comments and thinking of it some more 
- it may be that the env file is actually the template and the preload 
overrides per instance (would make sense otherwise we would need to re-zip the 
vFW heat/env combo for each instance).

So the current override behavior makes sense - especially for multiple 
instances of the vFW.
Thank you
/michael

From: FREEMAN, BRIAN D [mailto:bf1...@att.com]
Sent: Monday, July 24, 2017 08:27
To: FLOOD, JERRY ; ROSE, DANIEL V ; Michael 
O'Brien ; Josef Reisinger 
; PLATANIA, MARCO 
Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
Subject: RE: [onap-discuss] Robot vm script automation

Not sure if folks realize that sdn preload data over rides the .env file. 
Openstack merges the .env and the parameters passed into the heat stack create 
API so you can either dynamically create the .env or use the parameters from 
the sdnc preload (or any other mechanism to create the dyanmic parameters)  to 
set instance specific data.

Brian


From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FLOOD, JERRY
Sent: Tuesday, June 27, 2017 6:03 PM
To: ROSE, DANIEL V >; OBRIEN, FRANK 
MICHAEL >; Josef 
Reisinger >; 
PLATANIA, MARCO >
Cc: onap-discuss@lists.onap.org; 
ajay.priyadar...@ril.com
Subject: Re: [onap-discuss] Robot vm script automation

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Ajay
Michael

The preload values for the demo VFW originate from the following section of the 
integration_preload_parameters.py.

# heat template parameter values for heat template instances created for hands 
on demo test case
  "Demo" : {
   "vfw_preload.template": {
   "unprotected_private_net_id" : "demofwl_unprotected",
   "unprotected_private_net_cidr" : "192.168.110.0/24",
   "protected_private_net_id" : "demofwl_protected",
   "protected_private_net_cidr" : "192.168.120.0/24",
   "vfw_private_ip_0" : "192.168.110.100",
   "vfw_private_ip_1" : "192.168.120.100",
   "vfw_private_ip_2" : "10.1.${ecompnet}.11",
   "vpg_private_ip_0" : "192.168.110.200",
   "vpg_private_ip_1" : "10.1.${ecompnet}.12",
   "vsn_private_ip_0" : "192.168.120.250",
   "vsn_private_ip_1" : "10.1.${ecompnet}.13",
   'vfw_name_0':'demofwl01fwl',
   'vpg_name_0':'demofwl01pgn',
   'vsn_name_0':'demofwl01snk',

The values here were not intended to support more than 1 simultaneous instance 
of the demo vFW. Changing network ids  and host names  (in red) should enable 
simultaneous instantiations.

Note that the automated ETE configurations use a dynamically generated 
${hostid} to uniquely identify network ids  and host names (in red) to enable 
simultaneous instantiations. This pattern may be used for the "Demo" section as 
well

# heat template parameter values for heat template instances created during 
Vnf-Orchestration test cases
"Vnf-Orchestration" : {
"vfw_preload.template": {
"unprotected_private_net_id" : "vofwl01_unprotected${hostid}",
"unprotected_private_net_cidr" : "192.168.10.0/24",
   "protected_private_net_id" : "vofwl01_protected${hostid}",
"protected_private_net_cidr" : "192.168.20.0/24",
"vfw_private_ip_0" : "192.168.10.100",
"vfw_private_ip_1" : "192.168.20.100",
"vfw_private_ip_2" : "10.1.${ecompnet}.1",
"vpg_private_ip_0" : "192.168.10.200",
"vpg_private_ip_1" : "10.1.${ecompnet}.2",
"vsn_private_ip_0" : "192.168.20.250",
"vsn_private_ip_1" : "10.1.${ecompnet}.3",
'vfw_name_0':'vofwl01fwl${hostid}',
'vpg_name_0':'vofwl01pgn${hostid}',
'vsn_name_0':'vofwl01snk${hostid}',
},

A note about the ${ecompnet} parameter. This is  GLOBAL_BUILD_NUMBER%255 (-v 
GLOBAL_BUILD_NUMBER:1928 from the example below). These IPs are part of the 
ONAP OAM network defined by the ONAP heat template (subnet 10.0.0.0/8). Use of 
${ecompnet}  minimizes the potential for conflict on these network resources.

For complete control of preload values, you can modify the network ids, host 
names and ${ecompnet}  in the "Demo" section for each instantiation  

Re: [onap-discuss] VoLTE use case discussion with SDC team

[Lingli Deng]

Adding onap-list for more input and feedback.

 

Thanks,

Lingli

 

From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
Sent: 2017年7月24日 17:34
To: Yang Xu (Yang, Fixed Network) 
Cc: Lando,Michael ; Alla Goldner
; Seshu m ; TAYLOR, JON
; Kang Xi ; Lingli Deng
; Lansky, Boris ; Kapeluto,
Zahi ; Rozin, Eden ; KACHOROVSKY,
ARKADY 
Subject: Re: VoLTE use case discussion with SDC team

 

More clarifications and update inlines.

 

 

在 2017年7月24日，下午1:21，Yang Xu (Yang, Fixed Network)
 > 写道：

 

Hi Michael,

 

“VoLTE Service Design and Instantiation” session will be on July 25 at
2:10pm UTC. Who from your team can join the session to help us?

 

I have the following specific questions to discuss with your team during the
session:

 

Basic assumptions: 

1. VoLTE service has 2 VNFs NSs(Network Service) - vIMS and vEPC, this will
maximize the flexibility of service deployment, e.g. only deploy vEPC. 

2. VNF template defines the networks it will use. If VNF modules (e.g. MME
and SPGW for vEPC) are connected by one network but deployed in two data
centers, L2 VXLAN overlay between DC-GW will be set up to bridge the two
parts of the same network together.  

 

Questions/Requirements on SDC and SO:

   Can SDC design VNF/NS packages based on TOSCA?



1. Can SDC import and parse TOSCA VNF template?

   How SDN support to design WAN overlay/underlay models. How to input
parameters when instantiate the connection service?



2. Assume 3rd part SDN Controllerphysical PNFs (DC-GW and PE) are registered
with A/ESR. Can SDC pull the information from A/ESR and display it in
SDC portal as network resource for design?

3. Can SDC create VLAN type connection between DC-GW and PE, and allow VID
to set up VLAN id at deployment time? 

4. Can SDC create BGP MPLS L3VPN type connection between two PEs?

5. Can SDC create EVPN L2/L3 VXLAN type connection as overlay network
between two DC-GWs, and allow VID to set up VXLAN ID, IRT and ERT? (we
assume in R1 all networks on DC-GW will be exported by EVPN).

6. Can SDC put together the two VNFs templates and inter/intra DC network
template together, and create one E2E service template? 

7. Can SO parse the service template and call SDNC to create network and VFC
to create 2 VNFsNSs with all the information imported and collected by SDC
and VID?

 

If anyone from your team wants to discuss earlier before the session, please
set up a time with me. 

 

Thanks,

-Yang 

 

 

 

_
From: Yang Xu (Yang, Fixed Network) 
Sent: Thursday, July 20, 2017 3:30 PM
To: 'Lando,Michael'; 'Alla Goldner'; Seshu m
Cc: 'Chengli Wang'; 'TAYLOR, JON'; Kang Xi; 'Lingli Deng'; 'Lansky, Boris';
'Kapeluto, Zahi'; 'Rozin, Eden'; 'KACHOROVSKY, ARKADY'
Subject: RE: VoLTE use case discussion with SDC team

 

 

Correction: the event signup page is:
https://wiki.onap.org/pages/viewpage.action?pageId=8232264. Thanks Kang for
pointing out.

 

-Yang

 

_
From: Yang Xu (Yang, Fixed Network) 
Sent: Thursday, July 20, 2017 1:20 PM
To: 'Lando,Michael'; Alla Goldner; Seshu m
Cc: Chengli Wang; TAYLOR, JON; Kang Xi; Lingli Deng; Lansky, Boris;
Kapeluto, Zahi; Rozin, Eden; KACHOROVSKY, ARKADY
Subject: VoLTE use case discussion with SDC team

 

 

Hi Michael and SDC team,

 

VoLTE use case has a few requirements which need SDC team to support for R1.
For example: 

 

* VNF template format support (TOSCA/HEAT)

* vEPC and vIMS VNF templates upload

* Network service design for WAN underlay and overlay networks, and
network between two VNFs

* SDC output content and format

 

I have created a discussion topic in next week’s ONAP virtual developer
event, the title is “VoLTE Service Design and Instantiation”. Please sign
up at https://wiki.onap.org/pages/viewpage.action?pageId=8232264/.

 

Also, if you have time to discuss the topics earlier before next week event,
please let me know and I can set up a meeting. 

 

Thanks,

-Yang

 

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

Re: [onap-discuss] Robot vm script automation

[FREEMAN, BRIAN D]

Not sure if folks realize that sdn preload data over rides the .env file. 
Openstack merges the .env and the parameters passed into the heat stack create 
API so you can either dynamically create the .env or use the parameters from 
the sdnc preload (or any other mechanism to create the dyanmic parameters)  to 
set instance specific data.

Brian


From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FLOOD, JERRY
Sent: Tuesday, June 27, 2017 6:03 PM
To: ROSE, DANIEL V ; OBRIEN, FRANK MICHAEL 
; Josef Reisinger ; 
PLATANIA, MARCO 
Cc: onap-discuss@lists.onap.org; ajay.priyadar...@ril.com
Subject: Re: [onap-discuss] Robot vm script automation

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Ajay
Michael

The preload values for the demo VFW originate from the following section of the 
integration_preload_parameters.py.

# heat template parameter values for heat template instances created for hands 
on demo test case
  "Demo" : {
   "vfw_preload.template": {
   "unprotected_private_net_id" : "demofwl_unprotected",
   "unprotected_private_net_cidr" : "192.168.110.0/24",
   "protected_private_net_id" : "demofwl_protected",
   "protected_private_net_cidr" : "192.168.120.0/24",
   "vfw_private_ip_0" : "192.168.110.100",
   "vfw_private_ip_1" : "192.168.120.100",
   "vfw_private_ip_2" : "10.1.${ecompnet}.11",
   "vpg_private_ip_0" : "192.168.110.200",
   "vpg_private_ip_1" : "10.1.${ecompnet}.12",
   "vsn_private_ip_0" : "192.168.120.250",
   "vsn_private_ip_1" : "10.1.${ecompnet}.13",
   'vfw_name_0':'demofwl01fwl',
   'vpg_name_0':'demofwl01pgn',
   'vsn_name_0':'demofwl01snk',

The values here were not intended to support more than 1 simultaneous instance 
of the demo vFW. Changing network ids  and host names  (in red) should enable 
simultaneous instantiations.

Note that the automated ETE configurations use a dynamically generated 
${hostid} to uniquely identify network ids  and host names (in red) to enable 
simultaneous instantiations. This pattern may be used for the "Demo" section as 
well

# heat template parameter values for heat template instances created during 
Vnf-Orchestration test cases
"Vnf-Orchestration" : {
"vfw_preload.template": {
"unprotected_private_net_id" : "vofwl01_unprotected${hostid}",
"unprotected_private_net_cidr" : "192.168.10.0/24",
   "protected_private_net_id" : "vofwl01_protected${hostid}",
"protected_private_net_cidr" : "192.168.20.0/24",
"vfw_private_ip_0" : "192.168.10.100",
"vfw_private_ip_1" : "192.168.20.100",
"vfw_private_ip_2" : "10.1.${ecompnet}.1",
"vpg_private_ip_0" : "192.168.10.200",
"vpg_private_ip_1" : "10.1.${ecompnet}.2",
"vsn_private_ip_0" : "192.168.20.250",
"vsn_private_ip_1" : "10.1.${ecompnet}.3",
'vfw_name_0':'vofwl01fwl${hostid}',
'vpg_name_0':'vofwl01pgn${hostid}',
'vsn_name_0':'vofwl01snk${hostid}',
},

A note about the ${ecompnet} parameter. This is  GLOBAL_BUILD_NUMBER%255 (-v 
GLOBAL_BUILD_NUMBER:1928 from the example below). These IPs are part of the 
ONAP OAM network defined by the ONAP heat template (subnet 10.0.0.0/8). Use of 
${ecompnet}  minimizes the potential for conflict on these network resources.

For complete control of preload values, you can modify the network ids, host 
names and ${ecompnet}  in the "Demo" section for each instantiation  or you can 
update the "Demo" section to follow the "Vnf-Orchestration" pattern using 
${hostid} and ${ecompnet} to enable simultaneous instantiations with generated 
host and network ids.

Later
Jerry


From: ROSE, DANIEL V
Sent: Tuesday, June 27, 2017 4:24 PM
To: OBRIEN, FRANK MICHAEL; Josef Reisinger; FLOOD, JERRY; PLATANIA, MARCO
Cc: onap-discuss@lists.onap.org; 
ajay.priyadar...@ril.com
Subject: RE: [onap-discuss] Robot vm script automation

Good find, can you look at this jerry or marco?

Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308

From: OBRIEN, FRANK MICHAEL
Sent: Monday, June 26, 2017 11:18 PM
To: ROSE, DANIEL V >; Josef Reisinger 
>
Cc: onap-discuss@lists.onap.org; 
ajay.priyadar...@ril.com
Subject: RE: [onap-discuss] Robot vm script automation

Ajay,
   Yes, there is an open jira on these hardcoded values (changes to your env 
have no effect over the sample values).  Until this is fixed you can only have 
one instance of the 

Re: [onap-discuss] 答复: Re: About workflow engine

[Zohar Sacks]

Hi All

We need to have the first meeting this week, let's start with a hour.
I’ve created a doodle scheduling assistant here 
https://doodle.com/poll/zsg9i959suy7f3d7 please mark the slots of your 
convenience today.

NOTE all times where set at UTC+3 time zone (not sure id doodle is timezone 
aware)

Today EOD I’ll set a meeting to the time convenient to most people

Thank you all Z


From: zhang.maope...@zte.com.cn [mailto:zhang.maope...@zte.com.cn]
Sent: Friday, July 21, 2017 10:01 AM
To: zk0...@intl.att.com
Cc: seshu.kuma...@huawei.com; onap-discuss@lists.onap.org; Zohar Sacks 

Subject: 答复: Re: 答复: Re: [onap-discuss] About workflow engine


Hi Zahi



   The meeting time may conflict with the virtual development meeting.

   IMHO, I think both the design-time and runtime are important.

   We can talk the requirement from the design-time, and also want to discuss 
the possiblity that make the workflow engine  as mirco service and make the 
designer more easy。



Best Regards

Maopeng
原始邮件
发件人： >;
收件人：张茂鹏10030173;
抄送人： >; 
>; 
>;
日 期 ：2017年07月20日 20:59
主 题 ：Re: 答复: Re: [onap-discuss] About workflow engine


I would like to focus our discussion on design-time change management workflows 
(e.g., pause, upgrade etc.) and how current tooling fits into the overall SDC 
architecture and UX.

Can I set a meeting for next Tuesday, 17:00 UTC+3?

Zahi Kapeluto
Lead Architect, Network Communications LOB
AT Network Applications Development · SD
Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
·
Mobile: +972 (54) 6636831
Office: +972 (3) 9280064

From: "zhang.maope...@zte.com.cn" 
>
Date: Thursday, 20 July 2017 at 4:54
To: ZAHI KAPELUTO >
Cc: "seshu.kuma...@huawei.com" 
>, 
"onap-discuss@lists.onap.org" 
>, "SACKS, 
ZOHAR" >
Subject: 答复: Re: [onap-discuss] About workflow engine


Hi Zahi



Yes, definite.  Workflow engines have different workflow templates. If 
the workflow is designed by user via SDC,  it will effect SDC.

In my mind, some workflow is used by user, maybe some workflow is used 
only by the code developer as well, such as Camunda offline tools, DG offline 
tools,

However  if the workflow design for user can be integrated with SDC via 
portal SDK, It will be greater.



Best Regards

Maopeng
原始邮件
发件人： >;
收件人：张茂鹏10030173; >; 
>;
抄送人： >;
日 期 ：2017年07月20日 02:27
主 题 ：Re: [onap-discuss] About workflow engine


Can we also have a discussion about the workflow designer (which should be part 
of SDC), its capabilities, proposed architecture etc.?

Zahi Kapeluto
Lead Architect, Network Communications LOB
AT Network Applications Development · SD
Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
·
Mobile: +972 (54) 6636831
Office: +972 (3) 9280064

From: 
>
 on behalf of "zhang.maope...@zte.com.cn" 
>
Date: Wednesday, 19 July 2017 at 12:46
To: "seshu.kuma...@huawei.com" 
>, 
"onap-discuss@lists.onap.org" 
>
Subject: [onap-discuss] About workflow engine


Hi seshu and guys



   About the workflow engine(WFE) usage, I have an idea and want to share in 
the community, If I am wrong, please correct me.

   In the SO or controllers projects of ONAP,  there are many opensource party 
workflow engines, such as Camunda, MSO, DG, aria tosca workflow engine, ...etc.

   Most of those workflow engines now bind to the project.

   Workflow engines self are independant fucntion and can be decoupled with the 
specific project logic functions.

   Could the projects make them as micro service? If some projects use the 
same one,  the WFE instance could be shared among them.

   If possible, we can create an group or wiki page to discuss the issue.

   Thanks all.



Best Regards

Maopeng