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> 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] *?? *Nati Shalom > *????:* 2017?4?26? 17:06 > *???:* 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 > > > > > > 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> > 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] *On Behalf Of *Michael Brenner > *Sent:* 2017?4?26? 11:09 > *To:* denghui (L) <denghui12 at huawei.com> > *Cc:* onap-tsc at lists.onap.org; JANA, RITTWIK (RITTWIK) < > rjana at research.att.com>; 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> 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] > *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; Nati Shalom; > 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> 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 +1 408 916 8572 <(408)%20916-8572> > > > > On Apr 20, 2017, at 10:29 AM, Nguyenphu, Thinh (Nokia - US/Irving) < > 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 > <onap-discuss-bounces at lists.onap.org>] *On Behalf Of *denghui (L) > *Sent:* Thursday, April 20, 2017 3:35 AM > *To:* denghui (L) <denghui12 at huawei.com>; onap-tsc at lists.onap.org; > onap-discuss at lists.onap.org > *Cc:* JANA, RITTWIK (RITTWIK) <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 > https://lists.onap.org/mailman/listinfo/onap-discuss > > > > > > > > -- > > *Michael Brenner, **Chief Architect NFV* > > ------------------------------ > > M: +1-732-895-5772 <(732)%20895-5772> > > http://getcloudify.org > <http://getcloudify.org?utm_source=signaturesatori&utm_medium=email&utm_campaign=Cloudify%204.0%20Webinar> > > @cloudifysource > > <https://twitter.com/CloudifySource> > <https://www.linkedin.com/company-beta/17918192/> > <https://github.com/cloudify-cosmo> > <https://www.youtube.com/cloudifysource> > > > > <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 > https://lists.onap.org/mailman/listinfo/onap-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-tsc/attachments/20170426/fbc1037b/attachment-0001.html>
