Re: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMNsupportproposal at OASIS TOSCA WG

2017-05-15 Thread Nati Shalom
Hi Huabing

I'l let Michael respond directly to your questions but i wanted to make it
clear that no one in this discussion is suggesting that theres one way to
implement TOSCA orchestration and that it has to be declarative.

The specific questions that were trying to get answered repetitively can be
summarized as follows:

1. What should be the effect on the model after the execution of the
workflow (regardless of the specific language your using to implement the
workflow)

2. If TOSCA workflow is assumed to be "blackbox" from the Orchestrator
perspective why do we need a  specific specification to define BPMN
workflow and not set with the agreeing on the outer interfaces that calls
and return from the workflow?

In general what this discussion illustrates most is the gaps in terminology
and thus communication that we have here which makes the effectiveness of
this continues dialogue over email questionable.

It happens that were hosting a webinar on Thursday the 18  this week ( Model
Driven Orchestration with TOSCA and ARIA
)
in which well discuss some of the topics such as Model Driven architecture,
what we mean by Declarative workflow etc. We will also discuss how you can
map complex IMS workflow with this approach.

I think that it would be a good opportunity if you and everyone on this
thread and list to join and have lively discussion on those topics -
hopefully this could help to bridge some of the terminology gaps that we
seem to have here.

Nati S.


On Tue, May 16, 2017 at 4:47 AM  wrote:

> Hi Michael,
>
>
> "Clearly, you are NOT using the declarative workflow, so then why do you
> care how it is encoded in TOSCA? Only a TOSCA-based orchestrator that
> interprets the declarative intent needs to really interpret TOSCA."
>
>
> You're claiming that some Orchestration implementation is "TOSCA-based
> Orchestrator" and others are not.  And the criteria you're using to tell
> whether an Orchestration implementation is a "TOSCA-based Orchestrator" is
> if the LCM workflow of the orchestrator is declarative(Topology driven).
>
>
> Firstly, the TOSCA Specification doesn't restrict the implementation of
> orchestrator as long as " it can interpret a TOSCA service template or a
> TOSCA CSAR in order to instantiate and deploy the described application in
> a Cloud", no matter the workflow is implemented by Python(Aria is that
> case), BPMN or any other language.
>
> - TOSCA Simple Profile in YAML Version 1.1   1.3 implementation
>
>
> Secondly, TOSCA Specification also think that some complex use cases can't
> be solved by declarative workflow, that's why TOSCA define a new imperative
> workflow language in the V1.1 specification. But the language has some
> limitation. For example, what about long-running processes? Such as
> monitoring the application. What about human tasks? What about complex
> fault handling? What about reversing actions (compensation!)? This is all
> possible with BPEL and BPMN engines.
>
>
> Thirdly, As I have pointed out in my previous mail, the orchestrator
> implementation with BPEL/BPMN(OPEN-O is a good example) can be topology
> driven as well. We can combine declarative and imperative provisioning
> using BPMN/BPEL which can resolve drawbacks and to profit from benefits of
> both worlds. There is an academic paper presents a means to do that, we
> have done similar in OPEN-O.
>
>
> Breitenbücher, Uwe et al.: Combining Declarative and Imperative Cloud
> Application Provisioning based on TOSCA. In: Proceedings of the IEEE
> International Conference on Cloud Engineering (IC2E), 2014.
>
>
> http://www.iaas.uni-stuttgart.de/RUS-data/INPROC-2014-21%20-%20Combining%20Declarative%20and%20Imperative%20Cloud%20Application%20Provisioning%20based%20on%20TOSCA.pdf
>
>
>
> In conclusion, OPEN-O is a "TOSCA-based Orchestrator" which is ETSI MANO
> complied with the ability to allow vendors to bring their VNFs in with VNFM
> and it use Inventory(counterpart of A in OpenECOPM) to storage and
> manipulate the instance model. The Inventory API is called to update the
> instance model in the workflow activities, so this approach do "return to
> the TOSCA". So the request to take alternative workflows such as BPMN/BPEL,
> etc. which had been supported in TOSCA v1.0 back to TOSCA is reasonable.
>
>
> Thanks,
>
> Huabing
> Original Mail
> *Sender: * <mich...@gigaspaces.com>;
> *To: *mengzhaoxing10024238;
> *CC: * <na...@gigaspaces.com>;zhaohuabing10201488; <
> onap-discuss@lists.onap.org>; <onap-...@lists.onap.org>;
> *Date: *2017/05/13 01:08
> *Subject: **Re: Re: [onap-tsc] [onap-discuss] [modeling] TOSCA
> BPMNsupportproposal at OASIS TOSCA WG*
>
>
> Huabing,
> Let me suggest that you can accomplish today everything you are trying to
> accomplish, without additional support in the TOSCA spec. In fact, the
> additional support you are asking is ONLY useful if you use the declarative
> model to 

