date:20170510

Re: [onap-tsc] Proposal for structuring Modeling projects

2017-05-10 Thread GILBERT, MAZIN E (MAZIN E)

Jason

The VNF-SDK and ICE teams are in discussion of a merger and a consolidated plan 
with co-leadership.At least that is my expectation and hope.
CLAMP is for control loop automation. The development and design of templates 
that drive control loops can be part of SDC, including initial orchestration of 
the loop and policy definitions.
However, you need a runtime configuration environment (portal) that enable 
configuration and updates of policies, etc.

Let’s make sure we are not mixing design from run-time.

Mazin

On May 10, 2017, at 1:38 PM, Jason Hunt 
> wrote:

Andrei,

Thank you for bringing this topic up.  It's important that we minimize overlap 
in projects to maximize the impact of the contributors.

In my basic understanding, VNF-SDK and ICE have substantial overlap.  Can we 
investigate how these two projects can merge?

As for CLAMP and Policy Framework, it seems that they both would contribute 
design tools into SDC.  As I understand it, SDC should be able to support the 
design of all the elements that make up a VNF package (including workflows, 
analytics microservices, directed graphs for controllers, policies, etc.)  I 
would expect that each project that requires a design element would create that 
design element themselves and plug that into SDC... rather than the SDC project 
trying to design everything. For example, today directed graphs in the 
controllers are built directly in the Node-RED tooling in the controller, but 
this should in the future be accessible via SDC.  Is that your understanding?

I welcome others' input on this.

Thanks!

Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt

- Original message -
From: Andrei Kojukhov 
>
Sent by: onap-tsc-boun...@lists.onap.org
To: onap-discuss 
>, 
"onap-tsc@lists.onap.org" 
>
Cc:
Subject: [onap-tsc] Proposal for structuring Modeling projects
Date: Wed, May 10, 2017 9:46 AM

Dear all,

Currently there are 6 draft projects in ONAP that deal with modeling, 
onboarding and certification. The below table summarizes the 6 initiatives and 
presents the feature coverage of each one of them.

ONAP Project

Features covered by the project

VNF/Service Design

VNF Guidelines

VNF Certification

VNFD/VNF package onboard

Modeling – overall modeling issues

V

Incubation and Certification Entity (ICE)

V

V

V

Service Design and Create (SDC)

v

V

V

V

VNF-SDK

V

V

V

CLAMP

V

Policy Framework

V

Besides an overlap in content and resources allocation of contributors, my 
expectation is that there will be issues with synchronization of requirements 
such as VNF guidelines and requirements derived from Use cases as well as 
maintaining open source.

Therefore, I’m proposing to consider structuring the above described ONAP 
projects. One of possible umbrella projects may be SDC covering most if not all 
the design and onboarding related features.

The Service Design and Create can be seen as one candidate as unified platform 
for

· Validation and verification of VNF guidelines,

· VNF/Service Design studio

· Standard VNFD/VNF package onboarding platform based on ETSI NFV 
SOL001, SOL004 specifications leveraging TOSCA YAML modeling and CSAR packaging

· Multilayered VNF Certification including VNF package integrity and 
authenticity validation, VNF deployment and running VNF tests verifying 
non-functional VNF KPI’s that are currently specified in ETSI NFV EVE011 work,

There may be different options of structuring all or part of the ONAP 
initiatives as shown in the following pictures.

Option 1: SDC umbrella

Option 2: “Design Automation” umbrella including on-boarding and certification

Option 3: “Design Automation” umbrella excluding on-boarding and certification

I would like to invite ONAP community members to provide their view on possible 
structuring.

BR,

Andrei

Andrei Kojukhov, PhD

Open Network Division

Amdocs Technology

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

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

2017-05-10 Thread Yunxia Chen

Hi, Oliver,
Please see comments inline.

Regards,

Helen Chen

From: "SPATSCHECK, OLIVER" 
Date: Wednesday, May 10, 2017 at 7:01 PM
To: "zhao.huab...@zte.com.cn" 
Cc: Helen Chen 00725961 , "onap-tsc@lists.onap.org" 

Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP 
onContainers

