Re: [onap-tsc] Proposal: Architecture Subcommittee

[Dhananjay Pavgi]

+1 for Architecture subcommittee.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[cid:image002.png@01CE7323.F2727500]   [ONAP_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 Gadiyar, Rajesh
Sent: Saturday, May 13, 2017 6:17 AM
To: Alla Goldner ; Christopher Donley (Chris) 
; SPATSCHECK, OLIVER (OLIVER) 
; aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1 for forming the Architecture Subcommittee; Also agree with Chris and Alla on 
the ‘advisory’ nature of the Architecture sub-committee, and the important 
overseeing role this committee needs to play to ensure the consistency across 
the ONAP modules, interfaces, contentious issues between projects etc.

Leading upto the Middletown meetings, the effort that Vimal and Lingli had 
started with a small team on the ONAP architecture evolution and the 
architecture principles had made excellent progress. I like a small team 
approach for the Architecture Subcommittee (perhaps 1 participant nominated by 
each TSC member from their respective company) with a regular (monthly?) synch 
point with the larger technical community.

Rajesh

From: > 
on behalf of Alla Goldner 
>
Date: Friday, May 12, 2017 at 10:46 AM
To: "Christopher Donley (Chris)" 
>, 
"SPATSCHECK, OLIVER (OLIVER)" 
>, 
"aayush.bhatna...@ril.com" 
>
Cc: "onap-tsc@lists.onap.org" 
>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1, as also provided by my previous response to Aayush.

Architecture subcommittee, if created, should not deal with any specific 
architecture requirements, which are up to release/project to define.
Architecture subcommittee should review interactions between a different 
components/modules per defined Release goals, i.e. be responsible to validate 
whether e2e architecture across all modules is correct, whether all necessary 
interactions are covered etc.. It may also propose a new project, if gaps are 
identified, but it will be up to community to create such a project and up to 
TSC to approve/reject it.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image004.png@01D2CBD0.3A563510]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
>; 
aayush.bhatna...@ril.com
Cc: Alla Goldner >; 
Kanagaraj Manickam 
>; 
bob.monk...@arm.com; 
onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

+1.  The architecture subcommittee should NOT put gating requirements on any 
projects. Projects should be responsible for their own release plans and 
resources. I want to stress that my proposal is for an advisory committee, not 
a controlling committee. Specifically, the architecture subcommittee doesn’t 
have the power to make decisions or vote.  By Charter, that is solely the 
purview of the TSC. If decisions need to be made, such issues will be brought 
to the TSC.

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

The subcommittee should help to set a target functional architecture for the 
community (but not mandate it). That target may move over time, and it may take 
projects more than one release to catch up to it.  Scoping would be the 
responsibility of each project.  I also think there should be room for 
innovation. If a team has a good idea that would change the functional 
architecture, we may want to consider it.  I believe having a consensus target 
and a defined forum helps facilitate those conversations.

In the draft release plan, there is a checkpoint between functionality freeze 
and API freeze for an architecture check.  I think that would be a good spot 
for the architecture subcommittee to schedule a walk-through with each project 
to discuss the handoffs between each component to identify any 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Gadiyar, Rajesh]

+1 for forming the Architecture Subcommittee; Also agree with Chris and Alla on 
the ‘advisory’ nature of the Architecture sub-committee, and the important 
overseeing role this committee needs to play to ensure the consistency across 
the ONAP modules, interfaces, contentious issues between projects etc.

Leading upto the Middletown meetings, the effort that Vimal and Lingli had 
started with a small team on the ONAP architecture evolution and the 
architecture principles had made excellent progress. I like a small team 
approach for the Architecture Subcommittee (perhaps 1 participant nominated by 
each TSC member from their respective company) with a regular (monthly?) synch 
point with the larger technical community.

Rajesh

From:  on behalf of Alla Goldner 

Date: Friday, May 12, 2017 at 10:46 AM
To: "Christopher Donley (Chris)" , "SPATSCHECK, 
OLIVER (OLIVER)" , "aayush.bhatna...@ril.com" 

Cc: "onap-tsc@lists.onap.org" 
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1, as also provided by my previous response to Aayush.

Architecture subcommittee, if created, should not deal with any specific 
architecture requirements, which are up to release/project to define.
Architecture subcommittee should review interactions between a different 
components/modules per defined Release goals, i.e. be responsible to validate 
whether e2e architecture across all modules is correct, whether all necessary 
interactions are covered etc.. It may also propose a new project, if gaps are 
identified, but it will be up to community to create such a project and up to 
TSC to approve/reject it.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB21.F7B6FE50]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) ; 
aayush.bhatna...@ril.com
Cc: Alla Goldner ; Kanagaraj Manickam 
; bob.monk...@arm.com; onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

+1.  The architecture subcommittee should NOT put gating requirements on any 
projects. Projects should be responsible for their own release plans and 
resources. I want to stress that my proposal is for an advisory committee, not 
a controlling committee. Specifically, the architecture subcommittee doesn’t 
have the power to make decisions or vote.  By Charter, that is solely the 
purview of the TSC. If decisions need to be made, such issues will be brought 
to the TSC.

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

The subcommittee should help to set a target functional architecture for the 
community (but not mandate it). That target may move over time, and it may take 
projects more than one release to catch up to it.  Scoping would be the 
responsibility of each project.  I also think there should be room for 
innovation. If a team has a good idea that would change the functional 
architecture, we may want to consider it.  I believe having a consensus target 
and a defined forum helps facilitate those conversations.

In the draft release plan, there is a checkpoint between functionality freeze 
and API freeze for an architecture check.  I think that would be a good spot 
for the architecture subcommittee to schedule a walk-through with each project 
to discuss the handoffs between each component to identify any gaps so that 
teams have time to respond prior to API freeze.  The subcommittee should be 
asking questions, not dictating answers.

