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

[zhao.huabing]

Hi Michael,





Were you able to go to the meeting? Please let me know if you have any question 
about my presentation.

I'd like to start the integration job ASAP.




Thanks,

Huabing













Original Mail



Sender:  
To:  
Date: 2017/07/22 01:54
Subject: Re: [onap-discuss][MSB][OOM]The July Virtual Developers Event Topic :  
OOM & MSB Interaction







Huabing,


I will be there – added my name yesterday (in an OOM context).  Sorry I 
missed the extra OOM meet last night at 2100: I accidentally fell asleep.


/michael


 


From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of 
zhao.huab...@zte.com.cn
 Sent: Friday, July 21, 2017 02:33
 To: jflu...@research.att.com jh2...@att.com rb2...@att.com 
david.sauvag...@bell.ca ht1...@att.com Roger Maitland 
 j...@research.att.com jn1...@att.com 
meng.zhaoxi...@zte.com.cn zhao.huab...@zte.com.cn
 Cc: onap-discuss@lists.onap.org
 Subject: [onap-discuss] [MSB][OOM]The July Virtual Developers Event Topic :  
OOM & MSB Interaction


 

Hi there,

 

Will you be able to attend this topic:  OOM & MSB Interaction? I would 
appreciate it if both OOM team and the AT&T cloudify proposal folks could join 
to discuss it.

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

 

Thanks,

Huabing

 

 

 

 



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] 答复: 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&T Network Applications Development · SD&E
 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&T Network Applications Development · SD&E
 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 
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] [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 
mailto:kp...@linuxfoundation.org>> 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&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=UNKen1fs4ejCf862AlleVo3HNxfdUuBM8SAbP3PFpe4&s=LRP_uTu46KNtzOcv6P8g10MJ2bJjK5l1E3ilxUYG4AM&e=

___
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: 
mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of Cipher Cipher 
mailto:cipher.for.programm...@gmail.com>>
Date: Monday, July 24, 2017 at 3:08 PM
To: "onap-discuss@lists.onap.org" 
mailto: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] Architecture Progress

[Christopher Donley (Chris)]

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&T 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 in the conversation.

Now, this architecture is a high-level target, and there is more work to be 
done to get to the next level of detail (e.g., mapping projects into the 
structure, defining interfaces, and then looking at code).  That work is being 
driven by the affected projects, and I can attest that several project-level 
meetings have occurred to start the conversation (in parallel with R1 work and 
prior to R2 planning).  I feel strongly that this is the right approach, with 
the architecture subcommittee providing cross-project support, advice, and 
coordination, but the decisions regarding how best to align the projects with 
the framework are made by the projects themselves. Tom, to your point, the 
projects will come back to the architecture subcommittee after they have worked 
out some of the details, and we may need to iterate the architecture based on 
their findings.

Chris

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Thomas Nadeau
Sent: Monday, July 24, 2017 11:55 AM
To: Alla Goldner ; Pasi Vaananen 
; onap-discuss@lists.onap.org
Cc: onap-tsc 
Subject: Re: [onap-tsc] [onap-discuss] Architecture Progress


  Hi,

  I've read through all the messages on this thread this afternoon, 
and have a few things to add from my past experiences with open source projects 
that might help level set things and also help clarify the confusion that I 
sense some people are experiencing in why this combined architecture isn't 
moving forward as swiftly as some would like it to.  In my opinion, the answer 
to this is how open source projects often do not easily accept top-down 
management approaches, and how they more typically respond.  In this case, an 
architecture has been created that is now shown to projects with the 
expectation that they will comply with it - whether or not the subordinate 
project agrees with the architecture, or has the time to do so.  It is also 
important to observe that the merged architecture, objectively speaking is a 
*desired* architecture; it is not a picture of the existing project components. 
  That is, it is one to aspire to at some point in the future, and not 
necessarily as part of the next release.  It is this specific point that is 
giving people the most heartburn: the prospect of this picture not becoming 
reality in the next release.

