[onap-tsc] 转发: 答复: Re: 答复: Service Orchestrator project proposal

[Jinxin (Saw)]

Hi Dewayne ,Maopeng

If both options could be pursued in parallel，I think we should change the 
proposal like following:

It is envisioned that initial Releases of this project would demonstrate both 
alternative approaches.
For Alternative 1 approach:
• Demonstrate SO BPMN workflows interacting with an off-the-shelf TOSCA 
Orchestrator to collectively drive orchestration behavior for at least an 
instantiation use case
• Demonstrate rainy day handling
• Accomplish the above in a way that is demonstrably extensible to 
support lifecycle operations such as Scale-In and Scale-Out.
For Alternative 2 approach:
• Demonstrate SO BPMN workflows to drive TOSCA-aware orchestration 
behavior for VoLTE use case, dependency to VF-C.
• Support lifecycle operations such as Scale-In and Scale-Out.

What’s your opinion.


Best wishes
Jinxin

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

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


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of 
zhang.maope...@zte.com.cn
Sent: 2017年5月17日 9:11
To: dewa...@gigaspaces.com
Cc: onap-tsc@lists.onap.org
Subject: [onap-tsc] 答复: Re: 答复: Service Orchestrator project proposal


Hi DeWayne,



   Do you mean that this project proposal should support option 1 and option 2( 
integrated with VF-C)?

   If it is ture, the project proposal should be changed.



Best Regards

Maopeng
原始邮件
发件人： ＜dewa...@gigaspaces.com＞;
收件人：张茂鹏10030173;
抄送人： ＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月16日 23:11
主 题 ：Re: 答复: [onap-tsc] Service Orchestrator project proposal


Maopeng,
 The rationale behind option 1 vs option 2 was based on participant input at 
the time.  As far as I know, the time has passed for new project proposals.  I 
suppose it is conceivable with enough committers that both options could be 
pursued in parallel.  The proposal is submitted however.  Perhaps the TSC can 
chime in.

DeWayne

On Mon, May 15, 2017 at 1:02 AM,  
＜zhang.maope...@zte.com.cn＞ wrote:

Hi DeWayne,



I am interested in and already committed to contributing to this project.

I am afraid that I am confused since there are two alternatives on the proposal 
page, but it said in release 1 the project will only demonstrate option 1( Only 
depend on App-C project)

Since we are interested in contributing option 2, I doubt it is still open for 
discussion? Or shall we document it in a separate project proposal instead?



Best Regards

Maopeng
原始邮件
发件人： ＜dewa...@gigaspaces.com＞;
收件人： ＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月15日 01:32
主 题 ：[onap-tsc] Service Orchestrator project proposal



ONAP TSC,  We would like to formally propose the SO (Service Orchestrator) 
project for ONAP.. The proposal wiki page, which includes details of the 
project description, project scopes, and proposed repo names, can be found at:  
https://wiki.onap.org/display/DW/Service+Orchestrator.   The SO team consists 
of representatives from Cloudify, AT, Huawei, China Mobile, Ericsson, Orange, 
Amdocs, Nokia, and ZTE.

Thanks,

DeWayne Filppi
Director Solution Architecture
Gigaspaces/Cloudify
dewa...@gigaspaces.com
714.512.1706









--
DeWayne Filppi, Director, Solutions Architect

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-27020792c3e94269b883d9a828be029f56c08986b2ab208a46143b169592c35a.png]



M: +17145121706

http://cloudify.co

@dfilppi

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/2fb5e7413e7dbeee3e88676333b65c05237ec13d3512e4a63ebc1b5f85bfb917.png]
  
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/16b91ab7a91bb3a298f2a322640bebb3754357f93e9f20ff50d2c94bb82b1814.png]
 

Re: [onap-tsc] 答复: Re: 答复: Service Orchestrator project proposal

[Jinxin (Saw)]

Hi Dewayne ,Maopeng

If both options could be pursued in parallel，I think we should change the 
proposal like following:

It is envisioned that initial Releases of this project would demonstrate both 
alternative approaches.
For Alternative 1 approach:
· Demonstrate SO BPMN workflows interacting with an off-the-shelf TOSCA 
Orchestrator to collectively drive orchestration behavior for at least an 
instantiation use case
· Demonstrate rainy day handling
· Accomplish the above in a way that is demonstrably extensible to 
support lifecycle operations such as Scale-In and Scale-Out.
For Alternative 2 approach:
· Demonstrate SO BPMN workflows to drive TOSCA-aware orchestration 
behavior for VoLTE use case, dependency to VF-C.
· Support lifecycle operations such as Scale-In and Scale-Out.

What’s your opinion.


Best wishes
Jinxin

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

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


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of zhang.maope...@zte.com.cn
Sent: 2017年5月17日 9:11
To: dewa...@gigaspaces.com
Cc: onap-tsc@lists.onap.org
Subject: [onap-tsc] 答复: Re: 答复: Service Orchestrator project proposal


Hi DeWayne,



   Do you mean that this project proposal should support option 1 and option 2( 
integrated with VF-C)?

   If it is ture, the project proposal should be changed.



Best Regards

Maopeng
原始邮件
发件人： ＜dewa...@gigaspaces.com＞;
收件人：张茂鹏10030173;
抄送人： ＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月16日 23:11
主 题 ：Re: 答复: [onap-tsc] Service Orchestrator project proposal


Maopeng,
 The rationale behind option 1 vs option 2 was based on participant input at 
the time.  As far as I know, the time has passed for new project proposals.  I 
suppose it is conceivable with enough committers that both options could be 
pursued in parallel.  The proposal is submitted however.  Perhaps the TSC can 
chime in.

DeWayne

On Mon, May 15, 2017 at 1:02 AM,  
＜zhang.maope...@zte.com.cn＞ wrote:

Hi DeWayne,



I am interested in and already committed to contributing to this project.

I am afraid that I am confused since there are two alternatives on the proposal 
page, but it said in release 1 the project will only demonstrate option 1( Only 
depend on App-C project)

Since we are interested in contributing option 2, I doubt it is still open for 
discussion? Or shall we document it in a separate project proposal instead?



Best Regards

Maopeng
原始邮件
发件人： ＜dewa...@gigaspaces.com＞;
收件人： ＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月15日 01:32
主 题 ：[onap-tsc] Service Orchestrator project proposal



ONAP TSC,  We would like to formally propose the SO (Service Orchestrator) 
project for ONAP.. The proposal wiki page, which includes details of the 
project description, project scopes, and proposed repo names, can be found at:  
https://wiki.onap.org/display/DW/Service+Orchestrator.   The SO team consists 
of representatives from Cloudify, AT, Huawei, China Mobile, Ericsson, Orange, 
Amdocs, Nokia, and ZTE.

Thanks,

DeWayne Filppi
Director Solution Architecture
Gigaspaces/Cloudify
dewa...@gigaspaces.com
714.512.1706









--
DeWayne Filppi, Director, Solutions Architect

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-27020792c3e94269b883d9a828be029f56c08986b2ab208a46143b169592c35a.png]



M: +17145121706

http://cloudify.co

@dfilppi

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/2fb5e7413e7dbeee3e88676333b65c05237ec13d3512e4a63ebc1b5f85bfb917.png]
  
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/16b91ab7a91bb3a298f2a322640bebb3754357f93e9f20ff50d2c94bb82b1814.png]
    

Re: [onap-tsc] 答复: Release Naming

[Alexis de Talhouët]

> On May 17, 2017, at 9:21 AM, Arul Nambi  wrote:
> 
> Can non TSC members vote on these kind of decisions?
> 

I believe only TSC members can vote, but that doesn’t mean ONAP contributors 
can’t share their thoughts.

Thanks,
Alexis___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] 答复: Release Naming

[Arul Nambi]

Hi All,
Can non TSC members vote on these kind of decisions?
If so I vote on city names, as it is more common knowledge when compared to 
names of Orchestrators.
It will be great if we setup an online voting mechanism and see what others 
think as this is not more of a technical issue but rather a look and feel.
Regards
Arul
Arul Nambi MASc
Software Developer

