Hi Nati
         I believe we can discuss all the possible solutions based on these 
principles. We can discuss it based on ONAP UseCase, evaluate what benefit can 
each solution bring to us, etc.
         Wish to meet you next week.

Best regards

???: Nati Shalom [mailto:natis at gigaspaces.com]
????: 2017?4?26? 22:16
???: Zengjianguo (OSS Design); Lingli Deng; Michael Brenner; denghui (L)
??: JANA, RITTWIK (RITTWIK); onap-discuss at lists.onap.org; onap-tsc at 
lists.onap.org
??: Re: [onap-tsc] [onap-discuss] Modelling discussion on Friday May 5th

Hi Zengjianguo

First of all thanks for the detailed clarification.

I actually tend to agree with most of your description.
We still have some differences on how we view the specific chain of events but 
i'm not sure that its worth spending more time on it.

I think that the important part is that we seem to agree that the general 
direction should be to allow both native workflow as well as BPMN as the 
general direction going forward.

You also seem to confirm that some of the assumptions or limitations that led 
to the choice of technology at the time have changed by now and therefore worth 
revisit. ((decoupling of the components specifically).

I'm not sure if this is covered in the current agenda but if not this is what 
ONAP should be considering IMO.

Nati S.

On Wed, Apr 26, 2017 at 2:09 PM Zengjianguo (OSS Design) <zengjianguo at 
huawei.com<mailto:zengjianguo at huawei.com>> wrote:
Hi Nati
         I am sorry that I can?t agree on that statement:? Open-O took wrt to 
workflow which wasn't based on any technical merit per-se but mostly on 
practical aspects?
         I join the architecture discussion since the beginning of OPEN-O, 
there?s several technical principle for each components selections, all the 
discussion was lead by ARC and Elzur Uri do lots of work in it:
                   1: ?Be Decouple and micro-serviced based? is very important, 
the Selection should not cause us to bind with one special platform/product and 
no other choice, or bind to a large platform that must be integrated before 
provide the required service.
                   2: ?practical or available on time?, yes, it?s principle for 
all open source community.  All selections should be able catch up with our 
deliver plan, don?t lets all others wait for that selection to be mature.
                   3: ?as less effort as possible?,  so that it ?s encourage to 
reuse or interwork with exist product or solution. Don?t re-invent the wheel.

         OPEN-O get alignment on these principle in the pre-meeting in Mar 2 
2016 beijing meeting,  We decide to not develop based on ManageIQ due to 
principle 1. At that time, we agree to use ARIA.
         But in June meeting in Shenzhen, we found ARIA can?t meet principle 1 
too, and ask the Parser to decouple with workflow engine in ARIA.
         After the meeting, we were told that the decouple will take much more 
time than plan, so  we start to find alternative solution according to 
Principle 2, and select WSO2. But all agree that we may use ARIA in R2 if it 
can meet the  requirements of principle 1.

Although OPEN-O may be young, it?s very successful in the history of LF, I 
think these principle can be apply to ONAP too. ?Support native TOSCA workflow? 
is good idea, but since BPMN/BPEL is already a mature technology and widely 
used, lots of selection available by now, so my opinions is we can discuss it 
base on those principles.

Best regards

???: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at 
lists.onap.org> [mailto:onap-tsc-bounces at 
lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org>] ?? Nati Shalom
????: 2017?4?26? 17:06
???: Lingli Deng; Michael Brenner; denghui (L)
??: JANA, RITTWIK (RITTWIK); onap-discuss at lists.onap.org<mailto:onap-discuss 
at lists.onap.org>; onap-tsc at lists.onap.org<mailto:onap-tsc at 
lists.onap.org>
??: Re: [onap-tsc] [onap-discuss] Modelling discussion on Friday May 5th


Lingli

I think that you omitted an important fact.

The workflow proposal in TOSCA 1.1 is based on native workflow which is similar 
to what Aria and Cloudify use and extend upon it.

There is an on going open discussion to use a delegate model to allow other to 
"delegate" the workflow from TOSCA to external workflow but that is not yet 
decided and would only be included in future versions of the spec. In any case 
the TOSCA spec support both options so a degree of preference to the native 
option.

I really don't see how we can have an *open* discussion on modeling without 
presenting at least both options and i'm concerned that the way this topic is 
presented in the agenda is therefore already biased toward a certain direction 
and doesn't encourage a real open discussion on this subject.

Michael Brener tried to provide a balanced view on the history and evolution of 
Workflows in TOSCA vs Similar 
DSLs<http://cloudify.co/brochures/tosca-workflows-Apr-2017.pdf> in his paper 
which was also shared with the OASIS community. I think that it could serve as 
a good background to the topic.


Lingli you also made the following comment which i found to be inaccurate at 
best.

" native workflow proposed by gigaspaces was turned down by the consensus of 
the OPENO  community,"

There was practical reasons for taking the direction that Open-O took wrt to 
workflow which wasn't based on any technical merit per-se but mostly on 
practical aspects (which is a fair consideration). There was already existing 
investment in other workflow engine as part of the seed code and there was 
preference to use that as a first choice given the aggressive timeline of the 
first release.

There was never a decision NOT to use native-workflow as been suggested or any 
technical argument that was associated with this decision or direction.
As Brian mentioned other projects that didn't had that same constraints took a 
different direction  and as i mentioned above the TOSCA spec itself took that 
similar direction as well.

One last non related comment

You and others are referring to the discussion and decisions in Open-O 
interchangeably as if it represent a well thought standard process or an 
community led process.
While i think that Open-O was founded with that intent in mind it was still 
fairly young community and didn't reached the level of maturity of a real open 
community and therefore i would encourage people  in ONAP to look more 
consciously and do more fact checking whenever this reference is brought up as 
an argument in a discussion.

I think that as we evolve with ONAP community we should be more open minded and 
inclusive in considering other alternatives even to things that were previously 
decided in previous related projects and make sure that the decision and 
discussion serve best the current project goal as many of the consideration and 
constraints of those previous projects are not relevant anymore.
This is specifically true as we move toward more cloud-native, dev-ops and 
container based approach.

Nati S.










On Wed, Apr 26, 2017 at 9:10 AM Lingli Deng <denglingli at 
chinamobile.com<mailto:denglingli at chinamobile.com>> wrote:

Hi Michael,

You may consult your gigaspace's colleage, as my recollection, native workflow 
proposed by gigaspaces was turned down by the consensus of the OPENO  
community, we decided to use BPMN/BPEL type of workflow, you can also find out 
the workflow in MSO /APPC of OPENCOMP are also using BPMN/DG
Thanks,
Lingli

From: onap-discuss-bounces at lists.onap.org<mailto:onap-discuss-bounces at 
lists.onap.org> [mailto:onap-discuss-bounces at 
lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of 
Michael Brenner
Sent: 2017?4?26? 11:09
To: denghui (L) <denghui12 at huawei.com<mailto:denghui12 at huawei.com>>
Cc: onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>; JANA, 
RITTWIK (RITTWIK) <rjana at research.att.com<mailto:rjana at 
research.att.com>>; onap-discuss at lists.onap.org<mailto:onap-discuss at 
lists.onap.org>

Subject: Re: [onap-discuss] Modelling discussion on Friday May 5th

But no TOSCA native workflows ... why?
Michael

On Tue, Apr 25, 2017 at 8:03 PM, denghui (L) <denghui12 at 
huawei.com<mailto:denghui12 at huawei.com>> wrote:
Hi Michael,

Thanks for your suggestion, workflow is already covered in the Shitao?s 
session, they will discuss

1)       OPENCOMP Workflow

2)       OPEN-O Workflow.