[onap-discuss] ONAP Confluence maintenance (wiki.onap.org) 2017-05-20 15:00 - 16:00 UTC

2017-05-15 Thread Ryan Finnin Day
What:

  The Linux Foundation will be performing needed maintenance on the
  ONAP Confluence server.

When:

  Saturday, May 20 @ 8:00 - 9:00 PDT (2017-05-20 15:00 - 16:00 UTC)

Why:

  There are security updates available for Confluence.

Impact:

  https://wiki.onap.org will be unavailable during the upgrade.
  Expected downtime is less than 15 minutes, but extra time is
  allotted to the window for contingency work.


Notices will be posted here at the start and end of the maintenance.



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [onap-tsc] Project Proposal: External System Register

2017-05-15 Thread Jacopo Pianigiani
Hi,
I would agree with Steve about the need to limit overlap between subprojects
Jacopo
From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Monday, May 15, 2017 10:10 AM
To: li.z...@zte.com.cn; onap-...@lists.onap.org; onap-discuss@lists.onap.org
Subject: Re: [onap-tsc] Project Proposal: External System Register

Hi,

While I agree with the need of the external elements to be registered, is there 
a reason for why we need a separate register in addition to A? (note: I saw 
that Catherine had a comment with a similar lines).  It may also relate to 
catalogue - LiZi, have you had a chance to chat with the A Project 
(https://wiki.onap.org/pages/viewpage.action?pageId=3246952 ).

Best Regards,

Steve.

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of 
li.z...@zte.com.cn
Sent: 15 May 2017 04:32
To: onap-...@lists.onap.org; 
onap-discuss@lists.onap.org
Subject: [onap-tsc] Project Proposal: External System Register




Dear ONAP TSC,



We would like to formally propose the External System Register project for ONAP.



ONAP components need to talk with external systems such as VIM/VNFM/SDNC/EMS to 
orchestrate a network service, for example, SO/VF-C need to talk with VIM to 
allocate resource and VNFM to deploy a VNF. So they should get the information 
of available external systems from a registry before call the Interfaces of 
these external systems.  ESR provides a service to centralized management of 
the information (name, vendor, version, acess end point, etc.) of external 
systems. So the ONAP components can get the system information with unified API 
from a logical single point.



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/External+System+Register



Thanks,



LiZi









李滋 lizi



IT开发工程师 IT Development Engineer
网管及服务开发二部/中心研究院/系统产品 Network Management & Service Development Dept. II/Central 
R&D Institute/System Product


[cid:image001.gif@01D2CD64.B78D9A60]

[cid:image002.gif@01D2CD64.B78D9A60]
成都市高新区天府大道中段800号中兴通大厦
ZTE Corporation Building, No. 800 Middle Section Tianfu Avenue,
Chengdu, P..R.China, 610041
M: +86 15583405168
E: li.z...@zte.com.cn
www.zte.com.cn


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


Re: [onap-discuss] [onap-tsc] Project Proposal: External System Register

2017-05-15 Thread Stephen Terrill
Hi,

While I agree with the need of the external elements to be registered, is there 
a reason for why we need a separate register in addition to A? (note: I saw 
that Catherine had a comment with a similar lines).  It may also relate to 
catalogue - LiZi, have you had a chance to chat with the A Project 
(https://wiki.onap.org/pages/viewpage.action?pageId=3246952 ).

Best Regards,

Steve.

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of li.z...@zte.com.cn
Sent: 15 May 2017 04:32
To: onap-...@lists.onap.org; onap-discuss@lists.onap.org
Subject: [onap-tsc] Project Proposal: External System Register




Dear ONAP TSC,



We would like to formally propose the External System Register project for ONAP.



ONAP components need to talk with external systems such as VIM/VNFM/SDNC/EMS to 
orchestrate a network service, for example, SO/VF-C need to talk with VIM to 
allocate resource and VNFM to deploy a VNF. So they should get the information 
of available external systems from a registry before call the Interfaces of 
these external systems.  ESR provides a service to centralized management of 
the information (name, vendor, version, acess end point, etc.) of external 
systems. So the ONAP components can get the system information with unified API 
from a logical single point.



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/External+System+Register



Thanks,



LiZi









李滋 lizi



IT开发工程师 IT Development Engineer
网管及服务开发二部/中心研究院/系统产品 Network Management & Service Development Dept. II/Central 
R&D Institute/System Product


[cid:image001.gif@01D2CDAD.FCB40C20]

[cid:image002.gif@01D2CDAD.FCB40C20]
成都市高新区天府大道中段800号中兴通大厦
ZTE Corporation Building, No. 800 Middle Section Tianfu Avenue,
Chengdu, P..R.China, 610041
M: +86 15583405168
E: li.z...@zte.com.cn
www.zte.com.cn


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


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

2017-05-15 Thread Zohar Sacks
+1

-Original Message-
From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Andrei Kojukhov
Sent: Monday, May 15, 2017 9:00 AM
To: Kapeluto, Zahi ; Dhananjay Pavgi 
; onap-discuss ; 
onap-...@lists.onap.org
Cc: Liron Shtraichman 
Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Zahi,

Tks, 

Yes, It looks like we are aligned about that all design related initiatives as 
part of other projects (Policy, CLAMP, merged ICE-VNF SDK) should be handled 
under the SDC umbrella - Option 1 in my proposal.
I believe that is the proposal that we need to socialize in ONAP.

BR

Andrei

-Original Message-
From: Kapeluto, Zahi [mailto:zk0...@intl.att.com] 
Sent: Sunday, May 14, 2017 3:16 PM
To: Dhananjay Pavgi ; Andrei Kojukhov 
; onap-discuss ; 
onap-...@lists.onap.org
Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

AT already has plans to embed the policy framework and the design-related 
CLAMP activities under the SDC umbrella, so I think we’re aligned on the vision.

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

From:  on behalf of Dhananjay Pavgi 

Date: Sunday, 14 May 2017 at 9:24
To: Andrei Kojukhov , onap-discuss 
, "onap-...@lists.onap.org" 

Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

Valid point. There’s certainly an overlap in multiple ONAP projects that deal 
with modelling. Option 1 sounds more logical. Would have all aspects of Design 
Time environment covered under one umbrella than having yet another umbrella 
project (as depicted in Option 2 and 3).

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com
 Platinum Member. Visit : 
http://www.onap.org

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Andrei Kojukhov
Sent: Thursday, May 11, 2017 12:46 AM
To: onap-discuss ; onap-...@lists.onap.org
Subject: [onap-tsc] Proposal for structuring Modeling projects

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:image003.png@01D2CCC4.F2B6FAA0]


Option 2: “Design Automation” umbrella including on-boarding and certification 
[cid:image004.png@01D2CCC4.F2B6FAA0]


Option 3: 

[onap-discuss] [onap-tsc] Project Proposal: External System Register

2017-05-15 Thread li.zi30
Dear ONAP TSC,






We would like to formally propose the External System Register project for ONAP.





ONAP components need to talk with external systems such as VIM/VNFM/SDNC/EMS to 
orchestrate a network service, for example, SO/VF-C need to talk with VIM to 
allocate resource and VNFM to deploy a VNF. So they should get the information 
of available external systems from a registry before call the Interfaces of 
these external systems.  ESR provides a service to centralized management of 
the information (name, vendor, version, acess end point, etc.) of external 
systems. So the ONAP components can get the system information with unified API 
from a logical single point.





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/External+System+Register 


 


Thanks,





LiZi
















李滋 lizi






IT开发工程师 IT Development
Engineer
网管及服务开发二部/中心研究院/系统产品 Network Management & Service Development Dept. II/Central 
R&D Institute/System Product









成都市高新区天府大道中段800号中兴通大厦
ZTE
Corporation Building, No. 800 Middle Section Tianfu Avenue, 
Chengdu, P..R.China, 610041 
M: +86 15583405168 
E: li.z...@zte.com.cn 
www.zte.com.cn___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


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

2017-05-15 Thread Kapeluto, Zahi
Hi Andrei,

AT already has plans to embed the policy framework and the design-related 
CLAMP activities under the SDC umbrella, so I think we’re aligned on the vision.

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

From:  on behalf of Dhananjay Pavgi 

Date: Sunday, 14 May 2017 at 9:24
To: Andrei Kojukhov , onap-discuss 
, "onap-...@lists.onap.org" 

Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

Valid point. There’s certainly an overlap in multiple ONAP projects that deal 
with modelling. Option 1 sounds more logical. Would have all aspects of Design 
Time environment covered under one umbrella than having yet another umbrella 
project (as depicted in Option 2 and 3).

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com
 Platinum Member. Visit : 
http://www.onap.org

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Andrei Kojukhov
Sent: Thursday, May 11, 2017 12:46 AM
To: onap-discuss ; onap-...@lists.onap.org
Subject: [onap-tsc] Proposal for structuring Modeling projects

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:image003.png@01D2CCC4.F2B6FAA0]