Amdocs Technology
[cid:image010.png@01D2C9B5.447E30F0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Anil Vishnoi
Sent: Tuesday, May 16, 2017 10:16 PM
To: zhang.maope...@zte.com.cn
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] 答复: Release Naming

Hi All,

I am not a TSC member, but just want to share a thought. I think you should 
modify first option "famous cities belonging to platinum members" to "famous 
cities around the world", because platinum members are not permanent and can 
change in future.

Thanks
Anil

On Tue, May 16, 2017 at 6:37 PM, 
> wrote:

hi MAZINE,



  I’m not a TSC member but I prefer Option 1

  Chengdu is one of the major ZTE RD locations,  which is also a beautiful 
travel city and can be recommanded as the location.



Best Regards

Maopeng
原始邮件
发件人： ＜ma...@research.att.com＞;
收件人： ＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月17日 01:24
主 题 ：[onap-tsc] Release Naming


Team,
I have two  proposals for release naming. One from Rueben Klein and the other
from Gildas Lanilis.

The first is famous cities belonging to platinum members, and the other is 
famous conductors in
the domain of orchestrating:-) Both follow the alphabet style.
Please review and share comments before our TSC meeting on Thursday.

Thanks
Mazin


Option 1
Platinum Member

Country

Major Locations

IBM

US

Armonk

China Mobile/Telecom

China

Beijing

Amdocs

US

Chesterfield

AT

US

Dallas

Nokia

Finland

Espoo

VMWare

US (IL)

Herzliya

Intel

US

Irvine

Ericsson

Sweden

Kista

Tech Mahindra

India

Mumbai

Gigaspaces

US

New York

Bell Canada

Canada

Ottawa

Orange

France

Paris

Cisco

US

San Jose

Huawei

China

Shenzhen

ZTE

China

Tianjin



Option 2

Famous Conductors:
As ONAP plays in the domain of orchestrating, we could use the name of famous 
conductors.
Continuous Naming: Amadeus, Beethoven, Chopin, Debussy, Enescu, Foote, 
Gershwin, Handel, Ilyich, Johannes
Non-Continuous naming: Amadeus, Beethoven, Chopin, Debussy, Gershwin, Liszt, 
Puccini, Ravel, Schubert, Tchaikovsky,  Vivaldi, Wagner





___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc



--

Re: [onap-tsc] Thoughts on next steps.

[SPATSCHECK, OLIVER (OLIVER)]

Yuan,

let me separate things a bit.

The way I look at it is that there is a set of use cases which gate the success 
of the release. Those use cases have a set of VNFs.  

I completely agree with you that ONAP should support many commercial VNFs. In 
fact I would like all commercial VNFs to be supported by ONAP that’s the 
ultimate goal of AT, however, that does not mean that all of them have to be 
part of the set of VNFs used for the use case which gates the release. 

Now let’s focus on the VNFs which gate the release as the others can be worked 
using proprietary or bilateral agreements.  As stated below I don’t know how to 
do that efficiently. That doesn’t mean there isn’t a solution. So if you can 
outline one that would be great. I see three main challenges:

1. Developer access to VNFs. From experience you can speed up development 
substantially if you give developers access to an integration environment. It’s 
nice to develop against specs but I have never seen a complex project  (inside 
or outside of AT) which just worked based on developers working against 
specs. That’s where the whole agile idea comes from. Integration testing 
becomes an integral part of your development. So one way of fixing this is to 
give access to an IST level environment to the developers. That’s the approach 
we took with open sourcing ECOMP. Without that our demo use case would probably 
still not be working. So now if we use a commercial VNF how do we get 
developers these environments? E.g. AT has multiple development teams and we 
dynamically provided them what they needed on Rackspace to open source ECOMP. 
There are two solutions to this in my mind:

a.) We have a shared lab where all developers perform all the IST testing. If 
we want to follow this approach we have to answer the following questions:

Considering the substantially larger scale then Open-O do we have  a lab that 
can support ALL developers by 6/29? Who would provide that?  Does the shared 
lab really have enough instances to not slow development down?
Does that lab have a license which would allow them to give first hand access 
to e.g. an Ericsson (sorry just picked somebody randomly for illustrative 
purposes) developer to a Huawei or ZTE VNF?
Would e.g. Ericsson allow there developers to access that VNF or would they be 
afraid of IP entanglement if they did?
Do we have to worry about any international export control or anti trust laws 
doing this?