The reality is that the task of getting the subordinate projects to retool 
themselves in order to go along with a unified architecture is more challenging 
than writing an architectural document and telling the projects to follow it.  
I know many in this project would like the process here to be that 
straightforward, but it is turning out once again to not be. Understanding why 
and embracing this reality is the key to moving this project forward.  
Constituent projects need to get working and figure out how they will implement 
the merges in their code bases, and then figure out when/how this will be 
scheduled in the master release schedule for the project.  This has

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

[PLATANIA, MARCO (MARCO)]

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
___
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]

  Hi,

  I've read through all the messages on this thread this afternoon, 
and have a few things to add from my past experiences with open source projects 
that might help level set things and also help clarify the confusion that I 
sense some people are experiencing in why this combined architecture isn't 
moving forward as swiftly as some would like it to.  In my opinion, the answer 
to this is how open source projects often do not easily accept top-down 
management approaches, and how they more typically respond.  In this case, an 
architecture has been created that is now shown to projects with the 
expectation that they will comply with it - whether or not the subordinate 
project agrees with the architecture, or has the time to do so.  It is also 
important to observe that the merged architecture, objectively speaking is a 
*desired* architecture; it is not a picture of the existing project components. 
  That is, it is one to aspire to at some point in the future, and not 
necessarily as part of the next release.  It is this specific point that is 
giving people the most heartburn: the prospect of this picture not becoming 
reality in the next release.

The reality is that the task of getting the subordinate projects to retool 
themselves in order to go along with a unified architecture is more challenging 
than writing an architectural document and telling the projects to follow it.  
I know many in this project would like the process here to be that 
straightforward, but it is turning out once again to not be. Understanding why 
and embracing this reality is the key to moving this project forward.  
Constituent projects need to get working and figure out how they will implement 
the merges in their code bases, and then figure out when/how this will be 
scheduled in the master release schedule for the project.  This has to happen 
before people start building any new functionality including that that is 
likely needed to address the desired merged architecture for a number of 
components.  No amount of wishful thinking or mandates is going to change this. 
 I say this because I am observing that right now there are still discussions 
within projects about how to go about addressing their backlogs. This tells me 
that the blocking, tackling and scaffolding needs to be setup for projects to 
function before we talk about other things.  This is an indication that it 
might just be a bit early to be asking projects to figure out how to exist 
within a merged architecture - or pay attention to the details of one. It might 
also turn out that after a phase of implementation, that the system 
architecture needs to be different that is postulated in the desired merged 
architecture.  Its nice to start with a nice and detailed architectural plan 
for what everything is supposed to look like at the end of a project, but we 
have to be patient in how we get there and also understand that in modern 
software engineering, is rare to have it all figured out a priori.

With that in mind, it appears that as of now that it is going to be difficult 
to see a way forward where all the lego blocks come together from each project, 
have been rewritten to accommodate the desired merged architecture and 
requirements, and do so in time for the next release.  That also assumes that 
all of the projects agree on where they are going - which from what this thread 
sounds like is not exactly the case right now. One way less resistive path 
forward is to start by agreeing to disagree on certain portions of the 
architecture, while recognizing the portions of the architecture that do enjoy 
buy-in from a significant number of people.  Next, do what we did in past 
projects: release multiple options simultaneously and let derivatives repackage 
as necessary downstream until such time as the developers are pushed in one way 
or the other. If some projects do have time to start down the road of the 
desired architecture, then great, but if they do not accept that and work on 
simply getting them out in as stable a form as possible.  To this end, perhaps 
focus the integration teams on making sure that all the components build and 
can be tested to some degree and that the major functional "core" components 
work.  Then as projects gradually build better successor components in the mold 
of the desired architecture, the old ones will be deprecated.

This is decidedly not as clean as some would like it to be and will take time 
and patience for sure, but in the end I think will bring valuable 
implementation and deployment feedback to the party and that after some 
iteration and feedback, will help projects make better decisions on what to 
build going forward.  It will also result in a project and components that are 
built to meet the goals of the project, which is what I hope and think we are 
all after.

  --Tom



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@list

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 mailto:pvaan...@redhat.com>>; 
onap-discuss@lists.onap.org
Cc: onap-tsc mailto:onap-...@lists.onap.org>>
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 partially to the last 2 meetings, my position was 
represented by Vimal. We need time to analyse the output before to take a 