I guess where I was getting confused is who is managing the micro services 
themselves. E.g. DCAE uses micro services. The micro services in DCAE are 
managed by the DCAE controller in terms of life cycle management (turning up 
the micro services, monitoring the health of the micro service, turning down 
the micro service). In this case the DCAE controller also partially handles 
service discovery. My understanding was that the OOM will handle those tasks 
going forward in a unified way.
[HELEN] I think it is “Microservice Framework” been positioned to eventually 
provide a “unified way” to handle that, including doing the refactorying for 
DCAE in the future. OOM manages it through “Microservice Framework” (whatever 
it will be called).

So let me see if I am getting this straight now.  Is the following statement 
true?

If I have a micro service within ONAP the OOM manages:

- turn up
- faults
- turn down
- auto scaling
[HELEN] My understanding is that OOM doesn’t manage on micro service level. In 
OOM’s diagram about “Service & config registry” is not micro service. (Maybe I 
am wrong, let them clarify it).

the micro service framework manages

- service registration
- service discovery
- service load balaning

Do both teams agree to this separation?

If that is the case I agree that they are separate tasks and that the term 
micro service framework is very misleading as I would have thought a framework 
also handled turn up, faults, turn down and auto scaling.  Maybe we should go 
back to micro service bus then.

Those projects are obviously still closely related though. E.g. if you turn up 
a micro service (as the OOM would do) you have to let the micro service bus 
know about it (e.g. register it).
[HELEN] Agree. They are very close to each other.

Helen,

I am not sure I understand the difference between a component of ONAP and a 
tool. For the OOM to manage the above life cycle events of micro services and 
other components in ONAP it has to be running at the same operational level as 
any other ONAP component does.  So it’s not just a “script” you run once. It’s 
a component.   It just doesn’t directly interact with VNFs but that doesn’t 
make it less important.
[HELEN] What I mean is that a component of ONAP is without it, ONAP is not 
complete, while tool is that without it, ONAP is still fully function. (They 
all equally important).  It may run at the same operational level or may not. 
OOM manages ONAP through ONAP’s API, or installs a proxy/agent, or using 
Kubernetes to manage the container where those ONAP components run inside if 
they use container (some of them use VM).
My 2 cents. ☺

Thx

Oliver

On May 10, 2017, at 8:55 PM, 
zhao.huab...@zte.com.cn wrote:

What Helen said is correct.

During the project proposal discussion in the last week, people suggest use 
"Microservice Framework " instead of "Microservice Bus", that might be the 
reason of this confusion.
"Microservice Framework" or "Microservice Bus" provides a platform to enable 
service registration/discovery, service request routing, service load balancing 
for the services.

From the project description of OOM(ONAP Operations Manager), OOM intends to 
Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, 
SDC, etc.) and infrastructure (VMs, Containers).

So the scopes of these two project obviously have no any overlapping.

Thanks,
Huabing
Original Mail
Sender:  ＜helen.c...@huawei.com＞;
To:  ＜spat...@research.att.com＞; 
＜david.sauvag...@bell.ca＞;
CC:  ＜onap-tsc@lists.onap.org＞;
Date: 2017/05/11 07:21
Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP 
onContainers

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)"

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

2017-05-10 Thread SPATSCHECK, OLIVER (OLIVER)


I guess where I was getting confused is who is managing the micro services 
themselves. E.g. DCAE uses micro services. The micro services in DCAE are 
managed by the DCAE controller in terms of life cycle management (turning up 
the micro services, monitoring the health of the micro service, turning down 
the micro service). In this case the DCAE controller also partially handles 
service discovery. My understanding was that the OOM will handle those tasks 
going forward in a unified way.

So let me see if I am getting this straight now.  Is the following statement 
true?

If I have a micro service within ONAP the OOM manages:

- turn up
- faults
- turn down
- auto scaling

the micro service framework manages

- service registration
- service discovery
- service load balaning

Do both teams agree to this separation?

If that is the case I agree that they are separate tasks and that the term 
micro service framework is very misleading as I would have thought a framework 
also handled turn up, faults, turn down and auto scaling.  Maybe we should go 
back to micro service bus then.

Those projects are obviously still closely related though. E.g. if you turn up 
a micro service (as the OOM would do) you have to let the micro service bus 
know about it (e.g. register it).