Again all those questions need to be answered by 6/29 to make this work for the 
first release and I have seen little discussion on this so far. 

b.) Each organization developing provides it’s own integrated testing 
environment to it’s developers. That would mean e.g. AT needs to run all 
those VNFs in it’s own internal lab. Of course AT wouldn’t pay for that after 
all we are providing free code to the community so we wouldn’t pay license fees 
to a vendor to do so.

In this case are the VNF vendors willing to license there VNFs to ALL ONAP 
contributors for free in support of ONAP development? 
Are those license agreements reasonable enough (e.g. limited indemnification if 
software gets stolen) for the ONAP development teams to actually sign?
Can all of this be completed by 6/29?

2. Another problem is around final acceptance testing of the release. I am a 
strong believer that if others can’t repeat something it doesn’t really exists. 
E.g. in physics a phenomena is only true if more then one DIVERSE team was able 
to observe it. I strongly believe software testing needs to follow the same 
objective.  So how would we set up repeatable testing of commercial VNFs which 
can be performed by more then one diverse team? The possible approaches are 
similar then the once outlined above. 

3. The last one is around demos. E.g. one things which I think has been fairly 
well received (based on the feedback I got) is the fact that you can try the 
ECOMP part of ONAP on Rackspace EASILY. I know we are still working on the 
generic open stack setup but the fact that so many people are asking for it is 
an indication that people want to “kick the tiers” of ONAP in there own 
environment. Again how would we address this need with proprietary VNFs?  
Without delivering VNFs with the use case ONAP is just a huge amount of code 
doing nothing …. . Or to put it differently. A wise man told me once: “ People 
don’t want platforms they want solutions!” if we can’t demo a solution as part 
of the release openly people will be very disappointed.

Again I don’t see a practical way of addressing this in the time given (e.g. I 
know for example that even a free license agreement with AT generally 
requires negotiations in the risk and IP area). If you know one could you 
please outline it so the community can understand what the plan is in detail?

Thx

Oliver



> On May 17, 2017, at 3:27 AM  EDT, yuan@zte.com.cn wrote:
> 
> Hi Oliver and all,
> 
> 
> 
> My answer to " I wouldn’t even know how that worked 

Re: [onap-tsc] Thoughts on next steps.

[RATH, CHRISTOPHER A (CHRISTOPHER A)]

While it is true that part of the idea behind CCF is the creation of a software 
framework, part of that framework includes whole components that provide the 
functionality you mentioned for MSB.  We have integrated Consul to handle 
service registration/discovery, service health monitoring, and service 
configuration storage.

It should be noted that CCF doesn’t provide code for micro-service developers.  
It is intended for controller developers.  It is also not limited to 
micro-service management; micro-services would be a subset of the features 
provided in CCF.

We don’t currently have a common load balancer or service gateway, so I would 
be very interested in seeing how MSB handles this.

In listing DCAE and OOM as candidates for using CCF, I was not intending to be 
exclusive.  There are a number of other “controller” components that can be 
built on top of CCF; they just aren’t done that way today.

--
Christopher A. Rath
Director Inventive Science – Intelligent Systems Research Department
Advanced Technologies & Platforms
D2 Architecture & Design
AT Services, Inc.

From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: Tuesday, May 16, 2017 11:31 PM
To: RATH, CHRISTOPHER A (CHRISTOPHER A) 
Cc: SPATSCHECK, OLIVER (OLIVER) ; 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Thoughts on next steps.


"For MSB: I agree this should be part of CCF.  It could be used by DCAE and 
OOM."



Huabing：

MSB and CCF are different and their scope are not overlapping.



From the project description of CCF, it will provide "a common set of reusable 
code that can be used across multiple controllers", it seems like some kind of 
"Framework" codes refers to a collection of libraries/classes with the common 
goal of providing a scaffold on which to build controller.