Chris

From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com]
Sent: Friday, May 12, 2017 6:42 AM
To: aayush.bhatna...@ril.com
Cc: GOLDNER, ALLA; Kanagaraj Manickam; 
bob.monk...@arm.com; Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Don’t get my comment wrong I am in full support of an architecture 
subcommittee. I am somewhat worried on scope and process though.

If the architecture team can put release gating requirements on the project as 
outlined below (maybe I didn’t understand that correctly …) what is the process 
to ensure that they are realistic in the next release (enough resources 
available in the project) and align with the priorities of the volunteers in 
the projects which do the  work.  If they don’t they won’t get implemented and 
we don’t have a release.

I thought release features are worked by the projects.

It always worries me if you separate the decision 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Casem Majd (Cas Majd)]

+1
Keeping the architecture subcommittee open promotes distribution of information 
and is ultimately good for the community.

Cas


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Friday, May 12, 2017 3:26 PM
To: Haiby, Ranny (Nokia - US/San Jose USA); Alla Goldner; SPATSCHECK, OLIVER 
(OLIVER); aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Ranny,

What’s the saying?  If you want to go fast, go alone; if you want to go far, go 
together

You’re right that there are risks to having an open membership. The alternative 
is to impose restrictions such as the number of participants per company.  
However, that could leave some ideas out of the conversation, and foster 
mistrust in people who are not invited to participate.  My preference is to err 
on the side of openness, and impose limitations down the road if the committee 
becomes unwieldy. I want to set the right note at the beginning that we value 
community input and transparency, and are not making decisions in the 
proverbial smoke-filled room. (Also why I’m proposing this as an advisory body 
and not a decision making body).

My experience is that some people will be more interested in architecture than 
others, and people will self-select.  I expect that we would see a fairly 
stable core group, and others who come and go based on the topic. Yes, in 
OPEN-O, some people opted out.  We regularly had about 30 people attending 
(+/-), compared to 45 or so who showed up on TSC calls and 100+ contributing to 
the codebase.   Generally, about 10 people were active participants.  I don’t 
know how many people from ONAP will want to join - so far, about 10 have 
reached out to me.  I expect we’ll have more step forward if this proposal is 
approved and we have an open call for participation.

You could  have architecture discussions outside of the subcommittee, but it 
becomes difficult for people to know when or where conversations are taking 
place, and many such conversations de facto become private.  I think having a 
defined forum helps build trust in the community.

As with other aspects of open source communities, the architecture subcommittee 
would be contribution-driven.  I expect that the chair would schedule regular 
meetings, solicit contributions for particular topics, and publish an agenda in 
advance.  People who have a contribution or question could schedule a slot on 
the agenda.

Chris

From: Haiby, Ranny (Nokia - US/San Jose USA) [mailto:ranny.ha...@nokia.com]
Sent: Friday, May 12, 2017 11:33 AM
To: Alla Goldner; Christopher Donley (Chris); SPATSCHECK, OLIVER (OLIVER); 
aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

Chris,

I am having a hard time figuring out the difference between an architecture 
subcommittee member and a “plain” member of the community. Architectural 
discussions take place in the community on a regular basis and they are open to 
all. With the current definition of the subcommittee I don’t think any member 
of the community will opt-out for participation. I am missing some kind of 
required commitment from subcommittee members. Unless some commitment is 
involved (meeting participations, contributions to documentations, etc.) I 
hardly see how we can have an efficient subcommittee in a community as large as 
ours.

What was your experience in Open-O? What was the size of the subcommittee? Did 
any community member opt-out?

Would love to hear your thought on that matter.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, May 12, 2017 10:47 AM
To: Christopher Donley (Chris) ; SPATSCHECK, 
OLIVER (OLIVER) ; aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1, as also provided by my previous response to Aayush.

Architecture subcommittee, if created, should not deal with any specific 
architecture requirements, which are up to release/project to define.
Architecture subcommittee should review interactions between a different 
components/modules per defined Release goals, i.e. be responsible to validate 
whether e2e architecture across all modules is correct, whether all necessary 
interactions are covered etc.. It may also propose a new project, if gaps are 
identified, but it will be up to community to create such a project and up to 
TSC to approve/reject it.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB12.A5B18490]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
>; 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Christopher Donley (Chris)]

Ranny,

What’s the saying?  If you want to go fast, go alone; if you want to go far, go 
together

You’re right that there are risks to having an open membership. The alternative 
is to impose restrictions such as the number of participants per company.  
However, that could leave some ideas out of the conversation, and foster 
mistrust in people who are not invited to participate.  My preference is to err 
on the side of openness, and impose limitations down the road if the committee 
becomes unwieldy. I want to set the right note at the beginning that we value 
community input and transparency, and are not making decisions in the 
proverbial smoke-filled room. (Also why I’m proposing this as an advisory body 
and not a decision making body).

My experience is that some people will be more interested in architecture than 
others, and people will self-select.  I expect that we would see a fairly 
stable core group, and others who come and go based on the topic. Yes, in 
OPEN-O, some people opted out.  We regularly had about 30 people attending 
(+/-), compared to 45 or so who showed up on TSC calls and 100+ contributing to 
the codebase.   Generally, about 10 people were active participants.  I don’t 
know how many people from ONAP will want to join - so far, about 10 have 
reached out to me.  I expect we’ll have more step forward if this proposal is 
approved and we have an open call for participation.

You could  have architecture discussions outside of the subcommittee, but it 
becomes difficult for people to know when or where conversations are taking 
place, and many such conversations de facto become private.  I think having a 
defined forum helps build trust in the community.

As with other aspects of open source communities, the architecture subcommittee 
would be contribution-driven.  I expect that the chair would schedule regular 
meetings, solicit contributions for particular topics, and publish an agenda in 
advance.  People who have a contribution or question could schedule a slot on 
the agenda.

