Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal at OASIS TOSCA WG
Just to chip in my perspective on this “Rome” discussion, It is not about what “works very well now” and what doesn’t. Both approaches may very well work now. The BPMN approach apparently worked well in Open-O and I can attest that in Nokia we successfully delivered working EPC and VoLTE solutions using a commercial product that uses TOSCA as the master template, with callouts to an external workflow engine (OpenStack Mistral in our case). You are welcome to read about it here<https://tools.ext.nokia.com/asset/200827>. The suggested approach of having BPMN as the master execution workflow and keeping TOSCA as just the topology store makes little sense to me. The use of TOSCA in this case will be merely a fig leaf and we may be better off without it. Other than having an existing implementation, what are the other merits of BPMN over TOSCA as the master plan? Regards, Ranny. From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Michael Brenner Sent: Friday, May 12, 2017 10:08 AM To: meng.zhaoxi...@zte.com.cn Cc: onap-discuss <onap-disc...@lists.onap.org>; onap-tsc@lists.onap.org Subject: Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal 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 <mich...@gigaspaces.com<mailto:mich...@gigaspaces.com>> 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, <meng.zhaoxi...@zte.com.cn<mailto:meng.zhaoxi...@zte.com.cn>> 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 ti
Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal 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 <mich...@gigaspaces.com> 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, <meng.zhaoxi...@zte.com.cn> 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 >> >> >> >> 原始邮件 >> *发件人：* ＜na...@gigaspaces.com＞; >> *收件人：* ＜mich...@gigaspaces.com＞;赵化冰10201488; >> *抄送人：* ＜onap-disc...@lists.onap.org＞; ＜onap-tsc@lists.onap.org＞; >> *日 期 ：*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
Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal at OASIS TOSCA WG
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, <meng.zhaoxi...@zte.com.cn> 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 > > > > 原始邮件 > *发件人：* ＜na...@gigaspaces.com＞; > *收件人：* ＜mich...@gigaspaces.com＞;赵化冰10201488; > *抄送人：* ＜onap-disc...@lists.onap.org＞; ＜onap-tsc@lists.onap.org＞; > *日 期 ：*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