Option 2: “Design Automation” umbrella including on-boarding and certification
[cid:image004.png@01D2CCC4.F2B6FAA0]


Option 3: “Design Automation” umbrella excluding on-boarding and certification
[cid:image005.png@01D2CCC4.F2B6FAA0]


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:image006.png@01D2CCC4.F2B6FAA0]




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

Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at 

Re: [onap-discuss] [dev] Missing issue-id in commit message

2017-05-15 Thread ROSE, DANIEL V
Nacr is a check in gerrit that forbids the person who submitted a change from 
also approving it for addition into the code base. This means if I am a 
committer and I submit a change to gerrit, I can not +2 my own work, some other 
committer has to come and code review me and then +2.


Thanks,

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


-Original Message-
From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
Sent: Monday, May 15, 2017 10:41 AM
To: ROSE, DANIEL V 
Cc: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [dev] Missing issue-id in commit message

What do you mean by non-author code reviews? allowing it or forbidding it. If 
the later, I would disagree as I think in open source, anyone should be able to 
review code, and provide comments on changes.

Regarding jira issues, I tend to think it is a good practice to have a jira 
ticket tracking the work being done, hence as far as I’m concerned, I’m all in 
favour to that. But anyway, I think this is a TSC decision (to enforce it).

Thanks,
Alexis