Chris

From: Haiby, Ranny (Nokia - US/San Jose USA) [mailto:ranny.ha...@nokia.com]
Sent: Friday, May 12, 2017 11:33 AM
To: Alla Goldner; Christopher Donley (Chris); SPATSCHECK, OLIVER (OLIVER); 
aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

Chris,

I am having a hard time figuring out the difference between an architecture 
subcommittee member and a “plain” member of the community. Architectural 
discussions take place in the community on a regular basis and they are open to 
all. With the current definition of the subcommittee I don’t think any member 
of the community will opt-out for participation. I am missing some kind of 
required commitment from subcommittee members. Unless some commitment is 
involved (meeting participations, contributions to documentations, etc.) I 
hardly see how we can have an efficient subcommittee in a community as large as 
ours.

What was your experience in Open-O? What was the size of the subcommittee? Did 
any community member opt-out?

Would love to hear your thought on that matter.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, May 12, 2017 10:47 AM
To: Christopher Donley (Chris) ; SPATSCHECK, 
OLIVER (OLIVER) ; aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1, as also provided by my previous response to Aayush.

Architecture subcommittee, if created, should not deal with any specific 
architecture requirements, which are up to release/project to define.
Architecture subcommittee should review interactions between a different 
components/modules per defined Release goals, i.e. be responsible to validate 
whether e2e architecture across all modules is correct, whether all necessary 
interactions are covered etc.. It may also propose a new project, if gaps are 
identified, but it will be up to community to create such a project and up to 
TSC to approve/reject it.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB12.A5B18490]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
>; 
aayush.bhatna...@ril.com
Cc: Alla Goldner >; 
Kanagaraj Manickam 
>; 
bob.monk...@arm.com; 
onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

+1.  The architecture subcommittee should NOT put gating requirements on any 
projects. Projects should be responsible for their own release 

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

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

Just to chip in my perspective on this “Rome” discussion,

It is not about what “works very well now” and what doesn’t. Both approaches 
may very well work now. The BPMN approach apparently worked well in Open-O and 
I can attest that in Nokia we successfully delivered working EPC and VoLTE 
solutions using a commercial product that uses TOSCA as the master template, 
with callouts to an external workflow engine (OpenStack Mistral in our case). 
You are welcome to read about it here.

The suggested approach of having BPMN as the master execution workflow and 
keeping TOSCA as just the topology store makes little sense to me. The use of 
TOSCA in this case will be merely a fig leaf and we may be better off without 
it.

Other than having an existing implementation, what are the other merits of BPMN 
over TOSCA as the master plan?

Regards,

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Michael Brenner
Sent: Friday, May 12, 2017 10:08 AM
To: meng.zhaoxi...@zte.com.cn
Cc: onap-discuss ; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal 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 trigger imperative workflows, in that case you MUST provide a 
returning mechanism to the declarative model. This is what I have been 
advocating, and finally getting support from Nokia (Ranny) and Amdocs (Andrei).

Nothing stops anyone to do exactly what you want right now in opensource with 
the current TOSCA standard. All you have to do is to include scripts for each 
of the lifecycle events where you want and external workflow engine to execute 
the action.

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.

In your case, TOSCA is only used to describe the topology and nodes, and create 
an internal model (which may be translated to some other internal model). So 
you can provide an artifact that is opaque to the TOSCA parser and 
orchestrator, where you capture exactly what you suggest to be standardized - 
i.e. an indicator that you want to use an external workflow engine, and a 
pointer to a link that describes the engine and the plan.

The TOSCA parser not choke because it is not supposed to parse the artifacts 
themselves, just make them available in the internal model.

Once the internal model is generated - your preferred orchestrator that 
traverse the model will get to the point where that artifact is represented, 
and will execute it accordingly.

The only true reason to standardizing such a procedure is to define the 
relationship between the declarative model and the use of an external engine 
(whether for workflows or any other matter) - and such a procedure implies that 
the declarative model is "the master of that sub-domain" hence needs to know 
how to regain control once the external engine completed its task. But since 
this is not the approach you want to consider for your use case, you do not 
need any standard extension in TOSCA. Please try to think through the use case, 
through the prism of TOSCA, if you want to use TOSCA. Otherwise, this becomes a 
case of driving a tank to do your shopping at the super-market. Yes, it is 
possible, since the tank is vehicle after all, but neither recommended, nor 
should you expect support from the broader community.

Best regards,
Michael

On Fri, May 12, 2017 at 12:53 PM, Michael Brenner 
> wrote:
Sure ... but "Rome" did not become a standard in its first day either, neither 
in its 2nd, nor in its 100th day. It became a "standard" in the back-view 
mirror, hundreds of years later:-)
Having said that - considering that you made the analogy, I will take it as a 
great compliment for TOSCA, so let's then use this great standard in the way it 
was planned to be used, rather than chopping it up, using the least of its 
strengths, and then attaching a rushed appendix to on of its chopped wings!

Michael


On Fri, May 12, 2017 at 12:32 PM, 
> wrote:

Hi Nati and all,



I think we should focus on the requirement from opensource which is to include 
standard workflow DSL such as BPMN or BPEL as an alternative workflow approach 
for TOSCA service lifecycle management process modelling, rather than how to 
figure out a "sophisticated" mechanism to address all the raised questions of 
this approach, or we can't accomplish it in a predictable timeline.



The solution might not look to be perfect right now but work very 

Re: [onap-tsc] Proposal: Architecture Subcommittee

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

Chris,