Re: [onap-discuss] Architecture Progress

[jamil.chawki]

Hui Deng
I would like to remind you that the VFC and APPC are provisionally accepted 
pending the architecture alignment.
The final acceptance should be discussed in the TSC.
This kind of answer will not resolve the problem of overlapping between the 2 
streams and if we maintain this position will be have a useless Rel-1 and I 
recommend you to give a augmented answers.
Regards
jamil



De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
De la part de denghui (L)
Envoyé : dimanche 23 juillet 2017 10:24
À : Pasi Vaananen; Alla Goldner; onap-discuss@lists.onap.org
Cc : onap-tsc
Objet : Re: [onap-tsc] [onap-discuss] Architecture Progress

Just clarify one important thing here, GNVFM is in the scope of ONAP, no on the 
side of VNF vendors.

Inline please == >

From: Pasi Vaananen [mailto:pvaan...@redhat.com]
Sent: Saturday, July 22, 2017 8:53 PM
To: denghui (L) mailto:denghu...@huawei.com>>; Alla 
Goldner mailto:alla.gold...@amdocs.com>>; 
onap-discuss@lists.onap.org
Cc: onap-tsc mailto:onap-...@lists.onap.org>>
Subject: Re: [onap-discuss] Architecture Progress


I respectfully disagree, at least based on what has been said / presented in 
the meetings and written down on the present documents:

"Interface between VNF and ONAP is quite simple :"

Given that this has been under discussion for multiple years now, I would not 
say there is anything simple about it.

Interface to VNFs is also not limited to templates only - it also includes all 
run-time APIs and other interfaces towards "G-VNFM" style functionality (i.e. 
in support of VNF and VNFCI LCM operations). Collectively, VNF package and 
*all* artifacts thereof, as well as all interfaces that are exercised by the 
VNF and its associated component instances towards ONAP form the "interface" 
between ONAP and VNF vendor. As the majority of functions related to these 
interfaces and descriptors is implemented in the APP-C or VF-C, if we have 
single set of these, then both need to do the same thing, or functionality 
would need to be somehow split between the two. Right now, as already 
documented in Chris's email, most of the VNF LCM operations between the APP-C 
and VF-C have full overlap.

== > as said in the beginning, GVNFM  is in the scope of ONAP, its south bound 
interface (interface with VNF) is not matter with architecture.

"Heat(ECOMP)"

Heat is primarily interface to specific VIM, i.e. OpenStack. It is true that 
current APP-C uses Heat Orchestration Templates. However, the discussion is not 
the past state but on the future direction of the system, including direction 
of descriptors and APIs, and their implementation or at this point 
implementations. The current approved APP-C project proposal 
here states:

  *   APPC model will be based on ONAP TOSCA and Yang containing a dependency 
model, LCM recipes, configuration templates, policies etc.
  *   APPC provides multi-protocol southbound plugins, including support for 
NETCONF, Chef via a Chef Server, and Ansible and ability to operate through 
vendor specific VNFM/EMS via adaptation through a plugin.

At least the "ONAP TOSCA" (VNFD), Yang, potentially policies, and "etc.", 
Chef/Ansible, and S-VNFM interfaces from the above list are "interfaces" or 
touch-points that VNF vendors would need to integrate with (in addition to DCAE 
metrics/events interfaces which indirectly ultimately are associated with 
policy / controller actions as well).
== > If you are strongly believing in one interface to VNF, then you could go 
to VNF requirement or VNFSDK project, and strongly suggest to remove Heat 
support over there.