> On May 15, 2017, at 10:21 AM, ROSE, DANIEL V  wrote:
> 
> I also had a proposal for non-author code reviews being enforced and that is 
> delayed too. 
> 
> So as we form new projects we can make a decision about if nacr and jira 
> issues are something we want (either per project or overall).
> 
> 
> Thanks,
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
> 
> 
> -Original Message-
> From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
> Sent: Monday, May 15, 2017 10:01 AM
> To: ROSE, DANIEL V 
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] [dev] Missing issue-id in commit message
> 
> Ok. Good to know it’s expected then. I’ll address that in my commits.
> 
> Thanks,
> Alexis
>> On May 15, 2017, at 9:33 AM, ROSE, DANIEL V  wrote:
>> 
>> Right now it is not required, but we had set a timeline to make it required. 
>> Not sure where that went. Either way I would say its strongly encouraged to 
>> have a jira ticket for your submits so that others can have some context for 
>> your issues.
>> 
>> 
>> 
>> Thanks,
>> Daniel Rose
>> ECOMP / ONAP
>> com.att.ecomp
>> 732-420-7308
>> 
>> -Original Message-
>> From: onap-discuss-boun...@lists.onap.org 
>> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
>> Sent: Monday, May 15, 2017 8:53 AM
>> To: onap-discuss@lists.onap.org
>> Subject: [onap-discuss] [dev] Missing issue-id in commit message
>> 
>> Hi,
>> 
>> I’m seeing this warning when submitting patches to ONAP gerrit:
>> 
>> remote: Missing issue-id in commit message
>> remote: Commit 44775a0ec9732f2874c1b07fee15c393949b55b8 not associated to 
>> any issue
>> remote: 
>> remote: Hint: insert one or more issue-id anywhere in the commit message.
>> remote:   Issue-ids are strings matching ([A-Z][A-Z0-9]{1,9}-\d+)
>> remote:   and are pointing to existing tickets on its-jira Issue-Tracker
>> 
>> Is having a issue-if required? 
>> As my commit successfully go through, I believe it is not mandatory, but I’m 
>> wondering if this warning could be removed?
>> 
>> Thanks,
>> Alexis
>> ___
>> onap-discuss mailing list
>> onap-discuss@lists.onap.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=2wwdGZ3YcpSivQ2Kio028A=n6qtQ2m5CO7Ja6kNT67Kj0782QkrVFVQp5GBmZX30Ho=ijbYsl1A2QuaiHmHoIoZhz0nl-_jLRo1gGRduzr__9Y=
>>  
> 

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


[onap-discuss] How to best populate Contributors and Committers in newly formed ONAP projects

2017-05-15 Thread Phil Robb
Hello ONAP Development Community:

I wanted to kick off  a thread where we can discuss the best way to
populate contributors, committers, and Project Technical Leads (PTLs) as we
are forming the first ONAP project teams over the next few weeks.  For
consistency across projects and the formation of a healthy development
ecosystem, it is important that we all have a common understanding of the
roles and responsibilities of each of these participants in our community.
There is no "one way" to do this so please do not consider this email as an
edict to be blindly followed.  Instead, I'd like to provide some
best-practices gathered over the years, then for us to discuss, then come
to consensus on how we will populate these roles.

First the definitions:

Contributor:  Anyone who wants to participate in the project.  This can be
providing input on the email list, contributing a bug fix, contributing
code for a new feature, writing test case or documentation, etc.  Like
everyone in the project, these people always have a voice and are welcome
to provide their thoughts and insights in any technical discussion within
the project.

Committer:  A contributor that has the authority, and responsibility to
submit changes to the ONAP software repository.  Typical characteristics of
a Committer are:
1) Deep expertise in the code base over which they are committers
2) Time dedicated to reviewing code contributions made by other contributors
3) Knowledge and understanding of the overall development activities
occurring within the project - this is important so that the review of new
code is taken in the context of the overall development for the project.
4) Knowledge and understanding of other, interdependent projects within
ONAP and how contributions to this project affect work being done elsewhere
by others.