Microservices Bus are from OPEN-O code base which provides key infrastructure 
functionalities to support Microservice Architecture including service 
registration/discovery, service gateway, service load balancer. It's a 
pluggable architecture so it can plugin service provider options like AAF to 
provide Authentication & Authorization for APIs. Microservices Platform also 
provides a service portal and service requests logging, tracing and monitoring 
mechanism, etc. MSB doesn't not provide "Framework" codes for building a 
Microservice.



Besides, If we prefer to provide a common "framework"  across ONAP projects to 
build a Microservice, we could consider some open source Microservice 
frameworks on the table, which provides underlying libraries to support quickly 
Microservice development and included the mechanisms to handle cross-cutting 
concerns such as External Configuration, Logging, Health checks, Metrics etc.

Here are some candidates:

· Java

§  Spring Boot

§  Dropwizard

· Python

§  Nameko

§  Flask

· Go

§  Gizmo

§  Micro

§  Go kit



And one more thing, As the Microservice Infrastructure, MSB could be used 
nearly all the ONAP components(Microservices), not only DCAE and OOM.



Thanks and Regards,

Huabing
Original Mail
Sender:  ＜c...@research.att.com＞;
To:  ＜spat...@research.att.com＞; ＜onap-tsc@lists.onap.org＞;
Date: 2017/05/17 04:05
Subject: Re: [onap-tsc] Thoughts on next steps.


For the areas in which I have contributions to consider, here are some 
clarifications.

First, the Common Controller Framework should have overlap as far as scope with 
a lot of projects.  That is the point of that project, to find overlapping 
functionality, develop it in a single project, and reuse it among the other 
components.  So I would  not be concerned with any overlap between CCF and the 
other projects dealing with deployment, management, orchestration, etc.  That 
is by design..

For DCAE: we have recognized an overlap with Holmes, which in my view should be 
a sub-project of DCAE, but it does not appear that sub-projects were proposed 
this way.  DMaaP does not have an overlap with DCAE.  DCAE uses DMaaP, as do 
many other components,  but the scopes are completely different.  I believe the 
functionality in DMaaP for data processing does not exist today and it is not 
clear that it would be part of an open-source release of DMaaP or not anyway.

For DMaaP: The CCF overlap is by design.  It is our intention to provide a 
“Data Bus Controller” with responsibility for deploying and managing DMaaP data 
delivery components where they are needed and when they are needed.  That 
functionality exists in  DCAE today, but needs to be pulled out to be generally 
available across ONAP components.

For MSB: I agree this should be part of CCF.  It could be used by DCAE and OOM.

—
Christopher A. Rath
Director Inventive Science – Intelligent Services and Platforms Research


From: ＜onap-tsc-boun...@lists.onap.org＞ 
on behalf of "SPATSCHECK, OLIVER (OLIVER)" 
＜spat...@research.att.com＞

Re: [onap-tsc] Service Orchestrator project proposal

[GILBERT, MAZIN E (MAZIN E)]

The TSC committee and community will continue to provide project feedback over 
the next 2 weeks.
So nothing is written in stone.

The China meeting in early June will be the first opportunity where projects 
that are ready-to-go will be reviewed for
approvals on a first come basis and based on the critical needs defined by the 
use cases.

Mazin



On May 16, 2017, at 8:59 PM, Lingli Deng 
> wrote:

Hi guys,

Please correct me if I am wrong.
But I do not think we have a hard deadline for amendments to project proposal, 
until it is formal approval.

Lingli


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of DeWayne Filppi
Sent: 2017年5月16日 23:10
To: zhang.maope...@zte.com.cn
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] 答复: Service Orchestrator project proposal

Maopeng,

 The rationale behind option 1 vs option 2 was based on participant input at 
the time.  As far as I know, the time has passed for new project proposals.  I 
suppose it is conceivable with enough committers that both options could be 
pursued in parallel.  The proposal is submitted however.  Perhaps the TSC can 
chime in.

DeWayne

On Mon, May 15, 2017 at 1:02 AM, 
> wrote:
Hi DeWayne,