As far as I can tell from the project description, there is currently no 
implementation of the "sideways" APIs of ETSI architecture reference model 
between the VNF/EM and the "G-VNFM" function equivalent of APP-C, beyond of the 
indirect actions that can be taken through events received through e.g. 
VES/DCAE. For example, there is no implementation of ETSI SOL style API for VNF 
to directly call to request  "scale some component group out to level 'x'". 
However, there is "NBI" APIs for these operations, but it is not clear (at 
least from description) whether those are allowed to be invoked by the VNFs 
themselves (and if so, how) or ONAP internal subsystems only (if it is set of 
REST APIs, those could be exposed to VNFs as well, but whether that is not very 
clear from the current APP-C context diagram).

"TOSCA(OPEN-O)"

Obviously, the Open-O implementation came with their definition of TOSCA 
artifacts, in this context for VNFDs, and I am aware that those have been 
brought as input to ONAP along with the seed code to support implementation. 
However, from the approved VF-C project proposal 
here  VF-C does for 
the VNFM LCM functions:

  *   support VNF lifecycle management based on the ONAP 

[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&pageId=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

[onap-discuss] [sdnc] maven archetype for developing SDNC plugin/adaptor

[Jing Wang]

I wonder if we already have the maven archetype for developing SDNC plugin or 
adaptor. Checked wiki and maven repo, can't find any.

Thanks!

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

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

[Kanagaraj Manickam]

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] [SDC] Volte csar packages //Re: CSAR from SDC

[Kapeluto, Zahi]

We’re looking at the issues and we’ll return with an answer once we have it.

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

From: "zhao.huab...@zte.com.cn" 
Date: Monday, 24 July 2017 at 7:47
To: ZAHI KAPELUTO , "Rozin, Eden" , 
"Lando,Michael" 
Cc: "onap-discuss@lists.onap.org" , 
"yuan@zte.com.cn" 
Subject: [SDC] Volte csar packages //Re: [onap-discuss] CSAR from SDC


Hi ,



I created a jira issue to track the substitution issue.



Besides, attached are the VoLTE csar packages which have been used for OPEN-O 
Mercury Release.

Please review it, if there are anything SDC can't support now, we may need to 
add jira issues to track them.



Huabing








Original Mail
Sender: zhaohuabing10201488
To:  ;
CC:  ;YuanHu10090474; ;
Date: 2017/07/21 12:32
Subject: Re: [onap-discuss] CSAR from SDC



Hi Zahi,



I understand what's substitution mapping for, if you take a loot at the TOSCA 
spec, it says:

substitution_mappings


no


N/A


An optional declaration that exports the topology template as an implementation 
of a Node type.



This also includes the mappings between the external Node Types named 
capabilities and requirements to existing implementations of those capabilities 
and requirements on Node templates declared within the topology template.


I don't see the red part " the mappings between the external Node Types named 
capabilities and requirements to existing implementations of those capabilities 
and requirements on Node templates declared within the topology template" in 
the SDC service template. That's where my question comes from.



I took the example from official TOSCA spec here:  
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/csprd02/TOSCA-Simple-Profile-YAML-v1.1-csprd02.html#_Toc474149740

2.11.3Defining the details of a subsystem

Example 19 - Implementation of a TransactionSubsytem node type using 
substitution mappings



BR,

Huabing










Sender:  ;
To: zhaohuabing10201488;
CC:  ; ;YuanHu10090474; 
;
Date: 2017/07/20 21:51
Subject: Re: [onap-discuss] CSAR from SDC


Hi Zhao,

Substitution Mapping is used for embedding a complete Topology Template into 
another, higher-level, Topology Template as a Node Template as seen in the 
image below:

[cid:image001.png@01D30178.669A2E00]

Your sample TOSCA below seems wrong, where did you take it from?
Here is an example of substitution mapping:

topology_template:
  node_templates:
ExtVL 0:
  type: org.openecomp.resource.vl.extVL
  metadata:
invariantUUID: df44a9d0-024a-48fc-bd0a-12aaf69dd89e
UUID: 6bacc8ad-f5ca-4774-b5f6-bab441b3eba8
customizationUUID: cdc9e73c-245c-4569-ae34-2156acefdc2c
version: '5.0'
name: ExtVL
description: ECOMP generic virtual link (network) base type for all 
other service-level and global networks
type: VL
category: Generic
subcategory: Network Elements
resourceVendor: ATT (Tosca)
resourceVendorRelease: 1.0.0.wd03
resourceVendorModelNumber: ''
  properties:
network_assignments:
  is_external_network: false
  ecomp_generated_network_assignment: false
exVL_naming:
  ecomp_generated_naming: true
network_flows:
  is_network_policy: false
  is_bound_to_vpn: false
network_homing:
  ecomp_selected_instance_node_target: false
  substitution_mappings:
node_type: org.openecomp.service.ServicePort
capabilities:
  extvl0.virtual_linkable:
  - ExtVL 0
  - virtual_linkable
  extvl0.feature:
  - ExtVL 0
  - feature
requirements:
  extvl0.dependency:
  - ExtVL 0
  - dependency


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

From: "zhao.huab...@zte.com.cn" 
Date: Wednesday, 19 July 2017 at 10:08
To: ZAHI KAPELUTO 
Cc: "SACKS, ZOHAR" , "onap-discuss@lists.onap.org" 
, "yuan@zte.com.cn" , 
"Rozin, Eden" 
Subject: Re: [onap-discuss] CSAR from SDC


Hi Zahi,

Thanks for your answer.



1.  Can't find the corresponding node template for the defined capabilities and 
requirements in the substitution_mappings
The substation mapping in the below example contains capabilities/requirements. 
Thos

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 mailto:dr6...@att.com>>; OBRIEN, FRANK 
MICHAEL mailto:frank.obr...@amdocs.com>>; Josef 
Reisinger mailto:josef.reisin...@de.ibm.com>>; 
PLATANIA, MARCO mailto:plata...@research.att.com>>
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&T ***
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

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)
mailto:yang@huawei.com> > 写道：

 

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&AI/ESR. Can SDC pull the information from A&AI/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&T ***
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 mailto:dr6...@att.com>>; Josef Reisinger 
mailto:josef.reisin...@de.ibm.com>>
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 vFW or vLB up.

https://jira.onap.org/browse/UCA-17

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
原始邮件
发件人： mailto:zk0...@intl.att.com>>;
收件人：张茂鹏10030173;
抄送人： mailto:seshu.kuma...@huawei.com>>; 
mailto:onap-discuss@lists.onap.org>>; 
mailto:zohar.sa...@amdocs.com>>;
日 期 ：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&T Network Applications Development · SD&E
Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
·
Mobile: +972 (54) 6636831
Office: +972 (3) 9280064

From: "zhang.maope...@zte.com.cn" 
mailto:zhang.maope...@zte.com.cn>>
Date: Thursday, 20 July 2017 at 4:54
To: ZAHI KAPELUTO mailto:zk0...@intl.att.com>>
Cc: "seshu.kuma...@huawei.com" 
mailto:seshu.kuma...@huawei.com>>, 
"onap-discuss@lists.onap.org" 
mailto:onap-discuss@lists.onap.org>>, "SACKS, 
ZOHAR" mailto:zohar.sa...@amdocs.com>>
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
原始邮件
发件人： mailto:zk0...@intl.att.com>>;
收件人：张茂鹏10030173; mailto:seshu.kuma...@huawei.com>>; 
mailto:onap-discuss@lists.onap.org>>;
抄送人： mailto:zohar.sa...@amdocs.com>>;
日 期 ：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&T Network Applications Development · SD&E
Tel Aviv | Tampa | Atlanta | New Jersey | Chicago
·
Mobile: +972 (54) 6636831
Office: +972 (3) 9280064

From: 
mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of "zhang.maope...@zte.com.cn" 
mailto:zhang.maope...@zte.com.cn>>
Date: Wednesday, 19 July 2017 at 12:46
To: "seshu.kuma...@huawei.com" 
mailto:seshu.kuma...@huawei.com>>, 
"onap-discuss@lists.onap.org" 
mailto: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 https://www.amdocs.com/about/email-disclaimer 

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