I am having a hard time figuring out the difference between an architecture 
subcommittee member and a “plain” member of the community. Architectural 
discussions take place in the community on a regular basis and they are open to 
all. With the current definition of the subcommittee I don’t think any member 
of the community will opt-out for participation. I am missing some kind of 
required commitment from subcommittee members. Unless some commitment is 
involved (meeting participations, contributions to documentations, etc.) I 
hardly see how we can have an efficient subcommittee in a community as large as 
ours.

What was your experience in Open-O? What was the size of the subcommittee? Did 
any community member opt-out?

Would love to hear your thought on that matter.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, May 12, 2017 10:47 AM
To: Christopher Donley (Chris) ; SPATSCHECK, 
OLIVER (OLIVER) ; aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1, as also provided by my previous response to Aayush.

Architecture subcommittee, if created, should not deal with any specific 
architecture requirements, which are up to release/project to define.
Architecture subcommittee should review interactions between a different 
components/modules per defined Release goals, i.e. be responsible to validate 
whether e2e architecture across all modules is correct, whether all necessary 
interactions are covered etc.. It may also propose a new project, if gaps are 
identified, but it will be up to community to create such a project and up to 
TSC to approve/reject it.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB12.A5B18490]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
>; 
aayush.bhatna...@ril.com
Cc: Alla Goldner >; 
Kanagaraj Manickam 
>; 
bob.monk...@arm.com; 
onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

+1.  The architecture subcommittee should NOT put gating requirements on any 
projects. Projects should be responsible for their own release plans and 
resources. I want to stress that my proposal is for an advisory committee, not 
a controlling committee. Specifically, the architecture subcommittee doesn’t 
have the power to make decisions or vote.  By Charter, that is solely the 
purview of the TSC. If decisions need to be made, such issues will be brought 
to the TSC.

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

The subcommittee should help to set a target functional architecture for the 
community (but not mandate it). That target may move over time, and it may take 
projects more than one release to catch up to it.  Scoping would be the 
responsibility of each project.  I also think there should be room for 
innovation. If a team has a good idea that would change the functional 
architecture, we may want to consider it.  I believe having a consensus target 
and a defined forum helps facilitate those conversations.

In the draft release plan, there is a checkpoint between functionality freeze 
and API freeze for an architecture check.  I think that would be a good spot 
for the architecture subcommittee to schedule a walk-through with each project 
to discuss the handoffs between each component to identify any gaps so that 
teams have time to respond prior to API freeze.  The subcommittee should be 
asking questions, not dictating answers.

Chris

From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com]
Sent: Friday, May 12, 2017 6:42 AM
To: aayush.bhatna...@ril.com
Cc: GOLDNER, ALLA; Kanagaraj Manickam; 
bob.monk...@arm.com; Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Don’t get my comment wrong I am in full support of an architecture 
subcommittee. I am somewhat worried on scope and process though.

If the architecture team can put release gating requirements on the project as 
outlined below (maybe I didn’t understand that correctly …) what is the process 
to ensure that they are realistic in the next release (enough resources 
available in the project) and align with the priorities of the volunteers in 
the 

Re: [onap-tsc] ONAP project proposals

[Alla Goldner]

Hi Mazin, all,

The ONAP Extensibility project 
https://wiki.onap.org/display/DW/ONAP+Extensibility will be submitted for 
review on Monday.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB65.5C16CFE0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: Friday, May 12, 2017 2:33 PM
To: onap-tsc 
Subject: [onap-tsc] ONAP project proposals

ONAP Team,

Great job in getting your proposals submitted for review. Let me know if you 
will
not be complete with your proposal by end of today (Friday US time). I would 
like to follow up with
you Monday and check progress and offer my help.

I encourage the ONAP community to read all projects that have been submitted 
and ready for review.

thanks!
Mazin




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

you may review at https://www.amdocs.com/about/email-disclaimer 

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

[onap-tsc] Project Proposal: APPC

[KLEIN, REUBEN]

ONAP TSC,

We would like to formally propose the APPC project for ONAP.
The proposal wiki page, which includes details of the project description, 
project scope, and proposed repo names, can be found at:  
https://wiki.onap.org/display/DW/APPC++Project+Proposal


The CCF team consists of representatives from MDOCS, Orange, Intel and AT

Please contact me if there are any issues or questions regarding the proposal.

Sincerely,


Reuben Klein

Distinguished Inventive Scientist

AT Laboratories

Advanced Technologiy Strategy & Architecture

Tel:+1 732 420 8890



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

Re: [onap-tsc] ONAP project proposals

[Lingli]

ONAP Team, 


Great job in getting your proposals submitted for review. Let me know if you will
not be complete with your proposal by end of today (Friday US time). I would like to follow up with 
you Monday and check progress and offer my help.


I encourage the ONAP community to read all projects that have been submitted and ready for review.


thanks!
Mazin



























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

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Christopher Donley (Chris)]

That’s the intention, and one of the reasons I’m proposing a subcommittee, 
rather than a project. If we form this as a project, then decisions would be 
made by the ptl and committers. It also clouds the relationship with other 
projects.

As proposed, the architecture subcommittee would be an advisory body open to 
the community. There are not restrictions on who can participate:
The architecture subcommittee is open to all interested participants, and 
meetings are open.

I believe the subcommittee should be open to the community, whether or not you 
are a member of the TSC or an employee of a member company.

I specifically do NOT believe that this subcommittee should have approval 
power. That should rest with the projects. This group would advise the projects 
and ask questions about how does project A interact with project B, but should 
NOT dictate the answer.

Chris

From: Alla Goldner [mailto:alla.gold...@amdocs.com]
Sent: Thursday, May 11, 2017 9:59 PM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: RE: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB08.6E07D670]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman ; Christopher Donley (Chris) 
; onap-tsc 
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

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

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

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

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

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

+1  

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

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

Bob,

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

Thanks,
Chris

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

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

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

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

From: 

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

