Re: [onap-tsc] 答复: Re: Proposal for Holmes project

[JI, LUSHENG (LUSHENG)]

Mazin and Junjie,

As I was preparing the DCAE project proposal,  I had the same impression as 
Mazin that Holmes correlation engine appeared to align well with DCAE's micro 
service analytics architecture.  Hence I put in a placeholder for possible 
harmonization  with Holmes.

However this afternoon I had some time to briefly scan through Holmes Mercury 
source code and now I am actually feeling less confident about this impression.

Holmes implementation appears to consist of code around two major functional 
components, a DB (mysql) and a rule engine (Drools).  The rules are stored in 
DB, and loaded into Drools engine.  The Drools engine monitors Active MQ topics 
for alarms, then matches alarms with some rules.  Is this high level 
understanding correct?

If so, this actually appears to resemble some of the Policy Engine 
implementations more than DCAE analytics (cc-ing Pam, who is Policy Engine 
lead).  I think we need to schedule a deep dive meeting finding how to best 
align.  Given now it is already Friday afternoon in China, shall we target 
early next week?

Thanks,
Lusheng




 Original message 
From: liu.junj...@zte.com.cn
Date: 5/11/17 11:10 PM (GMT-05:00)
To: gilb...@mail.linuxfoundation.org, "GILBERT, MAZIN E (MAZIN E)" 

Cc: fu.guangr...@zte.com.cn, onap-tsc@lists.onap.org
Subject: [onap-tsc] 答复: Re:  Proposal for Holmes project


Hi

   Yes, I agree with your suggestion, Holmes will be  a Microservice 
application running in DCAE just like all analytics Microservices. Holmes is 
not a independence application without DCAE structure.





刘军杰 liujunjie

GA产品经理  GA Product Manager
服务及MANO产品部/系统产品 Service & MANO Product Dept./System Product



原始邮件
发件人： ＜ma...@research.att.com＞;
收件人： ＜dr6...@att.com＞;刘军杰10037236;
抄送人： ＜onap-tsc@lists.onap.org＞;付光荣10144542;
日 期 ：2017年05月12日 10:40
主 题 ：Re: [onap-tsc] Proposal for Holmes project


Liu,
Interesting. I need to spend time looking at Holmes a bit closer.

From a first glance, the rule designer seems like a GUI for writing policies.
The correlation engine is an algorithm that ingest data and provides signatures
based on those correlations. If my interpretation is right, then I suggest
putting the correlation engine as a Microservice running in DCAE just
like all analytics Microservices.

The GUI is similar to CLAMP. CLAMP allows you to design open and closed
loop systems besides just putting the policies and rules. CLAMP connects
with ONAP during both design and runtime.

Something to think about.
thanks
mazin





On May 11, 2017, at 10:29 AM, ROSE, DANIEL V 
＜dr6...@att.com＞ wrote:

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

The dcae proposal includes holmes as a sub part (*  Holmes: this is an OpenO 
project that performs similar/related  role to DCAE.  Further information is 
needed for identifying path for normalization.)

Did you talk to anyone from dcae about overlap? If so what was the differences 
between your projects? Just trying to wrap my head around the difference for my 
own edification.

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

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On  Behalf Of 
liu.junj...@zte.com.cn
Sent: Thursday, May 11, 2017 4:32 AM
To: onap-tsc@lists.onap.org
Cc: fu.guangr...@zte.com.cn
Subject: [onap-tsc] Proposal for Holmes project


Dear all

   Holmes project provides alarm correlation and analysis for Telecom 
cloud infrastructure and services, including host, vim, vnf and ns. Homels aims 
to find the reason which cause the fail or degradation  of services by digging 
into the ocean of events collected from different levels of Telecom cloud.

   Holmes is a application that processes events published by managed 
resources or other applications that detect specific conditions. Based on 
defined root cause analysis rules about the network,  an application of this 
kind would determine root cause for various conditions and notify other 
interested applications.

＜image001.png＞



Holmes is consist of a rule designer and a correlation engine.Rule Designer 
provides a user-friendly GUI to design the Correlation rules.
Correlation Engine receives original alarms from monitor and output the result 
back to monitor after analysis based on rules and the resources relationships 
from AAI.
Real-time Analytic application get the analysis result, which is the root cause 
can be used to drive the policy runtime for automation operation.
＜image002.png＞

[onap-tsc] Project Proposal: MSB

[zhao.huabing]

Dear TSC,





We would like to formally propose ONAP project for MSB(Microservice Bus).




MSB provide 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.






More detailed information of MSB can be found at 
https://wiki.onap.org/display/DW/Microservices+Bus, including the project 
description, scope, architecture and resources.


 


Thanks and Regards,

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

[onap-tsc] 答复: Re: Proposal for Holmes project

[liu.junjie2]

Hi


   Yes, I agree with your suggestion, Holmes will be  a Microservice 
application running in DCAE just like all analytics Microservices. Holmes is 
not a independence application without DCAE structure.
















刘军杰 liujunjie


GA产品经理  GA Product Manager 
服务及MANO产品部/系统产品 Service & MANO Product Dept./System Product













原始邮件



发件人： ＜ma...@research.att.com＞
收件人： ＜dr6...@att.com＞刘军杰10037236
抄送人： ＜onap-tsc@lists.onap.org＞付光荣10144542
日 期 ：2017年05月12日 10:40
主 题 ：Re: [onap-tsc] Proposal for Holmes project





Liu,  
Interesting. I need to spend time looking at Holmes a bit closer.
 
From a first glance, the rule designer seems like a GUI for writing policies.
The correlation engine is an algorithm that ingest data and provides signatures 

based on those correlations. If my interpretation is right, then I suggest 

putting the correlation engine as a Microservice running in DCAE just 

like all analytics Microservices.
 
The GUI is similar to CLAMP. CLAMP allows you to design open and closed

loop systems besides just putting the policies and rules. CLAMP connects

with ONAP during both design and runtime.
 







Something to think about.

thanks

mazin 






 
On May 11, 2017, at 10:29 AM, ROSE, DANIEL V ＜dr6...@att.com＞ wrote:
 
***Security  Advisory: This  Message Originated Outside of AT *** Reference 
http://cso.att.com/EmailSecurity/IDSP.html for  more information. 

The dcae proposal includes holmes as a sub part (·  Holmes: this is an OpenO 
project that performs similar/related  role to DCAE.  Further information is 
needed for identifying path for normalization.)
 
Did you talk to anyone from dcae about overlap? If so what was the differences 
between your projects? Just trying to wrap my head around the difference for my 
own edification.
 
Thanks,

Daniel Rose

ECOMP / ONAP

com.att.ecomp

732-420-7308
 
From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On  Behalf Of liu.junj...@zte.com.cn Sent: Thursday, May 11, 2017 4:32 AM To: 
onap-tsc@lists.onap.org Cc: fu.guangr...@zte.com.cn Subject: [onap-tsc] 
Proposal for Holmes project
 

Dear all


   Holmes project provides alarm correlation and analysis for Telecom 
cloud infrastructure and services, including host, vim, vnf and ns. Homels aims 
to find the reason which cause the fail or degradation  of services by digging 
into the ocean of events collected from different levels of Telecom cloud.


   Holmes is a application that processes events published by managed 
resources or other applications that detect specific conditions. Based on 
defined root cause analysis rules about the network,  an application of this 
kind would determine root cause for various conditions and notify other 
interested applications.

＜image001.png＞


 


Holmes is consist of a rule designer and a correlation engine.Rule Designer 
provides a user-friendly GUI to design the Correlation rules.