Helen,

I am not sure I understand the difference between a component of ONAP and a 
tool. For the OOM to manage the above life cycle events of micro services and 
other components in ONAP it has to be running at the same operational level as 
any other ONAP component does.  So it’s not just a “script” you run once. It’s 
a component.   It just doesn’t directly interact with VNFs but that doesn’t 
make it less important.

Thx

Oliver


On May 10, 2017, at 8:55 PM, 
zhao.huab...@zte.com.cn wrote:


What Helen said is correct.


During the project proposal discussion in the last week, people suggest use 
"Microservice Framework " instead of "Microservice Bus", that might be the 
reason of this confusion.

"Microservice Framework" or "Microservice Bus" provides a platform to enable 
service registration/discovery, service request routing, service load balancing 
for the services.


From the project description of OOM(ONAP Operations Manager), OOM intends to 
Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, 
SDC, etc.) and infrastructure (VMs, Containers).


So the scopes of these two project obviously have no any overlapping.


Thanks,

Huabing

Original Mail
Sender:  ＜helen.c...@huawei.com＞;
To:  ＜spat...@research.att.com＞; 
＜david.sauvag...@bell.ca＞;
CC:  ＜onap-tsc@lists.onap.org＞;
Date: 2017/05/11 07:21
Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP 
onContainers


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)" 
＜spat...@research.att.com＞ wrote:


One more question. I am wondering what the relationship of the Microservice 
Framework (https://wiki.onap.org/display/DW/Microservices+Framework) 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 
＜david.sauvag...@bell.ca＞ 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:
＞
＞

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

2017-05-10 Thread zhao.huabing

What Helen said is correct.




During the project proposal discussion in the last week, people suggest use 
"Microservice Framework " instead of "Microservice Bus", that might be the 
reason of this confusion.

"Microservice Framework" or "Microservice Bus" provides a platform to enable 
service registration/discovery, service request routing, service load balancing 
for the services.




From the project description of OOM(ONAP Operations Manager), OOM intends to 
Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, 
SDC, etc.) and infrastructure (VMs, Containers). 




So the scopes of these two project obviously have no any overlapping.




Thanks,

Huabing



Original Mail



Sender:  ＜helen.c...@huawei.com＞
To:  ＜spat...@research.att.com＞ ＜david.sauvag...@bell.ca＞
CC:  ＜onap-tsc@lists.onap.org＞
Date: 2017/05/11 07:21
Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP 
onContainers





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)" ＜spat...@research.att.com＞ 
wrote:


One more question. I am wondering what the relationship of the Microservice 
Framework (https://wiki.onap.org/display/DW/Microservices+Framework) 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 
＜david.sauvag...@bell.ca＞ 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://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 ＜helen.c...@huawei.com＞ 
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: ＜onap-tsc-boun...@lists.onap.org＞ on behalf of "Sauvageau, David" 
＜david.sauvag...@bell.ca＞
＞＞ Date: Wednesday, May 10, 2017 at 11:30 AM
＞＞ To: "onap-tsc@lists.onap.org" ＜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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BOperations-2BManager=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=JKrpL9bPGtCjFYFOQv1RHpooQ1UEvvb5Sqbl3r_-TTY=
 
＞＞ 
＞＞ 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

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

2017-05-10 Thread Yunxia Chen

That’s great! Let’s getting in sync on the schedule for these two projects once 
they are approved by TSC. Integration project would like to leverage OAM’s 
capabilities for distribution, packaging and lab deployment as well.

Regards,

Helen Chen

From: "Sauvageau, David" 
Date: Wednesday, May 10, 2017 at 12:34 PM
To: Helen Chen 00725961 , "onap-tsc@lists.onap.org" 

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

Hi Helen

I believe so. We are basically positioning the project to enable flexible 
deployment and operations of the ONAP platform components and infrastructure – 
initially but not limited to using containers. It will be providing all the OAM 
capabilities for the platform components (i.e. how to deploy and operate ONAP 
as a platform).

There were other names in the past for this project such as “ONAP controller” 
or “OAM”.

From: Yunxia Chen 
Date: Wednesday, May 10, 2017 at 3:11 PM
To: "Sauvageau, David" , "onap-tsc@lists.onap.org" 

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

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://lists.onap.org/mailman/listinfo/onap-tsc

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

2017-05-10 Thread Don Clarke

I agree with Alla - an SME with detailed knowledge and well known in the target 
external organization is highly desirable as coordinator for ONAP. I have an 
excellent candidate in mind for ETSI NFV.

BTW - ETSI NFV and ETSI MEC are separate bodies. Although several great people 
I know are involved in both.

Regards,
Don Clarke.

On May 10, 2017, at 15:05, Alla Goldner 
> wrote:

Hi all,

A different way to handle this topic is to assign person responsible for each 
SDO/Open source coordination, same as ETSI NFV have.
To me, it makes more sense, as eventually only subject expert knows which 
topics are discussed in the corresponding SDO/Open Source and how to handle 
them in the best possible way, and not a single coordinator assigned per all 
SDO and/or Open Source projects.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Jason Hunt
Sent: Wednesday, May 10, 2017 10:07 PM
To: ma...@research.att.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Creation Request for Coordination Area Standard/SDO

Mazin,

Understood.  I see that Lingli also proposed a separate open source 
coordinator.  Good discussion for tomorrow.

Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt

- Original message -
From: "GILBERT, MAZIN E (MAZIN E)" 
>
To: Jason Hunt >
Cc: "denglin...@chinamobile.com" 
>, 
"onap-tsc@lists.onap.org" 
>
Subject: Re: [onap-tsc] Creation Request for Coordination Area Standard/SDO
Date: Wed, May 10, 2017 1:58 PM

Jason

The coordinator we use to interact with SDO may need to be different than that 
for other
open source projects. There are short term impacts of our first release on 
other open source projects
like OPNFV, FD.io and Open Stack, etc.

Let’s discuss tomorrow in our TSC meeting. As of now, we have not approved any 
coordinators except security.
I also need to check with the governance board whether we need any direction 
when interacting
with SDO.

Mazin

On May 10, 2017, at 1:00 PM, Jason Hunt 
> wrote:

Good proposal.  Would this coordinator also work with other open source 
projects?  I'm thinking, in particular, of OPNFV where I think we could have a 
tight collaboration.

Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt

- Original message -
From: 邓灵莉 >
Sent by: onap-tsc-boun...@lists.onap.org
To: onap-tsc >
Cc:
Subject: [onap-tsc] Creation Request for Coordination Area Standard/SDO
Date: Wed, May 10, 2017 10:18 AM

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/邓灵莉

中国移动通信研究院

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

2017-05-10 Thread SPATSCHECK, OLIVER (OLIVER)


One more question. I am wondering what the relationship of the Microservice 
Framework (https://wiki.onap.org/display/DW/Microservices+Framework) 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
>> 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BOperations-2BManager=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=JKrpL9bPGtCjFYFOQv1RHpooQ1UEvvb5Sqbl3r_-TTY=
>>  
>> 
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D3247305=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=JpUYmrsZsg6RjZKDiep2Pih0JSdBKmoI6wxVFzvDVWA=
>>  
>> 
>> 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.
>>  •

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

2017-05-10 Thread Alla Goldner

Hi all,

A different way to handle this topic is to assign person responsible for each 
SDO/Open source coordination, same as ETSI NFV have.
To me, it makes more sense, as eventually only subject expert knows which 
topics are discussed in the corresponding SDO/Open Source and how to handle 
them in the best possible way, and not a single coordinator assigned per all 
SDO and/or Open Source projects.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology

[cid:image001.png@01D2C9E1.EAFE88E0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Jason Hunt
Sent: Wednesday, May 10, 2017 10:07 PM
To: ma...@research.att.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Creation Request for Coordination Area Standard/SDO

Mazin,

Understood.  I see that Lingli also proposed a separate open source 
coordinator.  Good discussion for tomorrow.

Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt

- Original message -
From: "GILBERT, MAZIN E (MAZIN E)" 
>
To: Jason Hunt >
Cc: "denglin...@chinamobile.com" 
>, 
"onap-tsc@lists.onap.org" 
>
Subject: Re: [onap-tsc] Creation Request for Coordination Area Standard/SDO
Date: Wed, May 10, 2017 1:58 PM

Jason

The coordinator we use to interact with SDO may need to be different than that 
for other
open source projects. There are short term impacts of our first release on 
other open source projects
like OPNFV, FD.io and Open Stack, etc.

Let’s discuss tomorrow in our TSC meeting. As of now, we have not approved any 
coordinators except security.
I also need to check with the governance board whether we need any direction 
when interacting
with SDO.

Mazin

On May 10, 2017, at 1:00 PM, Jason Hunt 
> wrote:

Good proposal.  Would this coordinator also work with other open source 
projects?  I'm thinking, in particular, of OPNFV where I think we could have a 
tight collaboration.

Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt

- Original message -
From: 邓灵莉 >
Sent by: onap-tsc-boun...@lists.onap.org
To: onap-tsc >
Cc:
Subject: [onap-tsc] Creation Request for Coordination Area Standard/SDO
Date: Wed, May 10, 2017 10:18 AM

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

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

___
ONAP-TSC mailing list

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

2017-05-10 Thread 邓灵莉

Hi Phil,

 

I agree with the approach and your interpretation.

 

There is an optional field for coordinator follow the instruction as documented 
in the charter for coordination area creation request in Section 5.1.4.3. And 
it also references an election process for coordinators in Section 5.2.2.2 and 
5.2.2.4.
 
I put the names in the creation request, because they already approach me with 
formal self-nomination.
 

Lingli/邓灵莉中国移动通信研究院denglin...@chinamobile.com
 

 ---Forwarded Message---

 

Hi Lingli:

 

Thanks very much for the Coordinator role proposal.

 

I have added this to the "Technical Community Coordinator" wiki page here: 
https://wiki.onap.org/display/DW/Technical+Community+Coordinators 

 

...and to the agenda for tomorrow39s TSC meeting.

 

I believe we should first have the TSC vote to approve this Coordinator role, 
and if/when that occurs we will then need to solicit individuals to 
self-nominate for the position and have the TSC vote to approve the person in 
that role.

 

TSC members, please let me know if you feel I am interpreting the Charter 
incorrectly on the process to establish Coordinator positions.

 

Best,

 

Phil.

 

On Wed, May 10, 2017 at 11:18 AM, 邓灵莉  wrote:

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

 


 ___ 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

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

2017-05-10 Thread Yunxia Chen

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://lists.onap.org/mailman/listinfo/onap-tsc

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

2017-05-10 Thread Sauvageau, David

Deer 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.




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

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

2017-05-10 Thread Jason Hunt

Mazin,
Understood. I see that Lingli also proposed a separate open source coordinator. Good discussion for tomorrow.
Regards,Jason HuntExecutive Software Architect, IBMPhone: +1-314-749-7422Email: djh...@us.ibm.comTwitter: @DJHunt
- Original message -From: "GILBERT, MAZIN E (MAZIN E)" To: Jason Hunt Cc: "denglin...@chinamobile.com" , "onap-tsc@lists.onap.org" Subject: Re: [onap-tsc] Creation Request for Coordination Area Standard/SDODate: Wed, May 10, 2017 1:58 PM Jason
The coordinator we use to interact with SDO may need to be different than that for other
open source projects. There are short term impacts of our first release on other open source projects
like OPNFV, FD.io and Open Stack, etc.
Let’s discuss tomorrow in our TSC meeting. As of now, we have not approved any coordinators except security.
I also need to check with the governance board whether we need any direction when interacting
with SDO.
Mazin

On May 10, 2017, at 1:00 PM, Jason Hunt wrote:

Good proposal. Would this coordinator also work with other open source projects? I'm thinking, in particular, of OPNFV where I think we could have a tight collaboration.
Regards,Jason HuntExecutive Software Architect, IBMPhone: +1-314-749-7422Email: djh...@us.ibm.comTwitter: @DJHunt
- Original message -From: 邓灵莉 Sent by: onap-tsc-boun...@lists.onap.orgTo: onap-tsc Cc:Subject: [onap-tsc] Creation Request for Coordination Area Standard/SDODate: Wed, May 10, 2017 10:18 AM
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
___ONAP-TSC mailing listONAP-TSC@lists.onap.orghttps://lists.onap.org/mailman/listinfo/onap-tsc
___ONAP-TSC mailing listONAP-TSC@lists.onap.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=XKUn57AaVgxzq3DD1RTnV7afF26cgZR5_nI143MWmGM=bWL0RMcjKp6RDJ1PBIpJOZ6p_uVFkinvFqtdPhcTkwU=

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

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

2017-05-10 Thread 邓灵莉

Hi Jason,

 

Recall from the discussion last Thursday TSC meeting, it is suggested to have a 
separate coordinator for opensource communities in addition to SDOs, hence I 
wrote another proposal separately.

 

I apologize not including the potential list of communities in that prposal for 
opensource coordination. And I agree that OPNFV should be on that list, as 
being identified to be relevant to ONAP and need coordination.

 

 

Lingli/邓灵莉中国移动通信研究院denglin...@chinamobile.com



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

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

2017-05-10 Thread GILBERT, MAZIN E (MAZIN E)

Jason

The coordinator we use to interact with SDO may need to be different than that 
for other
open source projects. There are short term impacts of our first release on 
other open source projects
like OPNFV, FD.io and Open Stack, etc.

Let’s discuss tomorrow in our TSC meeting. As of now, we have not approved any 
coordinators except security.
I also need to check with the governance board whether we need any direction 
when interacting
with SDO.

Mazin




On May 10, 2017, at 1:00 PM, Jason Hunt 
> wrote:


Good proposal.  Would this coordinator also work with other open source 
projects?  I'm thinking, in particular, of OPNFV where I think we could have a 
tight collaboration.


Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt


- Original message -
From: 邓灵莉 >
Sent by: onap-tsc-boun...@lists.onap.org
To: onap-tsc >
Cc:
Subject: [onap-tsc] Creation Request for Coordination Area Standard/SDO
Date: Wed, May 10, 2017 10:18 AM

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

___
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=XKUn57AaVgxzq3DD1RTnV7afF26cgZR5_nI143MWmGM=bWL0RMcjKp6RDJ1PBIpJOZ6p_uVFkinvFqtdPhcTkwU=

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

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

2017-05-10 Thread Sauvageau, David

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://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal for structuring Modeling projects

2017-05-10 Thread Jason Hunt

 
Andrei,
 
Thank you for bringing this topic up.  It's important that we minimize overlap in projects to maximize the impact of the contributors.
 
In my basic understanding, VNF-SDK and ICE have substantial overlap.  Can we investigate how these two projects can merge?
 
As for CLAMP and Policy Framework, it seems that they both would contribute design tools into SDC.  As I understand it, SDC should be able to support the design of all the elements that make up a VNF package (including workflows, analytics microservices, directed graphs for controllers, policies, etc.)  I would expect that each project that requires a design element would create that design element themselves and plug that into SDC... rather than the SDC project trying to design everything. For example, today directed graphs in the controllers are built directly in the Node-RED tooling in the controller, but this should in the future be accessible via SDC.  Is that your understanding?
 
I welcome others' input on this.
 
Thanks!Regards,Jason HuntExecutive Software Architect, IBMPhone: +1-314-749-7422Email: djh...@us.ibm.comTwitter: @DJHunt
 
 
- Original message -From: Andrei Kojukhov Sent by: onap-tsc-boun...@lists.onap.orgTo: onap-discuss , "onap-tsc@lists.onap.org" Cc:Subject: [onap-tsc] Proposal for structuring Modeling projectsDate: Wed, May 10, 2017 9:46 AM  
Dear all,
 
Currently there are 6 draft projects in ONAP that deal with modeling, onboarding and certification. The below table summarizes the 6 initiatives and presents the feature coverage of each one of them.
 
 
ONAP ProjectFeatures covered by the projectVNF/Service DesignVNF GuidelinesVNF CertificationVNFD/VNF package onboardModeling – overall modeling issuesV   Incubation and Certification Entity (ICE) VVVService Design and Create (SDC)vV VVVNF-SDK VVVCLAMPV   Policy FrameworkV   
 
 
Besides an overlap in content and resources allocation of contributors, my expectation is that there will be issues with synchronization of requirements such as VNF guidelines and requirements derived from Use cases as well as maintaining

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

2017-05-10 Thread Jason Hunt

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

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

2017-05-10 Thread 邓灵莉

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 


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

[onap-tsc] Proposal for structuring Modeling projects

2017-05-10 Thread Andrei Kojukhov

Dear all,

Currently there are 6 draft projects in ONAP that deal with modeling, 
onboarding and certification. The below table summarizes the 6 initiatives and 
presents the feature coverage of each one of them.


ONAP Project

Features covered by the project

VNF/Service Design

VNF Guidelines

VNF Certification

VNFD/VNF package onboard

Modeling - overall modeling issues

V







Incubation and Certification Entity (ICE)



V

V

V

Service Design and Create (SDC)

v

V

V

V

VNF-SDK

V

V

V

CLAMP

V







Policy Framework

V









Besides an overlap in content and resources allocation of contributors, my 
expectation is that there will be issues with synchronization of requirements 
such as VNF guidelines and requirements derived from Use cases as well as 
maintaining open source.
Therefore, I'm proposing to consider structuring the above described ONAP 
projects. One of possible umbrella projects may be SDC covering most if not all 
the design and onboarding related features.

The Service Design and Create can be seen as one candidate as unified platform 
for

* Validation and verification of VNF guidelines,

* VNF/Service Design studio

* Standard VNFD/VNF package onboarding platform based on ETSI NFV 
SOL001, SOL004 specifications leveraging TOSCA YAML modeling and CSAR packaging

* Multilayered VNF Certification including VNF package integrity and 
authenticity validation, VNF deployment and running VNF tests verifying 
non-functional VNF KPI's that are currently specified in ETSI NFV EVE011 work,
There may be different options of structuring all or part of the ONAP 
initiatives as shown in the following pictures.

Option 1: SDC umbrella
[cid:image007.png@01D2C9B5.447E30F0]


Option 2: "Design Automation" umbrella including on-boarding and certification
[cid:image008.png@01D2C9B5.447E30F0]


Option 3: "Design Automation" umbrella excluding on-boarding and certification
[cid:image009.png@01D2C9B5.447E30F0]


I would like to invite ONAP community members to provide their view on possible 
structuring.


BR,

Andrei



Andrei Kojukhov, PhD

Open Network Division
Amdocs Technology


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




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] [onap-discuss] [modeling] TOSCA BPMN support proposal at OASIS TOSCA WG

2017-05-10 Thread Michael Brenner

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 inherit the existing codes from OPEN-O and OpenECOMP and continue
> to use BPMN/BPEL in SO/VF-C.
>
> However, I noticed that TOSCA has removed the support for BPMN/BPEL in
> v1.1[1] which is recommended in the Topology and Orchestration
> Specification for Cloud Applications Version 1.0[2].
>
> This incompatible change of TOSCA specification may cause unpredictable
> effects to existing opensource projects, in particular, the ONAP, which
> have already adopted BPMN as its lifecycle management process modelling.
>
> To harmonize the opensource and standards, I am co-proposing a proposal[3]
> with Lingli(CMCC), Claude(AT) and Shitaoto(Huawei) to suggest OASIS TOSCA
> revert standard workflow DSLs support such as BPMN/BPEL in the next version
> of simple YAML specification.
>
> 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.
>
> I think this proposal is for the best interest of ONAP community, so I'm
> writing this mail to solicit supports from Gigaspaces and all the other
> community members who are both in ONAP and OASIS TOSCA WG.
>
>
> [1] http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html
>
> [2] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html
>
> [3] https://www.oasis-open.org/apps/org/workgroup/tosca/
> download.php/60604/Issue_TOSCA318_Lack%20of%20BPMN%
> 20BPEL%20support-v-2017-04-25.pptx
>
>
> Thanks,
>
> Huabing
>
>
>
> ___
> onap-discuss mailing list
> onap-disc...@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>

-- 
Michael Brenner, Chief Architect NFV
--
M: +1-732-895-5772 http://getcloudify.org

@cloudifysource

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

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

2017-05-10 Thread Vul, Alex

Hi Huabing, et. al.

The need to specify imperative workflow “callous” from a TOSCA service template 
is pretty well understood, both from the enterprise and the telecom use case 
perspective. In fact, there is already a generic mechanism in TOSCA to support 
invocation and execution of “artifacts”, based on a template declaration. This 
is inclusive of BPMN/BPEL…

As I see it, the only blocker at this time are the issues around the 
call/return contract between the orchestrator execution and the workflow 
execution.

Does the orchestrator block while the workflow is running? What happens if the 
workflow fails, or worse yet, what happens if a workflow processor fails? Does 
the orchestrator block forever, or is there a timeout? How do we clean up the 
leftover mess?

Say the orchestrator does not block… Again, what happens during the invocation 
and failure? Obviously what happens upon workflow execution completion is also 
important.

All of the above was discussed at the last TOSCA Simple YAML Profile meeting 
and action is being taken to document the call/return contracts. It might take 
a bit of time, but we will get there…

TOSCA is a standard that caters to both the enterprise and the telecom use 
cases. All and any TOSCA orchestrators out there will need to support workflow 
“callouts” once they are part of the spec, so “measuring twice and cutting 
once” is pretty important…

Kind regards,

Alex Vul
Intel Corporation
ONAP Member
OASIS TOSCA TC Member


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of zhao.huab...@zte.com.cn
Sent: Wednesday, May 10, 2017 12:17 AM
To: a...@gigaspaces.com
Cc: onap-disc...@lists.onap.org; onap-tsc@lists.onap.org
Subject: [onap-tsc]  [modeling] TOSCA BPMN support proposal at OASIS TOSCA WG


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 inherit the existing codes from OPEN-O and OpenECOMP and continue to use 
BPMN/BPEL in SO/VF-C.

However, I noticed that TOSCA has removed the support for BPMN/BPEL in v1.1[1] 
which is recommended in the Topology and Orchestration Specification for Cloud 
Applications Version 1.0[2].

This incompatible change of TOSCA specification may cause unpredictable effects 
to existing opensource projects, in particular, the ONAP, which have already 
adopted BPMN as its lifecycle management process modelling.

To harmonize the opensource and standards, I am co-proposing a proposal[3] with 
Lingli(CMCC), Claude(AT) and Shitaoto(Huawei) to suggest OASIS TOSCA revert 
standard workflow DSLs support such as BPMN/BPEL in the next version of simple 
YAML specification.

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.

I think this proposal is for the best interest of ONAP community, so I'm 
writing this mail to solicit supports from Gigaspaces and all the other 
community members who are both in ONAP and OASIS TOSCA WG.



[1] 
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html

[2] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html

[3] 
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/60604/Issue_TOSCA318_Lack%20of%20BPMN%20BPEL%20support-v-2017-04-25.pptx



Thanks,

Huabing


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

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

2017-05-10 Thread zhao.huabing

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 inherit the existing codes from OPEN-O and OpenECOMP and continue to use 
BPMN/BPEL in SO/VF-C.


However, I noticed that TOSCA has removed the support for BPMN/BPEL in v1.1[1] 
which is recommended in the Topology and Orchestration Specification for Cloud 
Applications Version 1.0[2].   


This incompatible change of TOSCA specification may cause unpredictable effects 
to existing opensource projects, in particular, the ONAP, which have already 
adopted BPMN as its lifecycle management process modelling.


To harmonize the opensource and standards, I am co-proposing a proposal[3] with 
Lingli(CMCC), Claude(AT) and Shitaoto(Huawei) to suggest OASIS TOSCA revert 
standard workflow DSLs support such as BPMN/BPEL in the next version of simple 
YAML specification. 


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.


I think this proposal is for the best interest of ONAP community, so I'm 
writing this mail to solicit supports from Gigaspaces and all the other 
community members who are both in ONAP and OASIS TOSCA WG.






[1] 
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html


[2] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html


[3] 
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/60604/Issue_TOSCA318_Lack%20of%20BPMN%20BPEL%20support-v-2017-04-25.pptx






Thanks,


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

Re: [onap-tsc] Proposal for structuring Modeling projects

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [onap-tsc] Proposal for structuring Modeling projects

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

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

[onap-tsc] Proposal for structuring Modeling projects

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

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

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

22 matches

Site Navigation

Mail list logo

Footer information