Best regards,

DENG Hui

From: Michael Brenner [mailto:michael at 
gigaspaces.com<mailto:mich...@gigaspaces.com>]
Sent: Friday, April 21, 2017 7:14 AM
To: Amir Levy
Cc: JANA, RITTWIK (RITTWIK); Nguyenphu, Thinh (Nokia - US/Irving); denghui (L); 
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>; Nati 
Shalom; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>
Subject: Re: [onap-discuss] Modelling discussion on Friday May 5th


I'll be happy to attend and take part in the discussion and would like to 
suggest to add workflows to the agenda ...a topic which I offer to moderate.
Best regards,
Michael
On Apr 20, 2017 4:51 PM, "Amir Levy" <amir at gigaspaces.com<mailto:amir at 
gigaspaces.com>> wrote:
Thanks DENG for leading this initiative.

I would love to share few quick links to prepare for this meeting:

We have a two parts video that provides TOSCA in practice training : Part 1: 
https://www.youtube.com/watch?v=aMkqLI6o-58 and  
https://www.youtube.com/watch?v=6xGmpi--7-A

And Michael Brenner for ETSI/NFV and TOSCA has recently drafted a in-depth 
comparison between model-driven and task-driven workflows: 
http://getcloudify.org/brochures/tosca-workflows-Apr-2017.pdf