I am interested in and already committed to contributing to this project.
I am afraid that I am confused since there are two alternatives on the proposal 
page, but it said in release 1 the project will only demonstrate option 1( Only 
depend on App-C project)
Since we are interested in contributing option 2, I doubt it is still open for 
discussion? Or shall we document it in a separate project proposal instead?

Best Regards
Maopeng
原始邮件
发件人： ＜dewa...@gigaspaces.com＞;
收件人： ＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月15日 01:32
主 题 ：[onap-tsc] Service Orchestrator project proposal



ONAP TSC,  We would like to formally propose the SO (Service Orchestrator) 
project for ONAP. The proposal wiki page, which includes details of the project 
description, project scopes, and proposed repo names, can be found at:  
https://wiki.onap.org/display/DW/Service+Orchestrator.
   The SO team consists of representatives from Cloudify, AT, Huawei, China 
Mobile, Ericsson, Orange, Amdocs, Nokia, and ZTE.


Thanks,

DeWayne Filppi
Director Solution Architecture
Gigaspaces/Cloudify
dewa...@gigaspaces.com
714.512.1706







--
DeWayne Filppi, Director, Solutions Architect

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-27020792c3e94269b883d9a828be029f56c08986b2ab208a46143b169592c35a.png]



M: +17145121706

http://cloudify.co

@dfilppi

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/2fb5e7413e7dbeee3e88676333b65c05237ec13d3512e4a63ebc1b5f85bfb917.png]
  
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/16b91ab7a91bb3a298f2a322640bebb3754357f93e9f20ff50d2c94bb82b1814.png]
 

   
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/6f7421bc5b9a93a0649735bbc8589b200c678bf08af9d7e0cebf1b3cffcdac94.png]
 

   
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/4be4d1377f4c1afe70a25e78926b6aad4e0a4fb1d45a7727e31d5a807eb3aae7.png]
 

Re: [onap-tsc] [onap-discuss] Project Proposal: External SystemRegister

[GILBERT, MAZIN E (MAZIN E)]

LiZi,

Thanks for putting the proposal together. The TSC will be continuing a review 
cycle over the next 2 weeks.
I realize the difference and the need of having a system register for external 
communications,
but the question is whether this should be a separate project that may cause 
further dilution.
If the technology and the algorithms used for supporting ESR are similar to 
others like those
used in A, but the type of data is different then I don’t see the need for 
separate systems.

I can see many situations like life cycle management of VNFs using closed loop 
automation where
doing post health checks are critical after repairing a failure. So having both 
platform and external system
data available in one place are key.

In general, the TSC will look very closely on projects that need merger to help 
unify the community
and strengthen the developer ecosystem. You are getting good feedback from the 
community and
I suggest you look closer.

Regards,
Mazin




On May 17, 2017, at 5:31 AM, li.z...@zte.com.cn 
wrote:

Hi Avi,

ESR will not only store and manage configuration of VIM, but also the 
configuration of VNFM/SDNC/EMS. It provides a service to centralized management 
of the information of different kinds of external systems. And it will be used 
by SO/SDC/VF-C etc.
When comes to multi-vim, we suggest that multi-vim using ESR as a dependency 
component, obtaining the connect information and status of VIM from ESR. For 
this point, we can have a further discussion.


Best regards,

LiZi




原始邮件
发件人： ＜avi.chap...@amdocs.com＞;
收件人： ＜dr6...@att.com＞;李滋00164331; 
＜jpianigi...@juniper.net＞;
抄送人： ＜onap-disc...@lists.onap.org＞; 
＜onap-tsc@lists.onap.org＞;
日 期 ：2017年05月17日 00:31
主 题 ：RE: [onap-tsc] [onap-discuss] Project Proposal: External SystemRegister

Hi,

Reading the project scope it seems to me a real time configuration repository 
for external system location and credential specifically for VIM.
Probably this should be part of the multi-vim project which should own and 
manage this configuration.

I assume that  the component which is used for  storing/managing this 
configuration can be shared across different projects and/or might offered to  
be a service  which any component can use.

Avi,


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of ROSE, DANIEL V
Sent: Tuesday, May 16, 2017 6:51 PM
To: li.z...@zte.com.cn; 
jpianigi...@juniper.net
Cc: onap-disc...@lists.onap.org; 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [onap-discuss] Project Proposal: External System 
Register