The Committers on a project will review each code contribution made by the
Contributors, and other Committers on the project.  Often, a Committer will
need to enter into a dialog with a Contributor to have them make changes to
the contribution to better fit the functional or structural makeup of the
existing codebase.  It is preferable to have at least 2 Committers show
approval (with a +1) for a contribution before it is accepted into the
repository.  It is also a best practice to never have a Committer review
and/or approve their own contribution into the repository.

Project Technical Lead (PTL):  The PTL is a committer who is the one point
of contact responsible for representing the project to the rest of the ONAP
community.  For projects that become part of any given release, the PTL is
responsible for reporting milestone status and release readiness to the
rest of the community.  The PTL for each project is elected by the other
committers within the project.

Please note that it is very common for individuals to be a committer on one
project, and an contributor on another.  However, there is nothing stopping
an individual from being a committer on multiple projects.  Also, it is
rare, but not unheard of, that an individual can be a PTL on more than one
project.

General Guidelines:

When forming projects such as ONAP where there is a great deal of initial
(seed) code, it is helpful to establish some common guidelines for projects
to follow when building their initial contributor, committer, and PTL
lists.  Here are some general best practices.

- Identify yourself as a Contributor on a project proposal if you believe
that you have the time and ability to contribute to the development  of the
project.  One of the goals of every project within ONAP is to have a
diverse set of contributors working on the project.  This shows that the
project has broad interest within the community and that the development of
the project will reflect a varied set of end user use-cases, and
requirements.  Please do not put your name down if you do not have the time
or ability to participate.

- Identify yourself as a Committer on the project only if you have
significant expertise in the seed-code that is already present in the ONAP
code repository.  The one exception to this rule is in the event that the
first activity of the project is to bring in significant code or
functionality that exists in another code base.  In such situations it may
be helpful to have a Committer position(s) for individuals with expertise
in the other code base to aid in the review of such code as it is
contributed to the existing seed-code in the repository.  I would suggest
that the Committers with deep expertise in the seed-code within the
repository determine how best to (or if to) include experts in other
codebases to participate as Committers within the project.  If help is
needed for this particular task I am happy to help facilitate the
discussion on a project-by-project basis.

- There should be enough Committers on a project to effectively perform the
reviews on all of the contributions in a timely manner.  If there are not,
then contributions 

Re: [onap-discuss] [dev] Missing issue-id in commit message

2017-05-15 Thread ROSE, DANIEL V
I also had a proposal for non-author code reviews being enforced and that is 
delayed too. 

So as we form new projects we can make a decision about if nacr and jira issues 
are something we want (either per project or overall).


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


-Original Message-
From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] 
Sent: Monday, May 15, 2017 10:01 AM
To: ROSE, DANIEL V 
Cc: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [dev] Missing issue-id in commit message

Ok. Good to know it’s expected then. I’ll address that in my commits.

Thanks,
Alexis
> On May 15, 2017, at 9:33 AM, ROSE, DANIEL V  wrote:
> 
> Right now it is not required, but we had set a timeline to make it required. 
> Not sure where that went. Either way I would say its strongly encouraged to 
> have a jira ticket for your submits so that others can have some context for 
> your issues.
> 
> 
> 
> Thanks,
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
> Sent: Monday, May 15, 2017 8:53 AM
> To: onap-discuss@lists.onap.org
> Subject: [onap-discuss] [dev] Missing issue-id in commit message
> 
> Hi,
> 
> I’m seeing this warning when submitting patches to ONAP gerrit:
> 
> remote: Missing issue-id in commit message
> remote: Commit 44775a0ec9732f2874c1b07fee15c393949b55b8 not associated to any 
> issue
> remote: 
> remote: Hint: insert one or more issue-id anywhere in the commit message.
> remote:   Issue-ids are strings matching ([A-Z][A-Z0-9]{1,9}-\d+)
> remote:   and are pointing to existing tickets on its-jira Issue-Tracker
> 
> Is having a issue-if required? 
> As my commit successfully go through, I believe it is not mandatory, but I’m 
> wondering if this warning could be removed?
> 
> Thanks,
> Alexis
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=2wwdGZ3YcpSivQ2Kio028A=n6qtQ2m5CO7Ja6kNT67Kj0782QkrVFVQp5GBmZX30Ho=ijbYsl1A2QuaiHmHoIoZhz0nl-_jLRo1gGRduzr__9Y=
>  

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


Re: [onap-discuss] [onap-tsc] Project Proposal: External System Register

2017-05-15 Thread ROSE, DANIEL V
Hi LiZi,

How would you compare this project with the MSB project?

MSB lists

Service discovery - Server side discovery

and you list

•  Register/query/update/delete function of VIM
•  Register/query/update/delete function of VNFM
•  Register/query/update/delete function of SDN Controller
•  Register/query/update/delete function of EMS.