Correlation Engine receives original alarms from monitor and output the result 
back to monitor after analysis based on rules and the resources relationships 
from AAI.

Real-time Analytic application get the analysis result, which is the root cause 
can be used to drive the policy runtime for automation operation. 

＜image002.png＞
 
https://wiki.onap.org/display/DW/Holmes

 



___ ONAP-TSC  mailing list 
ONAP-TSC@lists.onap.org 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=Def-eo3qaTtwrD5xDw94jFkzNZ4BDlZSFUX4kaN_jsU=6Zy6nCT9YhCL6c9oASVcOQXXfhxJA-Skj-Du9CSWFpg=___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Seed code for Service Orchestrator

[zhang.maopeng1]

hi eric




 Sorry, I don't preemail to the project contact person. I see in the wiki 
now the contact person is DeWayne Filppi (dewa...@gigaspaces.com),  right?




 We are an open community combined from openo and openecomp and other 
companies.

The SO seed code link from the both side can be provided. however in the 
wiki, the link is empty.  we should have a start point to contribute the 
infomation.   

 See the mutlvim project also provide the openo and ecomp seed code link, 
and other project wiki.

 So I provide the possible seed code link from the openo,  and just want to 
provide more infomation to project and have a good start to discuss the code. 

  The link from the ecomp mso also should be provided ASAP.

  Hope we are open and have an good discussion for the developers in the 
projects.



Best Regards

Maopeng



原始邮件



发件人： ＜eric.deb...@orange.com＞
收件人： ＜onap-tsc@lists.onap.org＞
日 期 ：2017年05月12日 03:48
主 题 ：[onap-tsc]  Seed code for Service Orchestrator







Hello


 


I am surprised to discover that open-o/gso is considered as the seed code for 
the Service Orchestrator.


 


As far as I know, we never decided such choice during the discussions last week 
and it should be a TSC decision.


 


Regards


 


Eric


_
  Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.  This 
message and its attachments may contain confidential or privileged information 
that may be protected by law they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message and its attachments. As emails may be 
altered, Orange is not liable for messages that have been modified, changed or 
falsified. Thank you.___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal for Holmes project

[GILBERT, MAZIN E (MAZIN E)]

Liu,

Interesting. I need to spend time looking at Holmes a bit closer.

From a first glance, the rule designer seems like a GUI for writing policies.
The correlation engine is an algorithm that ingest data and provides signatures
based on those correlations. If my interpretation is right, then I suggest
putting the correlation engine as a Microservice running in DCAE just
like all analytics Microservices.

The GUI is similar to CLAMP. CLAMP allows you to design open and closed
loop systems besides just putting the policies and rules. CLAMP connects
with ONAP during both design and runtime.

Something to think about.
thanks
mazin





On May 11, 2017, at 10:29 AM, ROSE, DANIEL V 
> wrote:

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

The dcae proposal includes holmes as a sub part (•  Holmes: this is an OpenO 
project that performs similar/related role to DCAE.  Further information is 
needed for identifying path for normalization.)

Did you talk to anyone from dcae about overlap? If so what was the differences 
between your projects? Just trying to wrap my head around the difference for my 
own edification.

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

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of 
liu.junj...@zte.com.cn
Sent: Thursday, May 11, 2017 4:32 AM
To: onap-tsc@lists.onap.org
Cc: fu.guangr...@zte.com.cn
Subject: [onap-tsc] Proposal for Holmes project


Dear all

   Holmes project provides alarm correlation and analysis for Telecom 
cloud infrastructure and services, including host, vim, vnf and ns. Homels aims 
to find the reason which cause the fail or degradation of services by digging 
into the ocean of events collected from different levels of Telecom cloud.

   Holmes is a application that processes events published by managed 
resources or other applications that detect specific conditions. Based on 
defined root cause analysis rules about the network, an application of this 
kind would determine root cause for various conditions and notify other 
interested applications.





Holmes is consist of a rule designer and a correlation engine.Rule Designer 
provides a user-friendly GUI to design the Correlation rules.
Correlation Engine receives original alarms from monitor and output the result 
back to monitor after analysis based on rules and the resources relationships 
from AAI.
Real-time Analytic application get the analysis result, which is the root cause 
can be used to drive the policy runtime for automation operation.


https://wiki.onap.org/display/DW/Holmes



___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=Def-eo3qaTtwrD5xDw94jFkzNZ4BDlZSFUX4kaN_jsU=6Zy6nCT9YhCL6c9oASVcOQXXfhxJA-Skj-Du9CSWFpg=

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

[onap-tsc] [ONAP STANDARDS/SDO COORDINATOR ELECTION] Kickoff of the ONAP Standards/SDO Coordinator Election

[Phil Robb]

Hello ONAP Community Members:

Please consider this email as the kickoff of the ONAP Standards/SDO
Coordinator Election process.  A description of the role can be found on
the ONAP Technical Community Coordinator's page here:
https://wiki.onap.org/display/DW/Technical+Community+Coordinators

Please recall, as stated in section 5.2.2.2 of the ONAP TSC Charter, any
member of the technical community is eligible to run for this position.  It
is not exclusively reserved for TSC Members.  However, only TSC members are
eligible to vote when choosing among the potential candidates.  This
position serves at the pleasure of the TSC and TSC Chairperson.

There are two phases to the election process.  The first is the Nomination
Phase where community members may nominate themselves for the position of
"ONAP Standards/SDO Coordinator".  Once the Nomination Phase has concluded,
we will enter the Election Phase, where all ONAP TSC Members are invited
and encouraged to vote on the candidates whom have been nominated.

Timing:

   - Nominations open May 11th, 2017.
   - Nominations close May 17th at 9:00pm Pacific Time
   - Voting begins May 18th, 2017
   - Voting Ends May 24th, 2017 at 9:00pm Pacific Time


If you wish to nominate yourself for the position of "ONAP Standards/SDO
Coordinator", please respond-all to this email with your picture
(headshot), biography, and statement of interest on why you would wish to
hold the position.  I wlll post this information to the wiki prior to the
start of the election so that everyone in the technical community is able
to become familiar with the candidates.

If you have any questions, please do not hesitate to contact me.

Best,

Phil.
-- 
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Kanagaraj Manickam]

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman ; onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

• TSC subcommittee name:
Architecture Subcommittee (ARC)

• TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

The architecture subcommittee is advisory by nature, and not authoritative. It 
may provide advice to projects and to the TSC, such as by providing a forum to 
help resolve architectural questions that may arise.

The architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

• TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

• TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any 

Re: [onap-tsc] ONAP University Project Proposal

[Don Clarke]

Nermin/Mazin,

This is a very good initiative. Can I suggest that there is a plan to include 
module(s) that describe how ONAP relates to the standards bodies that are also 
playing an important role in the NFV ecosystem.

I see mention of "ecosystem" and "upstream projects". I don't see explicit 
mention of standards.

ONAP adoption is in part dependent on those relationships being productive to 
avoid fragmentation and to be compatible with corporate mandates around 
telecommunications standards.

There is a list of relevant bodies being developed as part of the TSC Standards 
and Open Source coordinator discussion. The needed educational material could 
be coordinated through that effort.

For example an extensive body of tutorial material already exists for ETSI NFV. 
I'm sure similar collateral exists amongst the other bodies.

Best regards,
Don Clarke.

On May 11, 2017, at 14:08, Nermin Mohamed 
> wrote:

Hello,

ONAP University Project proposal is ready for review by ONAP TSC.

ONAP University
Contact: Mazin Gilbert (AT) and Nermin Mohamed (Huawei)
Description:
Provide overview of the ONAP University training courses for users, developers 
and any other interested parties of member and non-member companies.
This is to help SPs, vendors and suppliers to build up their team’s ONAP 
expertise to increase the success of adopting ONAP.
A variety of delivery options:

· Video Training

· Online Training

· Classroom training

· Hands-on training

· ONAP Certification

· Online tutorials and guides

· ONAP Blog

· Webinar

· Online nanodegrees
Training can be customized based on end user’s needs


Please see attached document for details. Please advise if you need any further 
detail.


BR//Nermin

Nermin Mohamed
Vice President, Solutions and Marketing
Huawei Technologies USA, Inc.
5700 Tennyson Parkway, Suite 500,
Plano, Texas 75024
Office: 214-919-6123
Mobile: 214-537-7985
Fax: 214-919-6597
email: nermin.moha...@huawei.com
www.huawei.cpm/us






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

Re: [onap-tsc] CI/CD

[Christopher Donley (Chris)]

Gildas and I have been participating in the group, representing OPEN-O, and 
Phil has been active, as well.  This group is working more along the lines of 
harmonizing tools, labs, and processes, rather than Integration.

I would recommend whomever is maintaining the CI/CD tooling and infrastructure 
requirements participate in the activity.

Chris

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of ROSE, DANIEL V
Sent: Thursday, May 11, 2017 1:54 PM
To: Stephen Terrill; onap-tsc
Subject: Re: [onap-tsc] CI/CD

I think we can just drop in ONAP to that list were Open-O is.
There is an integration project here in ONAP being proposed so that would apply 
still unless the TSC wants a separate coordinator here instead.


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

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Thursday, May 11, 2017 4:47 PM
To: onap-tsc 
Subject: [onap-tsc] CI/CD

Hi All,

I've become aware of colloborative work between a number of communities 
regarding CI/CD, where there is information here: 
https://wiki.opnfv.org/display/INF/Infra+Collaboration

I assume it would be good to consider this as well from an ONAP perspective.  
Any ideas on how we should?  Under the integration project? Or opensource 
coordinator?

Best regards,

Steve.


[Ericsson]
STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

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

Re: [onap-tsc] CI/CD

[Bob Monkman]

Hi,
  As an OPNFV Board member, I can confirm that this was indeed a 
high priority of the cross project harmonization discussion from the Leadership 
Summit in Lake Tahoe and progress ongoing. I would recommend ONAP TSC to 
coordinate thru the appropriate means in a common CI/CD. I will ask Fatih D who 
wrote that page in OPNFV wiki. to update to add ONAP to the list for their 
reference.

Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of SPATSCHECK, OLIVER (OLIVER)
Sent: Thursday, May 11, 2017 1:59 PM
To: Stephen Terrill 
Cc: onap-tsc 
Subject: Re: [onap-tsc] CI/CD


Yes that would be in scope of the integration project.

Oliver

On May 11, 2017, at 4:46 PM, Stephen Terrill 
> wrote:

Hi All,

I’ve become aware of colloborative work between a number of communities 
regarding CI/CD, where there is information 
here:https://wiki.opnfv.org/display/INF/Infra+Collaboration

I assume it would be good to consider this as well from an ONAP perspective.  
Any ideas on how we should?  Under the integration project? Or opensource 
coordinator?

Best regards,

Steve.


[Ericsson]


STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=BiE0UeMVWL5BFRE96kIMByH1XejOpwHbW3SIxLd5Cq8=HRf6t_SB0Ec1Y5h2_JGwQWflOuJIVBmcBS66AEBNhxk=

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] CI/CD

[SPATSCHECK, OLIVER (OLIVER)]

Yes that would be in scope of the integration project.

Oliver

On May 11, 2017, at 4:46 PM, Stephen Terrill 
> wrote:

Hi All,

I’ve become aware of colloborative work between a number of communities 
regarding CI/CD, where there is information 
here:https://wiki.opnfv.org/display/INF/Infra+Collaboration

I assume it would be good to consider this as well from an ONAP perspective.  
Any ideas on how we should?  Under the integration project? Or opensource 
coordinator?

Best regards,

Steve.


[Ericsson]

STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=BiE0UeMVWL5BFRE96kIMByH1XejOpwHbW3SIxLd5Cq8=HRf6t_SB0Ec1Y5h2_JGwQWflOuJIVBmcBS66AEBNhxk=

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

Re: [onap-tsc] CI/CD

[ROSE, DANIEL V]

I think we can just drop in ONAP to that list were Open-O is.
There is an integration project here in ONAP being proposed so that would apply 
still unless the TSC wants a separate coordinator here instead.


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

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Thursday, May 11, 2017 4:47 PM
To: onap-tsc 
Subject: [onap-tsc] CI/CD

Hi All,

I've become aware of colloborative work between a number of communities 
regarding CI/CD, where there is information here: 
https://wiki.opnfv.org/display/INF/Infra+Collaboration

I assume it would be good to consider this as well from an ONAP perspective.  
Any ideas on how we should?  Under the integration project? Or opensource 
coordinator?

Best regards,

Steve.


[Ericsson]
STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

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

[onap-tsc] CI/CD

[Stephen Terrill]

Hi All,

I've become aware of colloborative work between a number of communities 
regarding CI/CD, where there is information here: 
https://wiki.opnfv.org/display/INF/Infra+Collaboration

I assume it would be good to consider this as well from an ONAP perspective.  
Any ideas on how we should?  Under the integration project? Or opensource 
coordinator?

Best regards,

Steve.


[Ericsson]

STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

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

Re: [onap-tsc] Seed code for Service Orchestrator

[eric.debeau]

+1

De : Ed Warnicke [mailto:hagb...@gmail.com]
Envoyé : jeudi 11 mai 2017 22:17
À : ROSE, DANIEL V
Cc : SPATSCHECK, OLIVER; DEBEAU Eric IMT/OLN; dewa...@gigaspaces.com; 
onap-tsc@lists.onap.org
Objet : Re: [onap-tsc] Seed code for Service Orchestrator

In many other communities, as a matter of social norm, not governance, if one 
is going to edit a project proposal, it is considered good manners to ask the 
originator of a proposal before editing it in a substantive way.

Perhaps we should consider communicating this social norm withing the ONAP 
community to avoid confusion?

Ed

On Thu, May 11, 2017 at 4:11 PM, ROSE, DANIEL V 
> wrote:
There has been a ton of change on the page in the last day: 
https://wiki.onap.org/pages/diffpagesbyversion.action?pageId=4719246=29=6

I hope everyone who needed to be involved has been involved because I didn't 
see much public discussion about this project on this mailing lists.

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

-Original Message-
From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org]
 On Behalf Of SPATSCHECK, OLIVER
Sent: Thursday, May 11, 2017 4:05 PM
To: eric.deb...@orange.com; 
dewa...@gigaspaces.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Seed code for Service Orchestrator

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


So am I.  I thought in the charter we had agreed that the MSO code base would 
be used for this. Similar to the 3 legacy Open-O components.

Was there any discussion on this anywhere?

Thx

Oliver

> On May 11, 2017, at 3:48 PM  EDT, 
> eric.deb...@orange.com wrote:
>
> Hello
>
> I am surprised to discover that open-o/gso is considered as the seed code for 
> the Service Orchestrator.
>
> As far as I know, we never decided such choice during the discussions last 
> week and it should be a TSC decision.
>
> Regards
>
> Eric
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=yopWEEan7upXoI1z2e3hU3o52mzgW69H-rB7ZIT8-A8=r3tAPP-TO6TFW9dliuNeUQRkuweOwDof8ZXXYNxy8nw=

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=2wwdGZ3YcpSivQ2Kio028A=P3ocIvjpt_xeLNXVAxRECvAWNuMr4HDtz-qc9fROO9A=e4Ns63-VStxhnMGdv7vWHVfxhjlPO8z9gu3k3E6shes=
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please 