I have to agree with Jacopo and Steve, that’s not business logic that’s basic 
endpoint health checking.

So to clarify on my and their inputs, it still seems like to me that the entire 
scope of this project is covered by some combination of A, ONAP OM or MSB 
depending  on who you ask / how you look at it.

ONAP Operations manager in particular mentions (Which seems to cover most of 
your stuff.)

•  Platform Monitoring & healing: Monitor platform state, Platform health 
checks, fault tolerance and self-healing

Can you please work with someone like David Sauvageau on that project to be 
sure you have no overlap?

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

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of 
li.z...@zte.com.cn
Sent: Tuesday, May 16, 2017 12:49 AM
To: jpianigi...@juniper.net
Cc: onap-disc...@lists.onap.org; 
onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] Project Proposal: External System 
Register


Hi Jacopo,



Thanks for your quick response. The business logic can be information 
verification before store the data to A, and heartbeat detection of the 
system state.

For example, a user sent the authentic url, tenant, username and password of 
VIM to ESR. ESR try to connect the VIM with these information. After authentic 
succeed, ESR store these VIM information to A, do heartbeat detection for 
VIM status and present  the system status to user.



Best regards,

LiZi






原始邮件
发件人： ＜jpianigi...@juniper.net＞;
收件人：李滋00164331;
抄送人： ＜stephen.terr...@ericsson.com＞; 
＜onap-tsc@lists.onap.org＞; 
＜onap-disc...@lists.onap.org＞;
日 期 ：2017年05月16日 11:32
主 题 ：Re: [onap-tsc] Project Proposal: External System Register


Not clear what the 

[onap-tsc] Coordinators

[GILBERT, MAZIN E (MAZIN E)]

Team ONAP,

This is a reminder that the deadline for self nominations for the
open source coordinator and SDO coordinator is today at 9pm PST

thanks
mazin



___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Release Naming

[Stephen Terrill]

Hi,

If you want an emphasis on conductors more than composers, here is some 
inspiration 
https://www.gramophone.co.uk/feature/the-50-greatest-conductors-of-all-time

BR,

Steve

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: 16 May 2017 19:23
To: onap-tsc 
Subject: [onap-tsc] Release Naming

Team,

I have two  proposals for release naming. One from Rueben Klein and the other
from Gildas Lanilis.

The first is famous cities belonging to platinum members, and the other is 
famous conductors in
the domain of orchestrating:-) Both follow the alphabet style.
Please review and share comments before our TSC meeting on Thursday.

Thanks
Mazin


Option 1
Platinum Member

Country

Major Locations

IBM

US

Armonk

China Mobile/Telecom

China

Beijing

Amdocs

US

Chesterfield

AT

US

Dallas

Nokia

Finland

Espoo

VMWare

US (IL)

Herzliya

Intel

US

Irvine

Ericsson

Sweden

Kista

Tech Mahindra

India

Mumbai

Gigaspaces

US

New York

Bell Canada

Canada

Ottawa

Orange

France

Paris

Cisco

US

San Jose

Huawei

China

Shenzhen

ZTE

China

Tianjin



Option 2

Famous Conductors:
As ONAP plays in the domain of orchestrating, we could use the name of famous 
conductors.
Continuous Naming: Amadeus, Beethoven, Chopin, Debussy, Enescu, Foote, 
Gershwin, Handel, Ilyich, Johannes
Non-Continuous naming: Amadeus, Beethoven, Chopin, Debussy, Gershwin, Liszt, 
Puccini, Ravel, Schubert, Tchaikovsky, Vivaldi, Wagner
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Thoughts on next steps.

[yuan.yue]

Hi Oliver and all,




My answer to " I wouldn’t even know how that worked in practice. E.g. will 
those VNFs be available to competing vendors so they can test/develop ONAP 
code?"




We have already finished VoLTE testing in Open-O project with vIMS and vEPC 
comes from Huawei, ZTE and Ericsson. There was no problem using this 
proprietary vNFs for testing in Open-O. We also commit in ONAP community ZTE 
will provide our vNF packages with limited license for testing purpose.   