Can you say how they are different?

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 li.z...@zte.com.cn
Sent: Sunday, May 14, 2017 10:32 PM
To: onap-...@lists.onap.org; onap-discuss@lists.onap.org
Subject: [onap-tsc] Project Proposal: External System Register




Dear ONAP TSC,



We would like to formally propose the External System Register project for ONAP.



ONAP components need to talk with external systems such as VIM/VNFM/SDNC/EMS to 
orchestrate a network service, for example, SO/VF-C need to talk with VIM to 
allocate resource and VNFM to deploy a VNF. So they should get the information 
of available external systems from a registry before call the Interfaces of 
these external systems.  ESR provides a service to centralized management of 
the information (name, vendor, version, acess end point, etc.) of external 
systems. So the ONAP components can get the system information with unified API 
from a logical single point.



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/External+System+Register



Thanks,



LiZi









李滋 lizi



IT开发工程师 IT Development Engineer
网管及服务开发二部/中心研究院/系统产品 Network Management & Service Development Dept. II/Central 
R&D Institute/System Product


[cid:image001.gif@01D2CD63.08C0DFC0]

[cid:image002.gif@01D2CD63.08C0DFC0]
成都市高新区天府大道中段800号中兴通大厦
ZTE Corporation Building, No. 800 Middle Section Tianfu Avenue,
Chengdu, P..R.China, 610041
M: +86 15583405168
E: li.z...@zte.com.cn
www.zte.com.cn


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


Re: [onap-discuss] [dev] Missing issue-id in commit message

2017-05-15 Thread Alexis de Talhouët
Ok. Good to know it’s expected then. I’ll address that in my commits.

Thanks,
Alexis
> On May 15, 2017, at 9:33 AM, ROSE, DANIEL V  wrote:
> 
> Right now it is not required, but we had set a timeline to make it required. 
> Not sure where that went. Either way I would say its strongly encouraged to 
> have a jira ticket for your submits so that others can have some context for 
> your issues.
> 
> 
> 
> Thanks,
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
> Sent: Monday, May 15, 2017 8:53 AM
> To: onap-discuss@lists.onap.org
> Subject: [onap-discuss] [dev] Missing issue-id in commit message
> 
> Hi,
> 
> I’m seeing this warning when submitting patches to ONAP gerrit:
> 
> remote: Missing issue-id in commit message
> remote: Commit 44775a0ec9732f2874c1b07fee15c393949b55b8 not associated to any 
> issue
> remote: 
> remote: Hint: insert one or more issue-id anywhere in the commit message.
> remote:   Issue-ids are strings matching ([A-Z][A-Z0-9]{1,9}-\d+)
> remote:   and are pointing to existing tickets on its-jira Issue-Tracker
> 
> Is having a issue-if required? 
> As my commit successfully go through, I believe it is not mandatory, but I’m 
> wondering if this warning could be removed?
> 
> Thanks,
> Alexis
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=2wwdGZ3YcpSivQ2Kio028A=n6qtQ2m5CO7Ja6kNT67Kj0782QkrVFVQp5GBmZX30Ho=ijbYsl1A2QuaiHmHoIoZhz0nl-_jLRo1gGRduzr__9Y=
>  

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


Re: [onap-discuss] Query on vlb_ipaddr parameter of vLB usecase

2017-05-15 Thread ROSE, DANIEL V
We did thinks a bit bifferent for vlb vs vfw, here robot treats the packet gen 
as a tool to test the use case. This is actually closer to being how real vnfs 
would be tested as most real vnfs would not have a packet gen included in their 
base heat template.


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

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Kedar Ambekar
Sent: Monday, May 15, 2017 9:42 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Query on vlb_ipaddr parameter of vLB usecase

Hi ,

packet_gen_vlb_rackspace.env file of vLB use case has this parameter.

vlb_ipaddr: INSERT THE PUBLIC ADDRESS OF THE vLB HERE

To fill this, the vLB VM needs to be instantiated first.

What all Heat templates should be part of the zip file to be uploaded while 
defining a new Vendor Software Product in case of vLB ? Only 
dnsscaling_rackspace and base_vlb_rackspace first and then separately 
packet_gen_vlb_rackspace ? If this understanding is correct, then there will be 
2 Heat stacks for vLB  usecase ?

Regards,
KeDar



Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at 
http://www.techmahindra.com/Disclaimer.html
 externally 
http://tim.techmahindra.com/tim/disclaimer.html
 internally within TechMahindra.

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


Re: [onap-discuss] [dev] Missing issue-id in commit message

2017-05-15 Thread ROSE, DANIEL V
Right now it is not required, but we had set a timeline to make it required. 
Not sure where that went. Either way I would say its strongly encouraged to 
have a jira ticket for your submits so that others can have some context for 
your issues.



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

-Original Message-
From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët
Sent: Monday, May 15, 2017 8:53 AM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] [dev] Missing issue-id in commit message