Re: [onap-tsc] Seed code for Service Orchestrator

[Ed Warnicke]

In many other communities, as a matter of social norm, not governance, if
one is going to edit a project proposal, it is considered good manners to
ask the originator of a proposal before editing it in a substantive way.

Perhaps we should consider communicating this social norm withing the ONAP
community to avoid confusion?

Ed

On Thu, May 11, 2017 at 4:11 PM, ROSE, DANIEL V  wrote:

> There has been a ton of change on the page in the last day:
> https://wiki.onap.org/pages/diffpagesbyversion.action?pageId=4719246;
> selectedPageVersions=29=6
>
> I hope everyone who needed to be involved has been involved because I
> didn't see much public discussion about this project on this mailing lists.
>
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
>
> -Original Message-
> From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] On Behalf Of SPATSCHECK, OLIVER
> Sent: Thursday, May 11, 2017 4:05 PM
> To: eric.deb...@orange.com; dewa...@gigaspaces.com
> Cc: onap-tsc@lists.onap.org
> Subject: Re: [onap-tsc] Seed code for Service Orchestrator
>
> *** Security Advisory: This Message Originated Outside of AT ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>
>
> So am I.  I thought in the charter we had agreed that the MSO code base
> would be used for this. Similar to the 3 legacy Open-O components.
>
> Was there any discussion on this anywhere?
>
> Thx
>
> Oliver
>
> > On May 11, 2017, at 3:48 PM  EDT, eric.deb...@orange.com wrote:
> >
> > Hello
> >
> > I am surprised to discover that open-o/gso is considered as the seed
> code for the Service Orchestrator.
> >
> > As far as I know, we never decided such choice during the discussions
> last week and it should be a TSC decision.
> >
> > Regards
> >
> > Eric
> > 
> _
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
> > ___
> > ONAP-TSC mailing list
> > ONAP-TSC@lists.onap.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=
> 3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=
> yopWEEan7upXoI1z2e3hU3o52mzgW69H-rB7ZIT8-A8=r3tAPP-
> TO6TFW9dliuNeUQRkuweOwDof8ZXXYNxy8nw=
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=
> 2wwdGZ3YcpSivQ2Kio028A=P3ocIvjpt_xeLNXVAxRECvAWNuMr4HDtz-
> qc9fROO9A=e4Ns63-VStxhnMGdv7vWHVfxhjlPO8z9gu3k3E6shes=
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Seed code for Service Orchestrator

[ROSE, DANIEL V]

There has been a ton of change on the page in the last day: 
https://wiki.onap.org/pages/diffpagesbyversion.action?pageId=4719246=29=6

I hope everyone who needed to be involved has been involved because I didn't 
see much public discussion about this project on this mailing lists. 

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

-Original Message-
From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of SPATSCHECK, OLIVER
Sent: Thursday, May 11, 2017 4:05 PM
To: eric.deb...@orange.com; dewa...@gigaspaces.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Seed code for Service Orchestrator

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


So am I.  I thought in the charter we had agreed that the MSO code base would 
be used for this. Similar to the 3 legacy Open-O components.

Was there any discussion on this anywhere?

Thx

Oliver

> On May 11, 2017, at 3:48 PM  EDT, eric.deb...@orange.com wrote:
> 
> Hello
>  
> I am surprised to discover that open-o/gso is considered as the seed code for 
> the Service Orchestrator.
>  
> As far as I know, we never decided such choice during the discussions last 
> week and it should be a TSC decision.
>  
> Regards
>  
> Eric
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=yopWEEan7upXoI1z2e3hU3o52mzgW69H-rB7ZIT8-A8=r3tAPP-TO6TFW9dliuNeUQRkuweOwDof8ZXXYNxy8nw=

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=2wwdGZ3YcpSivQ2Kio028A=P3ocIvjpt_xeLNXVAxRECvAWNuMr4HDtz-qc9fROO9A=e4Ns63-VStxhnMGdv7vWHVfxhjlPO8z9gu3k3E6shes=
 
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Seed code for Service Orchestrator

[SPATSCHECK, OLIVER (OLIVER)]

So am I.  I thought in the charter we had agreed that the MSO code base would 
be used for this. Similar to the 3 legacy Open-O components.

Was there any discussion on this anywhere?

Thx

Oliver

> On May 11, 2017, at 3:48 PM  EDT, eric.deb...@orange.com wrote:
> 
> Hello
>  
> I am surprised to discover that open-o/gso is considered as the seed code for 
> the Service Orchestrator.
>  
> As far as I know, we never decided such choice during the discussions last 
> week and it should be a TSC decision.
>  
> Regards
>  
> Eric
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=yopWEEan7upXoI1z2e3hU3o52mzgW69H-rB7ZIT8-A8=r3tAPP-TO6TFW9dliuNeUQRkuweOwDof8ZXXYNxy8nw=

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

Re: [onap-tsc] Seed code for Service Orchestrator

[jamil.chawki]

Hello
I can't understand how projects editing are managed, modifications are 
introduced in SO project without agreement and not aligned with the what were 
discussed and agreed last week.

Phil,  Mazin cloud you clarify the situation ?
Regards
Jamil

Le 11 mai 2017 à 21:48, "eric.deb...@orange.com" 
> a écrit :

Hello

I am surprised to discover that open-o/gso is considered as the seed code for 
the Service Orchestrator.

As far as I know, we never decided such choice during the discussions last week 
and it should be a TSC decision.

Regards

Eric

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[onap-tsc] Seed code for Service Orchestrator

[eric.debeau]

Hello

I am surprised to discover that open-o/gso is considered as the seed code for 
the Service Orchestrator.

As far as I know, we never decided such choice during the discussions last week 
and it should be a TSC decision.

Regards

Eric

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Bob Monkman]

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman ; onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

• TSC subcommittee name:
Architecture Subcommittee (ARC)

• TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

The architecture subcommittee is advisory by nature, and not authoritative. It 
may provide advice to projects and to the TSC, such as by providing a forum to 
help resolve architectural questions that may arise.

The architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

• TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

• TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] ONAP University Project Proposal

[Nermin Mohamed]

Hello,

ONAP University Project proposal is ready for review by ONAP TSC.

ONAP University
Contact: Mazin Gilbert (AT) and Nermin Mohamed (Huawei)
Description:
Provide overview of the ONAP University training courses for users, developers 
and any other interested parties of member and non-member companies.
This is to help SPs, vendors and suppliers to build up their team's ONAP 
expertise to increase the success of adopting ONAP.
A variety of delivery options:

* Video Training

* Online Training

* Classroom training

* Hands-on training

* ONAP Certification

* Online tutorials and guides

* ONAP Blog

* Webinar

* Online nanodegrees
Training can be customized based on end user's needs


Please see attached document for details. Please advise if you need any further 
detail.


BR//Nermin

Nermin Mohamed
Vice President, Solutions and Marketing
Huawei Technologies USA, Inc.
5700 Tennyson Parkway, Suite 500,
Plano, Texas 75024
Office: 214-919-6123
Mobile: 214-537-7985
Fax: 214-919-6597
email: nermin.moha...@huawei.com
www.huawei.cpm/us

[logo]

[20_popular_social_media_icons__psd__by_softarea-d5xkanw.jpg][20_popular_social_media_icons__psd__by_softarea-d5xkanw.jpg][20_popular_social_media_icons__psd__by_softarea-d5xkanw.jpg][20_popular_social_media_icons__psd__by_softarea-d5xkanw.jpg][20_popular_social_media_icons__psd__by_softarea-d5xkanw.jpg]



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

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Christopher Donley (Chris)]