[Michael Brenner]

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 trigger imperative workflows, in that case you MUST provide a
returning mechanism to the declarative model. This is what I have been
advocating, and finally getting support from Nokia (Ranny) and Amdocs
(Andrei).

Nothing stops anyone to do exactly what you want right now in opensource
with the current TOSCA standard. All you have to do is to include scripts
for each of the lifecycle events where you want and external workflow
engine to execute the action.

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.

In your case, TOSCA is only used to describe the topology and nodes, and
create an internal model (which may be translated to some other internal
model). So you can provide an artifact that is opaque to the TOSCA parser
and orchestrator, where you capture exactly what you suggest to be
standardized - i.e. an indicator that you want to use an external workflow
engine, and a pointer to a link that describes the engine and the plan.

The TOSCA parser not choke because it is not supposed to parse the
artifacts themselves, just make them available in the internal model.

Once the internal model is generated - your preferred orchestrator that
traverse the model will get to the point where that artifact is
represented, and will execute it accordingly.

The only true reason to standardizing such a procedure is to define the
relationship between the declarative model and the use of an external
engine (whether for workflows or any other matter) - and such a procedure
implies that the declarative model is "the master of that sub-domain" hence
needs to know how to regain control once the external engine completed its
task. But since this is not the approach you want to consider for your use
case, you do not need any standard extension in TOSCA. Please try to think
through the use case, through the prism of TOSCA, if you want to use TOSCA.
Otherwise, this becomes a case of driving a tank to do your shopping at the
super-market. Yes, it is possible, since the tank is vehicle after all, but
neither recommended, nor should you expect support from the broader
community.

Best regards,
Michael

On Fri, May 12, 2017 at 12:53 PM, Michael Brenner 
wrote:

> Sure ... but "Rome" did not become a standard in its first day either,
> neither in its 2nd, nor in its 100th day. It became a "standard" in the
> back-view mirror, hundreds of years later:-)
> Having said that - considering that you made the analogy, I will take it
> as a great compliment for TOSCA, so let's then use this great standard in
> the way it was planned to be used, rather than chopping it up, using the
> least of its strengths, and then attaching a rushed appendix to on of its
> chopped wings!
>
> Michael
>
>
> On Fri, May 12, 2017 at 12:32 PM,  wrote:
>
>> Hi Nati and all,
>>
>>
>> I think we should focus on the requirement from opensource which is to
>> include standard workflow DSL such as BPMN or BPEL as an alternative
>> workflow approach for TOSCA service lifecycle management process
>> modelling, rather than how to figure out a "sophisticated" mechanism to
>> address all the raised questions of this approach, or we can't accomplish
>> it in a predictable timeline.
>>
>>
>> The solution might not look to be perfect right now but work very well
>> in the orchestration implementation.
>>
>>
>> Even in TOSCA Specification, there're still some parts needed to be
>> improved, but we embrace the ideas and allow them to evolve in the right
>> direction.
>>
>>
>> Please let me share a famous Chinese saying here "不积硅步,无以至千里",  or in
>> western, we say "Rome was not built in a day".
>>
>>
>> Thanks,
>>
>> Zhaoxing
>>
>>
>>
>> 原始邮件
>> *发件人：* ＜na...@gigaspaces.com＞;
>> *收件人：* ＜mich...@gigaspaces.com＞;赵化冰10201488;
>> *抄送人：* ＜onap-disc...@lists.onap.org＞; ＜onap-tsc@lists.onap.org＞;
>> *日 期 ：*2017年05月11日 21:42
>> *主 题 ：**Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN
>> supportproposal at OASIS TOSCA WG*
>>
>>
>> "The proposal has been discussed in the OASIS TOSCA for a couple of
>> weeks and most of the members agreed on it except the strong pushback from
>> Michael of Gigaspaces."
>> Huabing et al
>>
>> I wanted to ask that we will keep the discussion on a professional and
>> not a personal level.
>>
>> First i want to clarify what were discussing here right now is not a
>> question of declarative vs impressive workflow as it is being coined for
>> some reason.
>> What were really discussing is whether we use TOSCA as a configuration
>> input or as a model that represent a live system and allow continues
>> interaction 

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

[Michael Brenner]

Sure ... but "Rome" did not become a standard in its first day either,
neither in its 2nd, nor in its 100th day. It became a "standard" in the
back-view mirror, hundreds of years later:-)
Having said that - considering that you made the analogy, I will take it as
a great compliment for TOSCA, so let's then use this great standard in the
way it was planned to be used, rather than chopping it up, using the least
of its strengths, and then attaching a rushed appendix to on of its chopped
wings!

Michael


On Fri, May 12, 2017 at 12:32 PM,  wrote:

> Hi Nati and all,
>
>
> I think we should focus on the requirement from opensource which is to
> include standard workflow DSL such as BPMN or BPEL as an alternative
> workflow approach for TOSCA service lifecycle management process
> modelling, rather than how to figure out a "sophisticated" mechanism to
> address all the raised questions of this approach, or we can't accomplish
> it in a predictable timeline.
>
>
> The solution might not look to be perfect right now but work very well in
> the orchestration implementation.
>
>
> Even in TOSCA Specification, there're still some parts needed to be
> improved, but we embrace the ideas and allow them to evolve in the right
> direction.
>
>
> Please let me share a famous Chinese saying here "不积硅步,无以至千里",  or in
> western, we say "Rome was not built in a day".
>
>
> Thanks,
>
> Zhaoxing
>
>
>
> 原始邮件
> *发件人：* ＜na...@gigaspaces.com＞;
> *收件人：* ＜mich...@gigaspaces.com＞;赵化冰10201488;
> *抄送人：* ＜onap-disc...@lists.onap.org＞; ＜onap-tsc@lists.onap.org＞;
> *日 期 ：*2017年05月11日 21:42
> *主 题 ：**Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN
> supportproposal at OASIS TOSCA WG*
>
>
> "The proposal has been discussed in the OASIS TOSCA for a couple of weeks
> and most of the members agreed on it except the strong pushback from
> Michael of Gigaspaces."
> Huabing et al
>
> I wanted to ask that we will keep the discussion on a professional and not
> a personal level.
>
> First i want to clarify what were discussing here right now is not a
> question of declarative vs impressive workflow as it is being coined for
> some reason.
> What were really discussing is whether we use TOSCA as a configuration
> input or as a model that represent a live system and allow continues
> interaction with system through the model e.g. Model Driven.
>
> So the discussion is wether ONAP orchestration should be truly model
> driven or not and not whether we should support declarative vs imperative
> workflow and whether that workflow should be written in BPMN or some other
> language.
>
> There is also no real argument on whether you can or can't use BPMN as a
> workflow engine.  Intact if things done right we should't even care about
> it.
>
> I think that we all agreed that an implementor can choose to run the
> workflow in what ever language or format he wishes and that should become a
> "black-box" from the Orchestrator perspective.
>
> To allow this kind of flexibility i.e. allow the implementor to choose the
> workflow language that fits best to his needs we need to define a clear
> interface on how the execution get called and also how the state of the
> model get effected once that execution is completed.
>
> That's what Michael is basically trying to say repetitively but
> unfortunately he's comment are being ignored.
>
> Both Michael myself are more than happy to work with you or anyone else on
> the proposal for defining those interfaces assuming that we agree with the
> goal and scope toward a true Model Driven orchestration.
>
> Speaking of a community process.
> I would appreciate if you could respond to the questions that was raised
> here an on the OASIS discussion about the proposal in order that we could
> have a constructive dialogue and move forward.
>
> Here is a summary of some of those questions that were left un answered:
>
> 1. What's in your proposal should be the effect on the model after the
> execution is completed?  (I assume that right now this is considered out of
> scope in the current proposal right?)
>
> 2. Your making assumption on what works for Telco vs Simple use cases.
> (This goes with the declarative vs imperative for some reason even though
> i'm not sure how the two are even related). Can you share on what basis are
> you making those assumptions?
>
> 3. If we agree to leave that the implementation of the workflow should be
> treated as a blackbox why do we need a specific specification proposal for
> BPMN ?
>
> Let's start with that.
> As i mentioned we would be more than happy to work with you on those areas
> and put more clarity behind those items.
>
> Nati S.
>
>
>
>
>
>
>
>
> On Wed, May 10, 2017 at 9:03 AM Michael Brenner ＜mich...@gigaspaces.com＞
> wrote:
>
>> Huabing,
>> I recognize the need in ONAP to support delegation in TOSCA to external
>> workflow engines. I have said this repeatedly, and still am
>> miss-interpreted.
>> This has nothing to do with backward 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[SPATSCHECK, OLIVER (OLIVER)]

Don’t get my comment wrong I am in full support of an architecture 
subcommittee. I am somewhat worried on scope and process though.

If the architecture team can put release gating requirements on the project as 
outlined below (maybe I didn’t understand that correctly …) what is the process 
to ensure that they are realistic in the next release (enough resources 
available in the project) and align with the priorities of the volunteers in 
the projects which do the  work.  If they don’t they won’t get implemented and 
we don’t have a release.

I thought release features are worked by the projects.

It always worries me if you separate the decision process from the resources as 
without resources even the best decision has no value.

Oliver


On May 12, 2017, at 2:01 AM, 
aayush.bhatna...@ril.com wrote:

+1 for the subcommittee formation.

Additional proposal on the deliverables of the architectural subcommittee -

- Create the deployment architecture for ONAP especially for multi-DC VNF 
orchestration. This aspect is important as ONAP components such as the DCAE 
follow an edge-lake architecture which becomes relevant only when we visualize 
a multi-site deployment.

- Define the architectural principles of disaster recovery (DR) orchestrated by 
the MSO and Policy Engine for VNFs.
​

Regards

Aayush

From: onap-tsc-boun...@lists.onap.org 
> on 
behalf of Alla Goldner >
Sent: Friday, May 12, 2017 10:29 AM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

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 Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman >; Christopher 
Donley (Chris) 
>; onap-tsc 
>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

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

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

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

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

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

+1  

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

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

Bob,

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

Thanks,
Chris

From: Bob Monkman 

[onap-tsc] ONAP project proposals

[GILBERT, MAZIN E (MAZIN E)]

ONAP Team,

Great job in getting your proposals submitted for review. Let me know if you 
will
not be complete with your proposal by end of today (Friday US time). I would 
like to follow up with
you Monday and check progress and offer my help.

I encourage the ONAP community to read all projects that have been submitted 
and ready for review.

thanks!
Mazin





___
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 proposalat OASIS TOSCA WG

[Andrei Kojukhov]

Second to Michael, the way it is proposed by Huabing, it is like you have an 
ocean of BPMN with small optional islands of TOSCA.

BR

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Michael Brenner
Sent: Friday, May 12, 2017 1:46 PM
To: Huabing Zhao 
Cc: onap-discuss ; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN support proposalat 
OASIS TOSCA WG

Huabing,

The way you propose it ... you might as well ask the question "why use TOSCA at 
all"? This was one of my points in our discussion last Friday.
I cannot understand why one tries to cannibalize a good standard that was 
purposefully defined for cloud workloads intent-driven deployment and 
orchestration. TOSCA should be used as it was intended, and take advantage of 
its characteristics, instead of twisted around to fit some existing 
implementation.

Best regards,
Michael


On Fri, May 12, 2017 at 3:39 AM, 
> wrote:

Hi Ranny,

Thanks for your comments.



It's an interesting use case, in my opinion, why not put all these activities 
into a BPMN workflow, including the creation of VNF, the IP config of the peer 
physical MME and the port config of the security group, the parameters exchange 
is supported between different BPMN task nodes.



OPEN-O has a workflow design tool which can design Lifecycle Management 
workflows for a Network Service. The designer can design a BPMN task to call 
the operation of a tosca node, and an external service as well, including 
Catalog, Inventory(A), NFV-O, VNFM, etc.  So the parameters needed for a 
specific orchestration activity can get from either the BPMN task parameter or 
a service call to an external service.



For this use case, if we put it in the context of OPEN-O, the creation request 
of VNF is passed to NFV-O by a BPMN task node, which creates VNF and returns 
the IP as an output parameter. The output parameter can be used as an input 
parameter of the next BPMN task node, which uses this parameter to config the 
physical MME, in turn, the output of this task can be passed to the next task 
to config the security group. The actual workflow may have more tasks, 
including the interactions with Catalog(get VNF Package) and Inventory(Update 
the service instance), etc.



Furthermore, normally there're multiple nodes in a network service template, 
OPEN-O use parser to get all the nodes from service template and sort the nodes 
based on their topology dependency and then pass the nodes list to a BPMN loop. 
By this approach, we can see that BPMN is not an opposite of topology driven( 
aka declarative workflow), on the contrary, BPMN can complement and enhance 
declarative approach to include external service as well when needed.



Thanks,

Huabing


Original Mail
Sender:  ＜ranny.ha...@nokia.com＞;
To:  ＜na...@gigaspaces.com＞; 
＜mich...@gigaspaces.com＞;zhaohuabing10201488;
CC:  ＜onap-disc...@lists.onap.org＞; 
＜onap-tsc@lists.onap.org＞;
Date: 2017/05/12 01:52
Subject: RE: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposalat 
OASIS TOSCA WG


Huabing,

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

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

Thanks,

Ranny.

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org]
 On Behalf Of Nati Shalom
