Dear Huabing, As I explained a few days ago - you can achieve everything you want with the current spec. You do not need any special extension to do exactly what you want, including running a BPMN workflow. However, if you want to build a standard extension it has to be good enough to not handicap any implementation - not one that is only favorable to a particular implementation. Your current proposal may be perfect to support what you want to achieve, but it falls short for what others want to achieve with the same specification. Standards are build by communities to serve broad implementations. A TOSCA-based orchestrator that uses intent modelling (and that was TOSCA's intent all along), does not know how to recover using your proposal, after (or while) the imperative workflow in BPMN is executed. Once I can see a complete extension proposal, or at least a descritption that becomes part of the spec regarding the complete behaviour, there would no longer be a reason for us to have this debate.
Regards, Michael On Mon, May 15, 2017 at 10:46 PM, <[email protected]> wrote: > Hi Michael, > > > "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." > > > You're claiming that some Orchestration implementation is "TOSCA-based > Orchestrator" and others are not. And the criteria you're using to tell > whether an Orchestration implementation is a "TOSCA-based Orchestrator" is > if the LCM workflow of the orchestrator is declarative(Topology driven). > > > Firstly, the TOSCA Specification doesn't restrict the implementation of > orchestrator as long as " it can interpret a TOSCA service template or a > TOSCA CSAR in order to instantiate and deploy the described application in > a Cloud", no matter the workflow is implemented by Python(Aria is that > case), BPMN or any other language. > > - TOSCA Simple Profile in YAML Version 1.1 1.3 implementation > > > Secondly, TOSCA Specification also think that some complex use cases can't > be solved by declarative workflow, that's why TOSCA define a new imperative > workflow language in the V1.1 specification. But the language has some > limitation. For example, what about long-running processes? Such as > monitoring the application. What about human tasks? What about complex > fault handling? What about reversing actions (compensation!)? This is all > possible with BPEL and BPMN engines. > > > Thirdly, As I have pointed out in my previous mail, the orchestrator > implementation with BPEL/BPMN(OPEN-O is a good example) can be topology > driven as well. We can combine declarative and imperative provisioning > using BPMN/BPEL which can resolve drawbacks and to profit from benefits of > both worlds. There is an academic paper presents a means to do that, we > have done similar in OPEN-O. > > > Breitenbücher, Uwe et al.: Combining Declarative and Imperative Cloud > Application Provisioning based on TOSCA. In: Proceedings of the IEEE > International Conference on Cloud Engineering (IC2E), 2014. > > http://www.iaas.uni-stuttgart.de/RUS-data/INPROC-2014-21%20- > %20Combining%20Declarative%20and%20Imperative%20Cloud% > 20Application%20Provisioning%20based%20on%20TOSCA.pdf > > > In conclusion, OPEN-O is a "TOSCA-based Orchestrator" which is ETSI MANO > complied with the ability to allow vendors to bring their VNFs in with VNFM > and it use Inventory(counterpart of A&AI in OpenECOPM) to storage and > manipulate the instance model. The Inventory API is called to update the > instance model in the workflow activities, so this approach do "return to > the TOSCA". So the request to take alternative workflows such as BPMN/BPEL, > etc. which had been supported in TOSCA v1.0 back to TOSCA is reasonable. > > > Thanks, > > Huabing > Original Mail > *Sender: * ＜[email protected]＞; > *To: *mengzhaoxing10024238; > *CC: * ＜[email protected]＞;zhaohuabing10201488; ＜ > [email protected]＞; ＜[email protected]＞; > *Date: *2017/05/13 01:08 > *Subject: **Re: Re: [onap-tsc] [onap-discuss] [modeling] TOSCA > BPMNsupportproposal 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 ＜[email protected]＞ > 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, ＜[email protected]＞ 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 >>> >>> >>> >>> 原始邮件 >>> *发件人：* ＜[email protected]＞; >>> *收件人：* ＜[email protected]＞;赵化冰10201488; >>> *抄送人：* ＜[email protected] <[email protected]>＞; ＜ >>> [email protected]＞; >>> *日 期 ：*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 ＜[email protected]＞ >>> 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 compatibility to TOSCA 1.0, it >>>> only has to do with supporting "facts on the ground/existing >>>> implementations". We should get this agreed once for all, and it became >>>> obvious in ONAP's Friday modeling discussion. >>>> >>>> It also became clear that some of these "facts-on-the-ground" use TOSCA >>>> in a limited way. This is OK, and I have no issue with that. I can support >>>> in TOSCA TC to find the right mechanism to delegate externally, but only if >>>> we do it in a way that is complete: that means we need to not only specify >>>> how to "get out of TOSCA" but also has to include how to "get back to >>>> TOSCA", and "what is the TOSCA orchestrator supposed to do after it >>>> delegates externally". I suggest we work jointly to resolve these issues. >>>> >>>> Further, your claim that I am the only one opposing the half-way >>>> solution on the table is incorrect, and you know it. Luc Boutier in the >>>> TOSCA TC is also vehemently opposed, and partly at least for the same >>>> reasons as those quoted by me. >>>> >>>> It would be great if we stop making unfounded claims in one community, >>>> by quoting only partially what happens in another community, and it would >>>> be better to focus joint energy to resolve the issue in a consistent and >>>> complete technical manner in the TOSCA TC. Please realize that you >>>> absolutely CANNOT resolve TOSCA TC discussions/debates in the ONAP >>>> community alone, and this is not the appropriate way for you to convince me >>>> to drop my opposition in TOSCA TC. >>>> The right way to have me support this is by resolving the technical >>>> issues that I raised. >>>> >>>> Best regards, >>>> Michael >>>> >>>> On Wed, May 10, 2017 at 3:16 AM, ＜[email protected] >>>> <[email protected]>＞ wrote: >>>> >>>>> Hi Amir and all, >>>>> >>>>> Both OPEN-O and OpenECOMP have used TOSCA for service topology >>>>> modelling and BPMN/BPEL for lifecycle management process modelling. After >>>>> the merger, ONAP will inherit the existing codes from OPEN-O and OpenECOMP >>>>> and continue to use BPMN/BPEL in SO/VF-C. >>>>> >>>>> However, I noticed that TOSCA has removed the support for BPMN/BPEL in >>>>> v1.1[1] which is recommended in the Topology and Orchestration >>>>> Specification for Cloud Applications Version 1.0[2]. >>>>> >>>>> This incompatible change of TOSCA specification may cause >>>>> unpredictable effects to existing opensource projects, in particular, the >>>>> ONAP, which have already adopted BPMN as its lifecycle management process >>>>> modelling. >>>>> >>>>> To harmonize the opensource and standards, I am co-proposing a >>>>> proposal[3] with Lingli(CMCC), Claude(AT&T) and Shitaoto(Huawei) to >>>>> suggest >>>>> OASIS TOSCA revert standard workflow DSLs support such as BPMN/BPEL in the >>>>> next version of simple YAML specification.. >>>>> >>>>> 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. >>>>> >>>>> I think this proposal is for the best interest of ONAP community, so >>>>> I'm writing this mail to solicit supports from Gigaspaces and all the >>>>> other >>>>> community members who are both in ONAP and OASIS TOSCA WG. >>>>> >>>>> >>>>> [1] http://docs..oasis-open.org/tosca/TOSCA-Simple-Profile- >>>>> YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html >>>>> <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html> >>>>> >>>>> [2] http://docs.oasis-open.org/tosca/TOSCA/v1..0/TOSCA-v1.0.html >>>>> <http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html> >>>>> >>>>> [3] https://www.oasis-open.org/apps/org/workgroup/tosca/download >>>>> .php/60604/Issue_TOSCA318_Lack%20of%20BPMN%20BPEL%20support- >>>>> v-2017-04-25.pptx >>>>> <https://www.oasis-open.org/apps/org/workgroup/tosca/download..php/60604/Issue_TOSCA318_Lack%20of%20BPMN%20BPEL%20support-v-2017-04-25.pptx> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Huabing >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> onap-discuss mailing list >>>>> [email protected] >>>>> https://lists.onap.org/mailman/listinfo/onap-discuss >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>>> [email protected] <[email protected]> >>>> https://lists.onap.org/mailman/listinfo/onap-tsc >>>> >>> >>> >>> >> >> >> -- >> 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 [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