Bob,

I propose that it's open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

* TSC subcommittee name:
Architecture Subcommittee (ARC)

* TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

The architecture subcommittee is advisory by nature, and not authoritative. It 
may provide advice to projects and to the TSC, such as by providing a forum to 
help resolve architectural questions that may arise.

The architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

* TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

* TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Bob Monkman]

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

* TSC subcommittee name:
Architecture Subcommittee (ARC)

* TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

The architecture subcommittee is advisory by nature, and not authoritative. It 
may provide advice to projects and to the TSC, such as by providing a forum to 
help resolve architectural questions that may arise.

The architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

* TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

* TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN support proposal at OASIS TOSCA WG

[Haiby, Ranny (Nokia - US/San Jose USA)]

Huabing,

I like your direction of giving concrete examples for possible implementation 
that you did in some other branch of this thread. Following that, could you 
please illustrate how the following scenario will be addressed with a BPMN 
workflow:

Let say I am deploying an EPC P-GW, and in that process I need to configure 
DIAMETER-peers on a physical MME so it can communicate with my newly created 
GW. So, after creating some server nodes, TOSCA will need to call an external 
BPMN workflow and pass as a parameter the IP address of one of the newly 
created server nodes. Also, after the workflow is completed, a port number is 
allocated for the DIAMETER session and it needs to be configured on a security 
group, so it needs to be passed back to TOSCA as a parameter. Could you 
elaborate on how this back and forth switch of control and information exchange 
could happen?

Thanks,

Ranny.

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Nati Shalom
Sent: Thursday, May 11, 2017 6:41 AM
To: Michael Brenner ; Huabing Zhao 

Cc: onap-discuss ; onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposal 
at OASIS TOSCA WG

"The proposal has been discussed in the OASIS TOSCA for a couple of weeks and 
most of the members agreed on it except the strong pushback from Michael of 
Gigaspaces."

Huabing et al

I wanted to ask that we will keep the discussion on a professional and not a 
personal level.

First i want to clarify what were discussing here right now is not a question 
of declarative vs impressive workflow as it is being coined for some reason.
What were really discussing is whether we use TOSCA as a configuration input or 
as a model that represent a live system and allow continues interaction with 
system through the model e.g. Model Driven.

So the discussion is wether ONAP orchestration should be truly model driven or 
not and not whether we should support declarative vs imperative workflow and 
whether that workflow should be written in BPMN or some other language.

There is also no real argument on whether you can or can't use BPMN as a 
workflow engine.  Intact if things done right we should't even care about it.

I think that we all agreed that an implementor can choose to run the workflow 
in what ever language or format he wishes and that should become a "black-box" 
from the Orchestrator perspective.

To allow this kind of flexibility i.e. allow the implementor to choose the 
workflow language that fits best to his needs we need to define a clear 
interface on how the execution get called and also how the state of the model 
get effected once that execution is completed.

That's what Michael is basically trying to say repetitively but unfortunately 
he's comment are being ignored.

Both Michael myself are more than happy to work with you or anyone else on the 
proposal for defining those interfaces assuming that we agree with the goal and 
scope toward a true Model Driven orchestration.

Speaking of a community process.
I would appreciate if you could respond to the questions that was raised here 
an on the OASIS discussion about the proposal in order that we could have a 
constructive dialogue and move forward.

Here is a summary of some of those questions that were left un answered:

1. What's in your proposal should be the effect on the model after the 
execution is completed?  (I assume that right now this is considered out of 
scope in the current proposal right?)

2. Your making assumption on what works for Telco vs Simple use cases. (This 
goes with the declarative vs imperative for some reason even though i'm not 
sure how the two are even related). Can you share on what basis are you making 
those assumptions?

3. If we agree to leave that the implementation of the workflow should be 
treated as a blackbox why do we need a specific specification proposal for BPMN 
?

Let's start with that.
As i mentioned we would be more than happy to work with you on those areas and 
put more clarity behind those items.

Nati S.








On Wed, May 10, 2017 at 9:03 AM Michael Brenner 
> wrote:
Huabing,

I recognize the need in ONAP to support delegation in TOSCA to external 
workflow engines. I have said this repeatedly, and still am miss-interpreted.
This has nothing to do with backward compatibility to TOSCA 1.0, it only has to 
do with supporting "facts on the ground/existing implementations". We should 
get this agreed once for all, and it became obvious in ONAP's Friday modeling 
discussion.

It also became clear that some of these "facts-on-the-ground" use TOSCA in a 
limited way. This is OK, and I have no issue with that. I can support in TOSCA 
TC to find the right mechanism to delegate externally, but only if we do it in 
a way that is complete: that means we need 

Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on Containers

[Phil Robb]

Hello David:

Yes, all project proposals need to be on the "Proposing a Project" page.
Please move your second proposal to that page if it is wholly separate and
distinct of the first proposal.  If it is a "subproject" or "subcomponent"
of the first project, then please just add the documentation for it to the
first proposal's wiki page.

Thanks.

Phil.

On Wed, May 10, 2017 at 3:35 PM, Sauvageau, David 
wrote:

> Oliver – I can move it there. Was not aware thanks
>
> On 2017-05-10, 3:30 PM, "SPATSCHECK, OLIVER  (OLIVER)" <
> spat...@research.att.com> wrote:
>
>
> I would assume so otherwise we would have duplication.
>
> On an editorial note I thought we were supposed to move the proposal
> links above the project proposal draft line here:
>
> https://wiki.onap.org/display/DW/Proposing+A+Project
>
> when they are ready for the TSC review period.
>
> Thx
>
> Oliver
>
> > On May 10, 2017, at 3:11 PM  EDT, Yunxia Chen 
> wrote:
> >
> > Hi, David,
> > Could this manager be used for “Distribution” and “Packaging” of
> ONAP? Please refer to:
> > https://wiki.onap.org/display/DW/Integration
> >
> > Regards,
> >
> > Helen Chen
> >
> > From:  on behalf of "Sauvageau,
> David" 
> > Date: Wednesday, May 10, 2017 at 11:30 AM
> > To: "onap-tsc@lists.onap.org" 
> > Subject: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP
> on Containers
> >
> > Dear TSC,
> >
> > I would like to formally propose 2 projects to simplify the
> deployment and the operations of the ONAP platform and components.
> >
> > Project: ONAP Operations Manager (Formerly ONAP controller) -
> https://wiki.onap.org/display/DW/ONAP+Operations+Manager
> >
> > This proposal introduces the ONAP Platform OOM (ONAP Operations
> Manager) to efficiently Deploy, Manage, Operate the ONAP platform and its
> components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs,
> Containers). The OOM addresses the current lack of consistent platform-wide
> method in managing software components, their health, resiliency and other
> lifecycle management functions.  With OOM, service providers will have a
> single dashboard/UI to deploy & un-deploy the entire (or partial) ONAP
> platform, view the different instances being managed and the state of each
> component, monitor actions that have been taken as part of a control loop
> (e.g., scale in-out, self-heal), and trigger other control actions like
> capacity augments across data centers.
> >
> > Sub-project: ONAP Operations Manager / ONAP on Containers -
> https://wiki.onap.org/pages/viewpage.action?pageId=3247305
> >
> > This project describes a deployment and orchestration option for the
> ONAP platform components (MSO, SDNC, DCAE, etc.) based on Docker containers
> and the open-source Kubernetes container management system. This solution
> removes the need for VMs to be deployed on the servers hosting ONAP
> components and allows Docker containers to directly run on the host
> operating system.
> >
> > The primary benefits of this approach are as follows:
> >   • Life-cycle Management. Kubernetes is a comprehensive system for
> managing the life-cycle of containerized applications.  Its use as a
> platform manager will ease the deployment of ONAP, provide fault tolerance
> and horizontal scalability, and enable seamless upgrades.
> >   • Hardware Efficiency. As opposed to VMs that require a guest
> operating system be deployed along with the application, containers provide
> similar application encapsulation with neither the computing, memory and
> storage overhead nor the associated long term support costs of those guest
> operating systems.
> >   • Deployment Speed. Eliminating the guest operating system results
> in containers coming into service much faster than a VM equivalent. This
> advantage can be particularly useful for ONAP where rapid reaction to
> inevitable failures will be critical in production environments.
> >   • Cloud Provider Flexibility. A Kubernetes deployment of ONAP
> enables hosting the platform on multiple hosted cloud solutions like Google
> Compute Engine, AWS EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix
> and more.
> >
> >
> > We currently have the support of Bell, AMDOCS, AT, Orange,
> Ericsson and Gigaspaces on the project and still looking for more. Please
> review and comment!
> >
> > Thanks,
> > David Sauvageau, Bell Canada.
> >
> > *** PS you may have received this proposal twice since my original
> seemed to have bounced.
> > ___
> > ONAP-TSC mailing list
> > ONAP-TSC@lists.onap.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> 