Hi,

I’m seeing this warning when submitting patches to ONAP gerrit:

remote: Missing issue-id in commit message
remote: Commit 44775a0ec9732f2874c1b07fee15c393949b55b8 not associated to any 
issue
remote: 
remote: Hint: insert one or more issue-id anywhere in the commit message.
remote:   Issue-ids are strings matching ([A-Z][A-Z0-9]{1,9}-\d+)
remote:   and are pointing to existing tickets on its-jira Issue-Tracker

Is having a issue-if required? 
As my commit successfully go through, I believe it is not mandatory, but I’m 
wondering if this warning could be removed?

Thanks,
Alexis
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=2wwdGZ3YcpSivQ2Kio028A=n6qtQ2m5CO7Ja6kNT67Kj0782QkrVFVQp5GBmZX30Ho=ijbYsl1A2QuaiHmHoIoZhz0nl-_jLRo1gGRduzr__9Y=
 
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


Re: [onap-discuss] [ONAP EXTERNAL OPEN SOURCE COMMUNITY COORDINATOR] Election Kickoff

2017-05-15 Thread Ed Warnicke
I wish to nominate myself for ONAP External Open Source Community
Coordinator.

I have broad experience in Open Source Networking for over 15 years.  I've
been a TSC member at OpenDaylight since its inception, am TSC Chair at fd.io.
I know people across many different Open Source Communities, many of them
relevant to ONAP.

I believe strongly that a coordinator role is about identifying the members
of the ONAP community who have existing relationships with Open Source
communities relevant to ONAP, and connecting them with community members
who have needs in those Open Source communities.



​

On Thu, May 11, 2017 at 9:56 PM, Phil Robb 
wrote:

> Hello ONAP Community Members:
>
> Please consider this email as the kickoff of the ONAP External Open Source
> Community 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 External Open Source Community 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 External Open
> Source Community 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 <(970)%20229-5949>
> (M) 970-420-4292 <(970)%20420-4292>
> Skype: Phil.Robb
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss


[onap-discuss] [onap-tsc] Project Proposal: ONAP Usecase UI

2017-05-15 Thread shentao
ONAP TSC,

 

We would like to formally propose the ONAP Usecase UI project for ONAP.

The proposal wiki page, which includes details of the project description,
project scopes, and proposed repo names,

can be found at:
https://wiki.onap.org/display/DW/ONAP+Usecase+UI+Project+Proposal.

 

The ONAP Usecase UI team consists of representatives from China Mobile,
AT, Amdocs.

 

Thanks,

ShenTao

 

-

沈涛

中国移动通信有限公司研究院网络技术研究所

中国北京市西城区宣武门西大街32号(100053)

 

Shen Tao

China Mobile Research Institute

No.32 Xuanwumen west street,Xicheng District, Beijing 100053, China

 

Tel: +86 15801696688-34070

Mobile: +86 13521591389

Email:  shen...@chinamobile.com

-

 

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


Re: [onap-discuss] JIRA project "ONAP Operations Manager " missing

2017-05-15 Thread Josef Reisinger
Folks,
I added a few issues I stumbled across and for which I assume need some 
sort of resolution to https://jira.onap.org/projects/UCA/issues to avoid 
they get lost.

Mit freundlichen Grüßen / Kind regards 
Josef Reisinger 
When wisdom comes to call, there's nobody listening at all - Pendragon / 
Man Of Nomadic Traits 
IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius
IBM Deutschland 
Godesberger Allee 127 
53175 Bonn Beuel
Phone:+49 151 1426 4559 
Mobile:  +49-(0) 151 1426 4559 
E-Mail:  josef.reisin...@de.ibm.com 







From:   Josef Reisinger/Germany/IBM@IBMDE
To: Roger Maitland 
Cc: "onap-discuss@lists.onap.org" 
Date:   11.05.2017 17:03
Subject:Re: [onap-discuss] JIRA project "ONAP Operations Manager " 
missing
Sent by:onap-discuss-boun...@lists.onap.org



Folks,

thanks for your responses. I should have been more specific about the 
motivation of my initial  mail. In bringing up the ONAP stack on 
Openstack, I stumbled across a few things like fixed set waiting times in 
scripts and continuing irrespective of the state of the 
waited-for-resource (i.e. opendaylight in SDN-C, sdc-BE vs. sdc-cs in SDC 
etc) These times (and other parameters) work on the Rackspace instance 
but not on "my" instance and are hardly - if at all - to change. I would 
propose a few changes to the way it is done today. I assumed JIRA  would 
be the place to document the proposals as Bug, enhancement etc.. so they 
don't' get lost. I don't think this fits on the Wiki page as well as I 
don't believe it fits in the "questions" component of the Wiki.

