Not sure I follow your logic. The support for BPEL/BPMN was flawed in TOSCA 1.0 .. are you saying that the reason for supporting your proposal is because something similar existed in TOSCA 1.0? How can this be a good argument: to bring such flawed support forward in TOSCA 1.x YAML version? I was not involved at the time in TOSCA work, neither was I during the transition to YAML. But I have to give credit to those that were involved that decided to NOT bring forward a flawed, inconsistent and incomplete mechanism for handling workflows.
We can agree that there may be a need for cooperation between a TOSCA-based orchestrator with external workflow engines; there may be real use cases that may require that. My point remains that there is no need to reflect this in the TOSCA standard. But I could support reflecting such cooperation in the TOSCA standard if we were to offer a complete/consistent cooperation solution. That is not the case with the current proposal, and that is the reason for me not supporting the current proposal. Best regards, Michael On Thu, Apr 27, 2017 at 10:38 PM, <zhao.huab...@zte.com.cn> wrote: > Hi Michael, > > > I'm glad that we have reached agreement on the necessity of the > cooperation between TOSCA and the standard workflow DSLs. > > Actually we are not "changing" TOSCA but bringing back what had been > supported before the v1.1 workflow modification which make TOSCA completed. > > TOSCA ideally should have both the topology model and the process model to > facilitate the orchestration, and NFV is an important greenfield for > TOSCA in Telecom industry, so if proces model is missing for general NFV > use cases, seems to me it is incompleted. > > So the debate rasing out is should we limited TOSCA only on some specific > use cases which can be done by the declarative workflow/ internal > imperative workflow, or we want to embrace broader domain with more general > use cases? I believe the intention of TOSCA is the later one. > > > Thanks, > Huabing > > > > > > Original Mail > *Sender: * ＜mich...@gigaspaces.com＞; > *To: *zhaohuabing10201488; > *CC: * ＜denglin...@chinamobile.com＞; ＜onap-disc...@lists.onap.org＞; ＜ > rj...@research.att.com＞; ＜onap-tsc@lists.onap.org＞; > *Date: *2017/04/28 02:05 > *Subject: **Re: 答复：Re: [onap-tsc] [onap-discuss] Modelling discussion on > Friday May 5th* > > > Hi Huabing, > I think you still don't understand my main point - since you are trying to > convince me of something I already accept: the fact that certain workflows > may not be easily solvable "within TOSCA" and therefore need external > workflow engine help. > > My main point is that in order to leverage those external workflow engines > for what they do best, we do not need to make changes to the TOSCA > standard. But, if we do decide that we want changes to the TOSCA standard, > we should be careful to provide changes that make the standard > consistent/complete and overall better, rather than weaker. The current > proposal does not make the TOSCA standard consistent/complete/better wrt > workflows, but achieves rather the contrary effect - allows for too many > interpretations regarding the "contract" between a TOSCA-consuming > orchestrator and the external workflow engine it delegates the work to. If > we could solve all those issues before pushing them into the TOSCA > standard, I would have no objections. > > Getting back to what you are trying to achieve - i.e. leverage BPEL/BPMN > in ONAP (like in Open-O, or otherwise) - this is a discussion to take place > in ONAP; the same is true for a discussion of what the role of TOSCA is in > ONAP. > > I think we get into these debates here because we are conflating standards > approaches with implementations needs, and more often than not, complete > implementations/solutions should not be part of a standard, or at least not > part of the SAME standard. Standards are best when they have a clear > boundary of the domain they cover, and the smaller the domain, the more > granular the standard, and the better the standard. > > Best regards, > Michael > > On Thu, Apr 27, 2017 at 1:53 PM, ＜zhao.huab...@zte.com.cn＞ wrote: > >> Hi Michael, >> >> As far as I know, besides GSO, NFVO also uses BPEL, I'm not aware of any >> use of other workflow both . >> >> The main reason is that they don't have the capability to support the >> OPENO use case. >> >> The declarative workflow is suitable for simple scenarios,but it can't >> meet most of the requirements of Telecom cloud service, which is usually >> across multiple data center and need interactions with entities outside of >> the TOSCA service template. >> >> For example, when carriers deploy the vCPE service for a residential >> subscriber, the user plan vnf, such as VSTB, should be located in the data >> center which is the most close to the user to minimize latency. To achieve >> that, the workflow need to ask a placement service which know the resource >> and geographic info of all the data centers to get the best placement >> location to create the vnf. >> >> It's a very common use case for NFV, Neither declarative workflow nor the >> imperative workflow inside TOSCA can accomplish this job because obviously >> the global placement service is an external service out of TOSCA template, >> so it can't be invoked by the declarative or internal workflow of TOSCA. It >> can't be implemented as a node operation as well because the node operation >> is provided by vnf vendor, who have no idea of the Orchestration system >> components. >> >> Thanks, >> Huabing >> >> 原始邮件 >> *发件人:* MichaelBrenner; >> *收件人:*Lingli Deng; >> *抄送:*onap-discuss; JANA,RITTWIK (RITTWIK); onap-tsc@lists.onap.org; >> *日期:* 2017-04-27 00:58:12 >> >> *主题:Re: [onap-tsc] [onap-discuss] Modelling discussion on Friday May 5th* >> >> >> >> Lingli, all: >> >> I though we are now discussing ONAP and how to improve it, and not Open-O? >> >> >> Furthermore, ONAP is indeed using BPEL/BPMN workflows, but that is as >> part of the MSO. MSO may decide to delegate certain portion of the >> orchestration to a TOSCA-based orchestration engine, and what is delegated >> to such engine may have to use its own internal/native workflows. >> The real question here is: are we trying to leverage the best of all we >> have available, or are we trying to keep replicating the status-quo >> forever. Regardless of the answer, I find it that it is a very narrow >> perspective if we only want to discuss workflows in the context of what was >> implemented initially in Open-O or ECOMP, instead of opening a broader >> discussion of what makes sense where in the overall architecture. >> >> >> Best regards, >> Michael >> >> >> >> >> >> On Wed, Apr 26, 2017 at 2:10 AM, Lingli Deng ＜ >> denglin...@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-boun...@lists.onap.org [mailto: >>> onap-discuss-boun...@lists.onap.org] *On Behalf Of *Michael Brenner >>> *Sent:* 2017年4月26日 11:09 >>> *To:* denghui (L) ＜denghu...@huawei.com＞ >>> *Cc:* onap-tsc@lists.onap.org; JANA, RITTWIK (RITTWIK) ＜ >>> rj...@research.att.com＞; onap-disc...@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) ＜denghu...@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: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-disc...@lists.onap.org; Nati Shalom; >>> onap-tsc@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" ＜a...@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 >>> >>> >>> >>> a...@gigaspaces.com +1 408 916 8572 <(408)%20916-8572> >>> >>> >>> >>> On Apr 20, 2017, at 10:29 AM, Nguyenphu, Thinh (Nokia - US/Irving) ＜ >>> thinh.nguyen...@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-boun...@lists.onap.org [ >>> mailto:onap-discuss-boun...@lists.onap.org >>> <onap-discuss-boun...@lists.onap.org>] *On Behalf Of *denghui (L) >>> >>> *Sent:* Thursday, April 20, 2017 3:35 AM >>> *To:* denghui (L) ＜denghu...@huawei.com＞; onap-...@lists.onap..org >>> <onap-tsc@lists.onap.org>; onap-disc...@lists.onap.org >>> >>> *Cc:* JANA, RITTWIK (RITTWIK) ＜rj...@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-disc...@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> >>> >>> >>> >> >> >> >> -- >> >> Michael Brenner, Chief Architect NFV >> ------------------------------ >> M: +1-732-895-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> >> >> >> >> > > > -- > Michael Brenner, Chief Architect NFV > ------------------------------ > M: +1-732-895-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> > > > > > -- Michael Brenner, Chief Architect NFV ------------------------------ M: +1-732-895-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-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