Re: [onap-tsc] Creation Request for Coordination Area Standard/SDO

[Alla Goldner]

Hi,

Some more updates:


• IETF YANG/NETMOD/SUPA (IRTF NFVRG)

• TMF OSS/API/ZOOM

• MEF LSO

• ETSI NFV

• ETSI MEC

• OASIS TOSCA

• 3GPP SA5 and SA2 (5G architecture, service chaining, network slicing 
etc.)

• BBF SDN/NFV Work Area

· OCI Container


Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CA8F.698B32F0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of jamil.cha...@orange.com
Sent: Wednesday, May 10, 2017 11:41 PM
To: 邓灵莉 ; onap-tsc 
Subject: Re: [onap-tsc] Creation Request for Coordination Area Standard/SDO

Hello
Here with some updates on the list:

• IETF YANG/NETMOD/SUPA (IRTF NFVRG)

• TMF OSS/API/ZOOM

• MEF LSO

• ETSI NFV/MEC

• OASIS TOSCA

• 3GPP SA5

• BBF vGW

· OCI Container

Regards

Jamil



De : onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] De la part de ???
Envoyé : mercredi 10 mai 2017 17:18
À : onap-tsc
Objet : [onap-tsc] Creation Request for Coordination Area Standard/SDO


Coordination Area Description:



Open source and standard are compliementing each other. Opensource is playing 
an increasing important role in SDO practice, which could help to gain industry 
concensus and adoption.



The potential standard bodies and topics include:

• IETF YANG/NETMOD NFVRG

• TMF OSS/API/ZOOM

• MEF LSO

• ETSI NFV/MEC

• OASIS TOSCA

• 3GPP

• BBF



Coordinator Responsibilities Description:

• External Responsibilities:

•  Identify members of the ONAP community with existing relationships to 
external SDOs, and work with them to identify and follow the overlap in 
interest or practice from standard bodies related to ONAP’s implementation and 
report to TSC regularly or on demand.

•  Develop ONAP collaboration strategy with, coordinate ONAP presence, 
delegation and participation to identified SDO practices and report to TSC 
regularly or on demand.

• Internal Responsibilities:

  •  Work with individual projects in soliciting and identification of 
related SDO practices.

•  Coordinate between implementation project in ONAP and identified SDO 
practice and report to TSC regularly or on demand.

•  Coordinate among multiple implementation projects in ONAP which fall into 
scope of a given SDO spec and report to TSC regularly or on demand.



Report Cadence:

• Regularly each TSC F2F meeting.

• On-demand report based on urgency of the event.



Area Coordinator:

Hui Deng denghu...@huawei.com

Lingli/邓灵莉

中国移动通信研究院

denglin...@chinamobile.com



_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
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-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Project Proposal for SNIRO (Optimization Framework)

[Phil Robb]

Thank you Sastry for your submission.

Phil.

On Thu, May 11, 2017 at 8:45 AM, ISUKAPALLI, SASTRY S (SASTRY) <
sas...@research.att.com> wrote:

> Hello Committee Members,
>
>
>
> I would like to submit a project proposal for SNIRO (Optimization
> Framework):
>
>
> https://wiki.onap.org/display/DW/SNIRO+Optimization+Framework
>
>
>
> The SNIRO project (Service, Network, Infrastructure, and Resource
> Optimization) focuses on providing a platform for addressing different
> optimization (and resource allocation) needs and aims to provide
> "optimization as a service".
>
>
> Thanks,
>
> Sastry
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
>


-- 
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Project Proposal: Modeling

[denghui (L)]

Dear TSC,

We would like to formally propose ONAP project for Modeling.
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/Modeling

The Modeling team consists of representatives from AT, Huawei, China Mobile, 
Cisco, ZTE, Gigaspaces, Amdocs, Nokia, IBM, Windriver, Intel, Techmahindra, 
Ciena

Regards,

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

[onap-tsc] Integration Project Proposal

[Yunxia Chen]

Dear ONAP TSC,

I would like to formally propose Integration project for your approval.

Project details: https://wiki.onap.org/display/DW/Integration

Participants: Amdocs, AT, China Mobile, China Telecom, Huawei, Mirantis, 
Orange, TechMahindra, ZTE

Regards,
Helen Chen

Principal Architect, Open Orchestration
Huawei US R Center
Futurewei Technologies, Inc.

2330 Central Expressway, C2-16
Santa Clara, CA 95050
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Active and Available Inventory Project proposal

[Colin Burns]

Hello,

Active and Available Inventory Project proposal is ready for review by the ONAP 
TSC.
https://wiki.onap.org/pages/viewpage.action?pageId=3246952

Please advise if you need any further detail.

regards,
Colin


Colin Burns
Product Manager
Amdocs Open Network

mobile: +44(0) 7717 505854
office:   +44 (0) 1225 327275

[amdocs-2017-brand-mark-rgb]

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-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] Project Proposal: DCAE

[JI, LUSHENG (LUSHENG)]

Dear TSC,

We would like to formally propose ONAP project for DCAE.
The proposal wiki page, which includes details of the project description 
(including sub projects), project scopes, and proposed repo names, can be found 
at:  https://wiki.onap.org/display/DW/DCAE.

The DCAE team consists of representatives from DT, Huawei/Futurewei, Intel, 
Orange, Reliance Jio, Tech Mahindra, ZTE, and AT

Regards,

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

Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN support proposal at OASIS TOSCA WG

[Nati Shalom]

"The proposal has been discussed in the OASIS TOSCA for a couple of weeks
and most of the members agreed on it except the strong pushback from
Michael of Gigaspaces."

Huabing et al

I wanted to ask that we will keep the discussion on a professional and not
a personal level.

First i want to clarify what were discussing here right now is not a
question of declarative vs impressive workflow as it is being coined for
some reason.
What were really discussing is whether we use TOSCA as a configuration
input or as a model that represent a live system and allow continues
interaction with system through the model e.g. Model Driven.

So the discussion is wether ONAP orchestration should be truly model driven
or not and not whether we should support declarative vs imperative workflow
and whether that workflow should be written in BPMN or some other language.

There is also no real argument on whether you can or can't use BPMN as a
workflow engine.  Intact if things done right we should't even care about
it.