Deploying and managing vendor vNFs brings practical value to ONAP community. 
Anyway, target of ONAP project should be deploying and managing more commercial 
vNFs. I believe vNFs from  companies  other than ZTE and Huawei are also 
welcome for the VoLTE usecase.  




Best Regards,

Yuan Yue






袁越 yuanyue


资深战略规划师   Senior Strategy Planner



技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System 
Product









南京市雨花区软件大道50号中兴通讯3号楼1/F,Building 3, ZTE Nanjing R Center II, No.50, Software 
Avenue,YuHua District,Nanjing,P.R.China 210012
T: +025 88013478 

M: +86 13851446442 
E: yuan@zte.com.cn 
www.zte.com.cn














原始邮件



发件人： ＜spat...@research.att.com＞
收件人： ＜onap-tsc@lists.onap.org＞
日 期 ：2017年05月17日 03:47
主 题 ：[onap-tsc] Thoughts on next steps.





 
I just went through the proposals and noticed that quite a few of them have not 
clearly defined boundaries between them which makes me wonder if they overlap 
(see table below). From experience overlapping project definitions rarely lead 
to good  outcomes (duplicate work gets done and people are very upset at the 
end…) so I think we should resolve this before approving the projects.
 
When I built this table I focused on what’s written in the proposals. Now from 
discussions I think some of the perceived overlaps might just be a matter of 
cleaning up the writing. Others might actually be real. In either case I think 
we need  to be clear and precise in the project description and can’t rely on 
various email exchanges for this.  I also don’t claim that my table is 
complete. If you want I can put the table on the Wiki so people can add there 
perceived or real overlaps.
 
I don’t know how you usually resolve those issues but I would think that the 
project leads for all projects which might have an overlap define a common 
statement which defines there relationship with each other in some level of 
detail. Thoughts?
 
I also looked at the use cases. Lingli and her team did a great job cleaning up 
the VoLTE use case:
 
https://wiki.onap.org/pages/viewpage.action?pageId=3246140
 
The flow charts are a great start but we do need to get into more details and 
actually show the real API calls as well. I am also not sure I understand how 
exactly the legacy Open-O and legacy ECOMP components integrate. I think the 
next step  here is to walk through this in detail. I don’t think that’s 
something that can be done efficiently via email. I would suggest a call on the 
topic. That might actually be better then a F2F in June as it allows more 
developers to dial in.
 
One concern on this particular  use case is that only Huawei and ZTE have any 
VNFs in it. Personally I don’t think it’s a good start for an open project to 
start with proprietary VNFs from mainly one manufacturer with some contribution 
from a  second. I wouldn’t even know how that worked in practice. E.g. will 
those VNFs be available to competing vendors so they can test/develop ONAP code?
 
This brings me to overall use case scope and reality.
 
Using Gilda’s release plan (all his fault after all :)) we have to work all of 
this out by 6/29 (sounds a lot of time but really isn’t). Development is only 3 
months till RC0. We have 32 projects. That’s 21 projects more then the seed 
code of  8+3. If I ignore the toy use case we have two use cases proposed with 
the VoLTE one having more details then the other.  Coordinating interfaces one 
on one for the 32 projects requires 512 meetings. ….  I think if we are trying 
to achieve all of this in release  1 we are setting ourselves up for failure.
 
If it was up to me I would probably just focus the use cases on instantiation 
and one simple control loop. This might seem like very little but considering 
the work we need to start the projects, set up the labs, get developers 
familiar with the environment, get them lab access  etc… which all takes time.  
I think that would  be realistic for a first release and then we can adjust the 
second release accordingly.
 
 In terms of projects I would be very careful which projects have deliverables 
in release 1.0. . I don’t think having deliverable in release 1.0 is a gating 
function of getting a project approved. So the TSC can approve projects that 
make sense  but as said I would discourage some of them to have a contribution 
to the 1.0 release. 
 
Probably just stating the obvious … .
 
Oliver
 
ProjectPotential Scope OverlappAAI
APPCCommon Controller… , VF-CAuthentication…