Sent: Thursday, May 11, 2017 6:41 AM
To: Michael Brenner ＜mich...@gigaspaces.com＞; 
Huabing Zhao ＜zhao.huab...@zte.com.cn＞
Cc: onap-discuss 
＜onap-disc...@lists.onap.org＞; 
onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposal 
at OASIS TOSCA WG

"The proposal has been discussed in the OASIS TOSCA for a couple of weeks and 
most of the 

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

[Michael Brenner]

I would like to add the following point which seems to be forgotten from
the discussion. VNF packages are supposed to be put together by the VNF
vendor. The VNF package will include the description of the VNF (let's
refer to it as a VNFD), and all the accompanying artifacts (s/w images,
scripts to react to lifecycle events, etc). Vendors can only be held
responsible when that VNF package is processed as intended - including all
the artifacts.
TOSCA gives a VNF vendor the ability to both comply to, and rely to this
"handshake" between vendor and service provider. The vendor writes its own
TOSCA service template that refers to the artifacts the vendor includes in
the package, in ordert to express "the vendor's INTENT" about how its VNF
is to be deployed and (lifecycle) managed. That is a contract between
vendor and service provider. If one changes the service template or the
artifacts provided by the vendor, the vendor can deby accountability for
the way its VNF functions when deployed.

Now, let's look at the use of "external workflows" executed by a particular
workflow engine, specified by name (BPMN, BPEL, etc), vs one un=specified
(declarative). If we allow in the tOSCA service template to specify ANY
workflow engine (and that is the path of your proposal), then the VNF
vendor has the following options:
1. specify a declarative workflow (no particular workflow engine is
specified). The vendor cares only that the workflow is executed (e.g. by
the script it provided); it is opaque to the orchestrator, whio just has to
execute the script. ANY orchestrator can do that, does not need to know how
to interface with any external systems - or, if it has to, it is left to
the implementation.
2. the other option is for the vendor to specifically indicate in the
service template that the orchestrator must use BPMN or BPEL or some other
workflow engine. First of all, that implies that the VNF vendor has created
and tested its VNF using sich a workflow engine. I wonder how many VNF
vendors will actually create their VNFs relying on BPMN or BPEL for
executing its deployment and orchestration. I do not know a single vendor
that does that - but perhaps we need to ask VNF vendors themselves, and
include them in this discussion.
More importantly though - imagine that vendor X indicates BPMN, vendor Y
indicates BPEL, vsndor Z indicates Drules, vendor U indicates XACML, vendor
V indicates "my preferred fantastic workflow engine that nobody else is
using because it was invented by me, and attached as an artifact in the VNF
package"). That case forces EVERY orchestrator to be capable of
interactions with EVERY possible workflow engine out there, including some
that it could have never anticipated. Very few, if any, orchestrators can
keep up with such an implementation, because it is unheard of. Nobody would
build it ... because nobody can guarantee that "if they build it, they
(VNFs) will come".

My point is that orchestrator's interaction with external entities, whether
based on a standard spec or not, should be left to implementation, and not
specified in a standard. Once you create in a standard such a precedent, it
is difficult to not perpetually replicate it, because you cannot grant such
lattitude for use case X (e.g. use of BPMN) but not to use case Y (e.g.
BPEL), and then the floodgate is open for everyone to claim "precedence"
and push their preferred external engine into the standard spec. And the
poor standard guys have no standing to stop that, because they already
allowed that once before. And poor orchestrator builders now have the
choice of developing something 5 times more complex than may be needed, or
held in non-compliance to standards.

For practical reasons, may I ask any VNF vendors on this thread (e.g.
Metaswitch) - would they consider including a specific artifact for BPMN
and/or BPEL for their VNF install/un-install, instead of an opaque script
and relying on the TOSCA orchestrator declarative model to decide what
workflow engine (if any) to use?

Best regards,
Michael