I think that we all agreed that an implementor can choose to run the
workflow in what ever language or format he wishes and that should become a
"black-box" from the Orchestrator perspective.

To allow this kind of flexibility i.e. allow the implementor to choose the
workflow language that fits best to his needs we need to define a clear
interface on how the execution get called and also how the state of the
model get effected once that execution is completed.

That's what Michael is basically trying to say repetitively but
unfortunately he's comment are being ignored.

Both Michael myself are more than happy to work with you or anyone else on
the proposal for defining those interfaces assuming that we agree with the
goal and scope toward a true Model Driven orchestration.

Speaking of a community process.
I would appreciate if you could respond to the questions that was raised
here an on the OASIS discussion about the proposal in order that we could
have a constructive dialogue and move forward.

Here is a summary of some of those questions that were left un answered:

1. What's in your proposal should be the effect on the model after the
execution is completed?  (I assume that right now this is considered out of
scope in the current proposal right?)

2. Your making assumption on what works for Telco vs Simple use cases.
(This goes with the declarative vs imperative for some reason even though
i'm not sure how the two are even related). Can you share on what basis are
you making those assumptions?

3. If we agree to leave that the implementation of the workflow should be
treated as a blackbox why do we need a specific specification proposal for
BPMN ?

Let's start with that.
As i mentioned we would be more than happy to work with you on those areas
and put more clarity behind those items.

Nati S.









On Wed, May 10, 2017 at 9:03 AM Michael Brenner 
wrote:

> Huabing,
>
> I recognize the need in ONAP to support delegation in TOSCA to external
> workflow engines. I have said this repeatedly, and still am
> miss-interpreted.
> This has nothing to do with backward compatibility to TOSCA 1.0, it only
> has to do with supporting "facts on the ground/existing implementations".
> We should get this agreed once for all, and it became obvious in ONAP's
> Friday modeling discussion.
>
> It also became clear that some of these "facts-on-the-ground" use TOSCA in
> a limited way. This is OK, and I have no issue with that. I can support in
> TOSCA TC to find the right mechanism to delegate externally, but only if we
> do it in a way that is complete: that means we need to not only specify how
> to "get out of TOSCA" but also has to include how to "get back to TOSCA",
> and "what is the TOSCA orchestrator supposed to do after it delegates
> externally". I suggest we work jointly to resolve these issues.
>
> Further, your claim that I am the only one opposing the half-way solution
> on the table is incorrect, and you know it. Luc Boutier in the TOSCA TC is
> also vehemently opposed, and partly at least for the same reasons as those
> quoted by me.
>
> It would be great if we stop making unfounded claims in one community, by
> quoting only partially what happens in another community, and it would be
> better to focus joint energy to resolve the issue in a consistent and
> complete technical manner in the TOSCA TC. Please realize that you
> absolutely CANNOT resolve TOSCA TC discussions/debates in the ONAP
> community alone, and this is not the appropriate way for you to convince me
> to drop my opposition in TOSCA TC.
> The right way to have me support this is by resolving the technical issues
> that I raised.
>
> Best regards,
> Michael
>
> On Wed, May 10, 2017 at 3:16 AM,  wrote:
>
>> Hi Amir and all,
>>
>> Both OPEN-O and OpenECOMP have used TOSCA for service topology modelling
>> and BPMN/BPEL for lifecycle management process modelling. After the merger,
>> ONAP will 

[onap-tsc] Project Proposal: Multi VIM/Cloud

[Danny Lin]

Dear TSC,

I would like to formally propose “Multi VIM/Cloud” project for your approval.

Project: Multi VIM/Cloud --  
https://wiki.onap.org/pages/viewpage.action?pageId=3247262

Project Description:  ONAP needs underlying virtualized infrastructure to 
deploy, run, and manage network services and VNFs. The service provider looks 
for flexibility in its choice of on-premise private cloud, public cloud, or 
hybrid cloud implementations, and related network backends. This project aims 
to enable ONAP to support multiple infrastructure environments, for example, 
OpenStack and its different distributions, public and private clouds (e.g., 
VMware, Azure), and micro services containers, etc.

Currently, we have committers and contributors from VMware, Wind River, 
Microsoft, AT, China Mobile, Huawei, Amdocs, and Intel. Please kindly review 
and comment!

Regards,

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

[onap-tsc] Project Proposal for Network Function Change Management.

[MAVROGIORGIS, EMMANUIL (EMMANUIL)]

Hello Committee Members,



I would like to submit a project proposal for a project focusing on Change 
Management for NF's in ONAP.

Details for this proposal can be found in:



https://wiki.onap.org/display/DW/Network+Function+Change+Management+Project+Proposal





Thanks,



Emmanouil Mavrogiorgis (emau...@research.att.com)

Senior Inventive Scientist

Networking and SQM Research

AT Research

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

Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on Containers

[RATH, CHRISTOPHER A (CHRISTOPHER A)]

In the proposal we are putting together, OOM and DCAE, and other components as 
well, would use the "Common Controller Framework", which is a separate project, 
to unify the common aspects of deployment and management of both the ONAP 
platform components and the services that run on the ONAP platform.  This 
common framework supports orchestration and deployment of Docker containers as 
well as VMs.  DCAE adds in support for orchestration and deployment of 
CDAP-based micro-services; if there is a need for this for other ONAP 
components we could move that functionality up into the common framework 
instead.

The service discovery aspect is part of our proposal for the common controller 
framework as well, but does not appear to have made it into the description or 
scope.  I will see if I can amend that.

Given that, are there are parts of the Microservices Framework that you believe 
are missing either from the Common Controller Framework, the OOM, or DCAE?

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

-Original Message-
From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Yunxia Chen
Sent: Wednesday, May 10, 2017 7:21 PM
To: SPATSCHECK, OLIVER (OLIVER) ; Sauvageau, David 

Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on 
Containers

As I understand correctly:

First of all, from its functionality, Microservices Framework focus on helping 
project which uses microservices to easier manage their services, including 
register/discover, etc. through its services bus; it is the content, and where 
it will be installed, is out of its scope. And OOM focus on where it will be 
installed, (from theory, it could be packed in a VM or a container), but OOM 
chose docker. 



Secondly from its distribution, Microservices Framework is part of ONAP itself; 
while OOM will be distributed as tools for ONAP, just as some tools which will 
be distributed from Integration project.



Regards,

 

Helen Chen



On 5/10/17, 1:23 PM, "SPATSCHECK, OLIVER  (OLIVER)"  
wrote:





One more question. I am wondering what the relationship of the Microservice 
Framework 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Microservices-2BFramework=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=mSWkj6dIUv40CROVujozu_XlxP5keHDQDHDFr5pdK8c=ta0eJwzXHYREmdpXE_-Wkst1klIkdFUqJylouhm9-TU=On73pBcb9b16x4lujJPm29psASYcf_3L2pq7QteF-jg=
 ) and below is.  



Below says:



>> The OOM addresses the current lack of consistent platform-wide method in 
managing software components, their health, resiliency and other lifecycle 
management functions.



the Microservice Framework proposal says:



>>Standardize ONAP platform Microservies concepts & principles and provide 
key framework



it seems the Microservice Framework is a subset of the the Operations 
Manager and container proposal in scope.



Am I interpreting this correctly?



Thx



Oliver



> On May 10, 2017, at 3:35 PM  EDT, Sauvageau, David 
 wrote:

> 

> Oliver – I can move it there. Was not aware thanks

> 

> On 2017-05-10, 3:30 PM, "SPATSCHECK, OLIVER  (OLIVER)" 
 wrote:

> 

> 

>I would assume so otherwise we would have duplication. 