? amir

amir at gigaspaces.com<mailto:amir at gigaspaces.com> +1 408 916 
8572<tel:(408)%20916-8572>

On Apr 20, 2017, at 10:29 AM, Nguyenphu, Thinh (Nokia - US/Irving) 
<thinh.nguyenphu at nokia.com<mailto:thinh.nguyenphu at nokia.com>> wrote:

Hi Rittwik and DENG,

Is modeling discussion covering network service and VNF descriptors? Or it is 
broader to cover all of the ONAP functions?

Yes, I am planning to attend.

Thinh

From: onap-discuss-bounces at lists.onap.org<mailto:onap-discuss-bounces at 
lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of 
denghui (L)
Sent: Thursday, April 20, 2017 3:35 AM
To: denghui (L) <denghui12 at huawei.com<mailto:denghui12 at huawei.com>>; 
onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>; onap-discuss at 
lists.onap.org<mailto:onap-discuss at lists.onap.org>
Cc: JANA, RITTWIK (RITTWIK) <rjana at research.att.com<mailto:rjana at 
research.att.com>>
Subject: [onap-discuss] Modelling discussion on Friday May 5th

Hello all

We are happy to let you know that we are hosting a modeling session on Friday, 
May 5th, AT&T Lab.
9:00-10:30 Shitao moderate: TOSCA NFV Profile
10:30-12:00 Rittwik moderate: AT&T Parser
13:30-16:00 DengHui moderate: Modelling & Opendeployment

Please kindly help to let us know if you are interested in joining us, so that 
we can book a proper meeting room for our discussion

Best regards,

Rittwik & DENG Hui
_______________________________________________
onap-discuss mailing list
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss




--
Michael Brenner, Chief Architect NFV

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

________________________________

M: +1-732-895-5772<tel:(732)%20895-5772>

http://getcloudify.org<http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar>

@cloudifysource

[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/2fb5e7413e7dbeee3e88676333b65c05237ec13d3512e4a63ebc1b5f85bfb917.png]<https://twitter.com/CloudifySource>
  
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/16b91ab7a91bb3a298f2a322640bebb3754357f93e9f20ff50d2c94bb82b1814.png]
 <https://www.linkedin.com/company-beta/17918192/>   
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/6f7421bc5b9a93a0649735bbc8589b200c678bf08af9d7e0cebf1b3cffcdac94.png]
 <https://github.com/cloudify-cosmo>   
[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/4be4d1377f4c1afe70a25e78926b6aad4e0a4fb1d45a7727e31d5a807eb3aae7.png]
 <https://www.youtube.com/cloudifysource>



[https://storage.googleapis.com/signaturesatori/customer-C00h6qxzk/images/-218433c43f71db1180fd27884e3650b01b94c578c594b32c6f49c3daa3151366.png]<http://getcloudify.org/webinars/the-new-cloudify-4.html?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar>

_______________________________________________
onap-discuss mailing list
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170427/a1b68190/attachment-0001.html>

Reply via email to