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, <[email protected]> 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); [email protected]; > *日期:* 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 <[email protected]> > 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:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Michael Brenner >> *Sent:* 2017年4月26日 11:09 >> *To:* denghui (L) <[email protected]> >> *Cc:* [email protected]; JANA, RITTWIK (RITTWIK) < >> [email protected]>; [email protected] >> >> *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) <[email protected]> >> 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:[email protected]] >> *Sent:* Friday, April 21, 2017 7:14 AM >> *To:* Amir Levy >> *Cc:* JANA, RITTWIK (RITTWIK); Nguyenphu, Thinh (Nokia - US/Irving); >> denghui (L); [email protected]; Nati Shalom; >> [email protected] >> *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" <[email protected]> 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 >> >> >> >> [email protected] +1 408 916 8572 <(408)%20916-8572> >> >> >> >> On Apr 20, 2017, at 10:29 AM, Nguyenphu, Thinh (Nokia - US/Irving) < >> [email protected]> 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:* [email protected] [ >> mailto:[email protected] >> <[email protected]>] *On Behalf Of *denghui (L) >> *Sent:* Thursday, April 20, 2017 3:35 AM >> *To:* denghui (L) <[email protected]>; [email protected]; >> [email protected] >> *Cc:* JANA, RITTWIK (RITTWIK) <[email protected]> >> *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 >> [email protected] >> 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>
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