Mit freundlichen Grüßen / Kind regards 
Josef Reisinger 
When wisdom comes to call, there's nobody listening at all - Pendragon / 
Man Of Nomadic Traits 
IBM Sales & Distribution, Communications Sector
Certified IT-Architect Telecommunications
IBM Certified Telecommunications Industry ITA
Lehrbeauftragter an der Hochschule Fresenius
IBM Deutschland 
Godesberger Allee 127 
53175 Bonn Beuel
Phone:+49 151 1426 4559 
Mobile:  +49-(0) 151 1426 4559 
E-Mail:  josef.reisin...@de.ibm.com 


IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter 
Geschäftsführung: Martina Koederitz (Vorsitzende), Nicole Reimer, Norbert 
Janzen, Dr. Christian Keller, Ivo Koerner, Stefan Lutz 
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 14562 / WEEE-Reg.-Nr. DE 99369940 





From:Roger Maitland 
To:"ROSE, DANIEL V" , "SPATSCHECK, OLIVER" 
, Josef Reisinger/Germany/IBM@IBMDE
Cc:"onap-discuss@lists.onap.org" 
Date:11.05.2017 16:46
Subject:RE: [onap-discuss] JIRA project "ONAP Operations Manager " 
missing



Josef, back to your question about the Operations Manager and sizing for 
multiple environments.  Clearly we need to support production environments 
where resource reservations for VMs (as done today) or pure container 
deployments are appropriate.  However, fully containerized deployments 
avoid the resource requirements of multiple guest operating systems, thus 
are more resource efficient.  Based on exploratory work we?ve already 
done, it may be possible to deploy an ONAP system on a single host in a 
development environment.  Therefore, being able to target multiple 
environments (e.g. development and production) will be required (although 
defaulting to current behavior might be appropriate).
 
Cheers,
Roger Maitland

Amdocs a Platinum member of ONAP
 
From: onap-discuss-boun...@lists.onap.org [
mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of ROSE, DANIEL V
Sent: Thursday, May 11, 2017 4:40 PM
To: SPATSCHECK, OLIVER; Josef Reisinger
Cc: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] JIRA project "ONAP Operations Manager " 
missing
 
But we will be moving JIRA tickers around from the existing ones so if you 
prefer to make them now you can. Something like 
https://jira.onap.org/projects/UCA/issuesis a nice catchall
 
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308
 
From: onap-discuss-boun...@lists.onap.org[
mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SPATSCHECK, 
OLIVER
Sent: Thursday, May 11, 2017 8:52 AM
To: Josef Reisinger 
Cc: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] JIRA project "ONAP Operations Manager " 
missing
 
***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.htmlfor more information.
 
I don?t think there will be a JIRA till the project is formally approved?. 
.
 
Oliver
 
On May 11, 2017, at 7:53 AM, Josef Reisinger  
wrote:
 
Folks,

am I correct to assume that the ' ONAP Operations Manager ' project deals 
with 

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

2017-05-15 Thread Andrei Kojukhov
Hi Zahi,

Tks, 

Yes, It looks like we are aligned about that all design related initiatives as 
part of other projects (Policy, CLAMP, merged ICE-VNF SDK) should be handled 
under the SDC umbrella - Option 1 in my proposal.
I believe that is the proposal that we need to socialize in ONAP.

BR

Andrei

-Original Message-
From: Kapeluto, Zahi [mailto:zk0...@intl.att.com] 
Sent: Sunday, May 14, 2017 3:16 PM
To: Dhananjay Pavgi ; Andrei Kojukhov 
; onap-discuss ; 
onap-...@lists.onap.org
Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

AT already has plans to embed the policy framework and the design-related 
CLAMP activities under the SDC umbrella, so I think we’re aligned on the vision.

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

From:  on behalf of Dhananjay Pavgi 

Date: Sunday, 14 May 2017 at 9:24
To: Andrei Kojukhov , onap-discuss 
, "onap-...@lists.onap.org" 

Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

Valid point. There’s certainly an overlap in multiple ONAP projects that deal 
with modelling. Option 1 sounds more logical. Would have all aspects of Design 
Time environment covered under one umbrella than having yet another umbrella 
project (as depicted in Option 2 and 3).

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com
 Platinum Member. Visit : 
http://www.onap.org

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Andrei Kojukhov
Sent: Thursday, May 11, 2017 12:46 AM
To: onap-discuss ; onap-...@lists.onap.org
Subject: [onap-tsc] Proposal for structuring Modeling projects

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:image003.png@01D2CCC4.F2B6FAA0]


Option 2: “Design Automation” umbrella including on-boarding and certification 
[cid:image004.png@01D2CCC4.F2B6FAA0]


Option 3: “Design Automation” umbrella excluding on-boarding and certification 
[cid:image005.png@01D2CCC4.F2B6FAA0]


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:image006.png@01D2CCC4.F2B6FAA0]




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