> 

>On an editorial note I thought we were supposed to move the proposal 
links above the project proposal draft line here:

> 

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Proposing-2BA-2BProject=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=KRq5UXk7n766idl0S3NdoJnXVXF7vWo4f17PKdHET6o=
 

> 

>when they are ready for the TSC review period.

> 

>Thx

> 

>Oliver

> 

>> On May 10, 2017, at 3:11 PM  EDT, Yunxia Chen  
wrote:

>> 

>> Hi, David,

>> Could this manager be used for “Distribution” and “Packaging” of ONAP? 
Please refer to:

>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Integration=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=XtcCxrSC2x1iAS_-wkrcO7OCAMRT4JckuzoQHdrNC88=
 

>> 

>> Regards,

>> 

>> Helen Chen

>> 

>> From:  on behalf of "Sauvageau, David" 


>> Date: Wednesday, May 10, 2017 at 11:30 AM

>> To: "onap-tsc@lists.onap.org" 

>> Subject: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on 
Containers

[onap-tsc] Project Proposal for SNIRO (Optimization Framework)

[ISUKAPALLI, SASTRY S (SASTRY)]

Hello Committee Members,

I would like to submit a project proposal for SNIRO (Optimization Framework):

https://wiki.onap.org/display/DW/SNIRO+Optimization+Framework

The SNIRO project (Service, Network, Infrastructure, and Resource Optimization) 
focuses on providing a platform for addressing different optimization (and 
resource allocation) needs and aims to provide "optimization as a service".

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

[onap-tsc] [Modeling]Start Poll Modeling weekly teleconf time

[denghui (L)]

Hello all

Please help to do doodle for our regular weekly teleconf time, we are going to 
close the doodle until this Sunday, EDT 10AM
http://doodle.com/poll/itpu466itrriqerc

Thanks a lot

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

[onap-tsc] Policy Framework Project Proposal

[DRAGOSH, PAMELA L (PAM)]

Hello Committee Members,

I would like to submit the following project proposal:

https://wiki.onap.org/display/DW/Policy+Framework+Project+Proposal

Regards,

Pam

Pamela Dragosh
Lead Inventive Scientist
ONAP Policy
AT Research
pdrag...@research.att.com


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

[onap-tsc] CLAMP project proposal

[Ngueko, Gervais-Martial]

Hello tsc members,

I'am bringing to your attention a new project proposal: "CLAMP", for you to 
approve.
The description page of the project is located at 
https://wiki.onap.org/display/DW/CLAMP

Best Regards,

Gervais-Martial Ngueko
Principal, Application Design
CP - Common Platform & Technology Services
AT Global Network Services Belgium/Luxembourg

"TEXTING and DRIVING... It Can Wait."

AT
Rethink Possible
BUROGEST OFFICE PARK SA
Avenue des Dessus-de-Lives, 2
5101 Loyers (Namur)
M: +32 478 960 529
gn4...@att.com

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

Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN support proposal at OASISTOSCA WG

[zhao.huabing]

Hi Michael,




I brought this issue here only because the proposal has a strong relationship 
to the ONAP community.




In the OASIS TOSCA meeting and maillist, I have repeatedly clarified that our 
proposal only adds an option for the backward-compatible with TOSCA 1.0 to 
allow reusing the tremendous existing codes of OpenECOMP and OPEN-O, it doesn't 
intend to replace the new workflow DSL defined in TOSCA v1.1, and we also 
acknowledge the vision of TOSCA declarative workflow. 




TOSCA TSC Chair Matt also agree on this approach, here is what he said: “I 
thought we had resolved going forward to acknowledge BPMN and BPEL (by name) as 
popular examples of opaque ("Black box" artifact) work flow languages and list 
all the issues/problems/caveats around using them in conjunction within a 
declarative topology (for the Orchestrator and portability).  To be clear, we 
would not endorse them as normative, but neither would we reject them and 
follow our philosophy of "meeting customer where they are at in their 
(declarative) journey that is, not leave them behind, ignore them or force them 
to choose to rewrite to TOSCA or leave.”




If BPMN/BPEL is not included in the TOSCA, we must either abandon the existing 
codes, or extend the TOSCA spec in a non-standard way to support this.  We hope 
that the opensource and standard can cooperate and codevelop in a harmonized 
way in the journey to it's ideally destination, that's why we submit this 
proposal to OASIS TOSCA. 




Here is the main idea of the proposal: it suggests an inclusive approach for 
workflow definition: While the user can define each step of the imperative 
workflow, the workflow can also be delegated to an arbitrary artifact, which 
could be BPMN, BPEL or any other implementations which make sense.




To achieve that, the proposal suggest adding a “delegate” keyname at the 
workflow level to signal that the workflow is delegated to an artifact 
implementation. The value of “delegate” keyname is the relative path of the 
artifact file in the CSAR package which the tosca template is in. During the 
runtime, the orchestrator is responsible for instantiating the corresponding 
artifact processor and hand over the workflow to it.




artifact_types: 

  tosca.artifacts.Implementation.BPMN:

derived_from: tosca.artifacts.Implementation

description: Script artifact for the BPMN workflow

mime_type: application/bpmn+xml

file_ext: [ bpmn ]  



topology_template:

  workflows:

update:

  description: A BPMN workflow to update the network service

  delegate: plan/update.bpmn




This approach is similar to the plan defined in TOSCA V1.0




＜Plans＞ 

＜Plan id="UpdateApplication" 

planType="http://www.example.com/UpdatePlan; 

planLanguage="http://www.omg.org/spec/BPMN/20100524/MODEL"＞ 

  ＜PlanModelReference reference="plans:UpdateApp"/＞ 

   ＜/Plan＞ 

＜/Plans＞ 




Given the intention of this proposal which is detailed described above, I don't 
understand why you keep pushing it back .





Thanks,

Huabing



Original Mail



Sender:  ＜mich...@gigaspaces.com＞
To: zhaohuabing10201488
CC:  ＜a...@gigaspaces.com＞ ＜onap-disc...@lists.onap.org＞ 
＜onap-tsc@lists.onap.org＞
Date: 2017/05/10 21:03
Subject: Re: [onap-discuss] [modeling] TOSCA BPMN support proposal at 
OASISTOSCA WG






Huabing,
I recognize the need in ONAP to support delegation in TOSCA to external 
workflow engines. I have said this repeatedly, and still am miss-interpreted.
This has nothing to do with backward compatibility to TOSCA 1.0, it only has to 
do with supporting "facts on the ground/existing implementations". We should 
get this agreed once for all, and it became obvious in ONAP's Friday modeling 
discussion.

It also became clear that some of these "facts-on-the-ground" use TOSCA in a 
limited way. This is OK, and I have no issue with that. I can support in TOSCA 
TC to find the right mechanism to delegate externally, but only if we do it in 
a way that is complete: that means we need to not only specify how to "get out 
of TOSCA" but also has to include how to "get back to TOSCA", and "what is the 
TOSCA orchestrator supposed to do after it delegates externally". I suggest we 
work jointly to resolve these issues.

Further, your claim that I am the only one opposing the half-way solution on 
the table is incorrect, and you know it. Luc Boutier in the TOSCA TC is also 
vehemently opposed, and partly at least for the same reasons as those quoted by 
me.

It would be great if we stop making unfounded claims in one community, by 
quoting only partially what happens in another community, and it would be 
better to focus joint energy to resolve the issue in a consistent and complete 
technical manner in the TOSCA TC. Please realize that you absolutely CANNOT 
resolve TOSCA TC discussions/debates in the ONAP community alone, and this is 
not the appropriate way for you to convince me to drop my opposition in