On Fri, May 12, 2017 at 6:45 AM, Michael Brenner 
wrote:

> Huabing,
>
> The way you propose it ... you might as well ask the question "why use
> TOSCA at all"? This was one of my points in our discussion last Friday.
> I cannot understand why one tries to cannibalize a good standard that was
> purposefully defined for cloud workloads intent-driven deployment and
> orchestration. TOSCA should be used as it was intended, and take advantage
> of its characteristics, instead of twisted around to fit some existing
> implementation.
>
> Best regards,
> Michael
>
>
> On Fri, May 12, 2017 at 3:39 AM,  wrote:
>
>> Hi Ranny,
>>
>> Thanks for your comments.
>>
>>
>> It's an interesting use case, in my opinion, why not put all these
>> activities into a BPMN workflow, including the creation of VNF, the IP
>> config of the peer physical MME and the port config of the security group,
>> the 

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

[zhao.huabing]

Hi Ranny,

Thanks for your comments.




It's an interesting use case, in my opinion, why not put all these activities 
into a BPMN workflow, including the creation of VNF, the IP config of the peer 
physical MME and the port config of the security group, the parameters exchange 
is supported between different BPMN task nodes. 




OPEN-O has a workflow design tool which can design Lifecycle Management 
workflows for a Network Service. The designer can design a BPMN task to call 
the operation of a tosca node, and an external service as well, including 
Catalog, Inventory(A), NFV-O, VNFM, etc.  So the parameters needed for a 
specific orchestration activity can get from either the BPMN task parameter or 
a service call to an external service. 




For this use case, if we put it in the context of OPEN-O, the creation request 
of VNF is passed to NFV-O by a BPMN task node, which creates VNF and returns 
the IP as an output parameter. The output parameter can be used as an input 
parameter of the next BPMN task node, which uses this parameter to config the 
physical MME, in turn, the output of this task can be passed to the next task 
to config the security group. The actual workflow may have more tasks, 
including the interactions with Catalog(get VNF Package) and Inventory(Update 
the service instance), etc.




Furthermore, normally there're multiple nodes in a network service template, 
OPEN-O use parser to get all the nodes from service template and sort the nodes 
based on their topology dependency and then pass the nodes list to a BPMN loop. 
By this approach, we can see that BPMN is not an opposite of topology driven( 
aka declarative workflow), on the contrary, BPMN can complement and enhance 
declarative approach to include external service as well when needed.




Thanks,

Huabing






Original Mail



Sender:  ＜ranny.ha...@nokia.com＞
To:  ＜na...@gigaspaces.com＞ ＜mich...@gigaspaces.com＞zhaohuabing10201488
CC:  ＜onap-disc...@lists.onap.org＞ ＜onap-tsc@lists.onap.org＞
Date: 2017/05/12 01:52
Subject: RE: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposalat 
OASIS TOSCA WG







Huabing,


 


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


 


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


 


Thanks,


 


Ranny.





 

 
From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Nati Shalom
 Sent: Thursday, May 11, 2017 6:41 AM
 To: Michael Brenner ＜mich...@gigaspaces.com＞ Huabing Zhao 
＜zhao.huab...@zte.com.cn＞
 Cc: onap-discuss ＜onap-disc...@lists.onap.org＞ onap-tsc@lists.onap.org
 Subject: Re: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposal 
at OASIS TOSCA WG


 


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


 


Huabing et al



 


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



 


First i want to clarify what were discussing here right now is not a question 
of declarative vs impressive workflow as it is being coined for some reason.



What were really discussing is whether we use TOSCA as a configuration input or 
as a model that represent a live system and allow continues interaction with 
system through the model e.g. Model Driven.



 


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



 


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



 


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



 


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

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

[liu.junjie2]

Hi

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

Response： Yes, your understanding is correct.




Given now it is already Friday  afternoon in China, shall we target early next 
week?

Response：OK, we can discuss these issues in next week early.



















刘军杰 liujunjie


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













原始邮件



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





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

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

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

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

 Thanks,
Lusheng  

   
 
  Original message 
From: liu.junj...@zte.com.cn
Date: 5/11/17 11:10 PM (GMT-05:00)
To: gilb...@mail.linuxfoundation.org, "GILBERT, MAZIN E (MAZIN E)" 
＜ma...@research.att.com＞
Cc: fu.guangr...@zte.com.cn, onap-tsc@lists.onap.org
Subject: [onap-tsc] 答复: Re:  Proposal for Holmes project

 

Hi


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


 


 


 




 


刘军杰 liujunjie


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





 
 





 










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



 

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

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

putting the correlation engine as a Microservice running in DCAE just 

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

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

with ONAP during both design and runtime.
 







Something to think about.

thanks

mazin 






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

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

Daniel Rose

ECOMP / ONAP

com.att.ecomp

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

Dear all


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


   Holmes is a application that processes events published by managed 
resources or other applications that detect specific conditions. Based on 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Aayush.Bhatnagar]

+1 for the subcommittee formation.


Additional proposal on the deliverables of the architectural subcommittee -


- Create the deployment architecture for ONAP especially for multi-DC VNF 
orchestration. This aspect is important as ONAP components such as the DCAE 
follow an edge-lake architecture which becomes relevant only when we visualize 
a multi-site deployment.


- Define the architectural principles of disaster recovery (DR) orchestrated by 
the MSO and Policy Engine for VNFs.

​


Regards


Aayush


From: onap-tsc-boun...@lists.onap.org  on 
behalf of Alla Goldner 
Sent: Friday, May 12, 2017 10:29 AM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CAF5.A9A66BA0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman ; Christopher Donley (Chris) 
; onap-tsc 
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

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

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

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

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

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

+1  

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

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

Bob,

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

Thanks,
Chris

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

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

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

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

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

Dear TSC,
I'd