OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] 答复:Re: [tosca] Re: 答复: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded


Hi Huabing,

 

I have not seen in your use-case (which BTW has never been detailed. My understanding is that you just said: we should ask a component before being able to process the next component and that is something the workflow dsl can do…). So please if you want to bring up a use-case please do so but bring all information. This include the BPMN workflow, schema of the workflow and highlight of the specific part that in your opinion cannot be moved to 1.1. workflow and what exactly is missing.

 

You cannot speak of “bringing back to what had been supported” has nothing was clearly defined and certainly not at all in a portable way. In the previous spec while BPMN and BPEL where mentioned as possible choices for workflows and things to look in the future they were not specified as must and so any language of anything can be taken here. And many implementers made their own choices before reaching a consensus on something adapter to TOSCA and portable.

I fully agree that the XML spec however was really misleading.

 

Now if we want to move forward rather than just saying the same thing over again I would like that we try to clearly answer these two questions:

·         What exactly is missing in 1.1. workflow spec and how can we improve it, both from imperative and declarative point of view.

·         How to support any other kind of artifacts to perform operations on multiple nodes while providing a clear output back to the orchestrator so he can perform TOSCA orchestration on other nodes that may interact with them and then that he can run potential other workflows on these nodes providing the right inputs etc.

 

I think that this is critical to answer these two elements and especially the second point if we want to include any elements that are today not well defined and to add them while making the standard stronger rather than adding them to make the standard weaker. Note that anything that would be added without clear specification will imply some misleading elements that some implementers may decide to support in their own personal way and then claim that we should keep them forever for backward compatibility purpose

 

On the political side, as long as the technical issues are not resolved, what the TC has clearly to answer is:

·         Do we consider that a standard is stronger by increasing the portability and interoperability or by allowing everybody to do things that are not specified and make all the other work not portable anymore? Note that this may goes beyond workflow because if we accept adding support for specific keywords to run anything for workflows and loose interoperability here, why not indeed add some keyword for UI elements and plenty of other stuff…

 

Luc

 

From: "zhao.huabing@zte.com.cn" <zhao.huabing@zte.com.cn>
Date: Friday, 28 April 2017 at 04:48
To: "michael@gigaspaces.com" <michael@gigaspaces.com>
Cc: Luc Boutier <luc.boutier@fastconnect.fr>, shitao li <lishitao@huawei.com>, Chris Lauwers <lauwers@ubicity.com>, Matthew Rutkowski <mrutkows@us.ibm.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca]
答复:Re: [tosca] Re: 答复: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded

 

Hi Michael,

 

I'm glad that we have reached agreement on the necessity of the cooperation between TOSCA and the standard workflow DSLs.  

 

What I mentioned before is not a "special" or "particular" use case, it's a very very normal use case in Telecom cloud. Actually we are not "changing" TOSCA but bringing back what had been supported before the v1.1 workflow modification which make TOSCA completed and more powerful.

 

TOSCA ideally should have both the topology model and the process model to facilitate the orchestration,  since NFV is an important greenfield for TOSCA in Telecom industry, so if proces model to support NFV 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 by incorporating mature standard workflow? I believe the intention of TOSCA is the later one.



Thanks, 
Huabing

Original Mail

Sender:  michael@gigaspaces.com;

To: zhaohuabing10201488;

CC:  luc.boutier@fastconnect.fr; lishitao@huawei.com; lauwers@ubicity.com; mrutkows@us.ibm.com; tosca@lists.oasis-open.org;

Date: 2017/04/27 22:56

Subject: Re: [tosca] 答复:Re: [tosca] Re: 答复: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded

 

Huabing,

It is possible that there are complex cases where a declarative TOSCA workflow may not work - although if we have not tried, we can't really say that it does or does not.

Regardless, I think you are missing the point that I have made repeatedly. And that is: I am not against using "what works/best-in-class" to solve particular issues (e.g. use of BPEL/BPMN for what it is best-in-class). But not every use of best-in-class products requires the backup of a standard (e.g. backup in TOSCA). The reason to include something in a standard (even that not always) may be because there is a consistent standard way that ensures portability/inter-operability. The current proposal simply does not do this - since it is incomplete, and cause more problems than it solves.

 

It has the feel that there is attempt to standardize an incomplete solution, for the sole reason that those that have systems supporting that solution can claim that they are compliant with some standard. This is what I call "rubber-stamping a solution". Typically standards bodies that want to build solid standards via consensus tend to shy away from doing that.

 

Honestly I am at a loss why anyone would want to make a standard weaker, by allowing just the tip of the iceberg of a potential solution into the standard, and leaving the implementer scratching their heads about how to implement what is required to make the solution work in a portable/inter-operable manner.

 

Michael

 

On Thu, Apr 27, 2017 at 10:32 AM,  zhao..huabing@zte.com.cn wrote:

Hi Michael and all,

The workflow is for the whole service template, not part of it, so the approach you mentioned is not feasible.  

The declarative workflow is suitable for simple scenarios,but it can't meet requirements of more complex cloud service.  
For example, when carriers deploy the vCPE service for a residential subscriber, the user plan vnf 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, and it can't be implemented as a node operation because the node operation is provided by vnf vendor, who have no idea of the Orchestration system components.

I hope this concrete use case help us better understand the use and limitation of different approaches and realize that powerful standard workflow DSL such as BPMN or BPEL is a must right now.

Thanks,
Huabing

原始      

发件人:       MichaelBrenner;      

收件人:BOUTIER, LUC;

抄送:Lishitao; Chris Lauwers; Matt Rutkowski; 赵化冰10201488; tosca@lists.oasis-open.org;

日期:       2017-04-27 20:48:56      

:Re: [tosca] Re: 答复: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded      

 

Well said Luc (and 2 voices are better than one, even if still lonely).. Vendors will adapt to the situation, no matter what the spec says - since products really have to work, even if the spec does not. Deployments will have to decide whether they want to use the strengths of "consistent" TOSCA spec to the full extent (intent/model driven deployment and orchestration), or just as a means to put in place a deployment, and use "inconsistent" portions of potential standard and "delegate and forget" (legacy/task oriented deployment and orchestration) .. Each choice has some implications, pros and cons.I believe the task-oriented approach will anchor us in the legacy approach, and that means difficulty in scaling and in keeping states in sync. But solutions have been developed for those issues over tens of years, and some may want to continue down that path. The intent/model driven approach is promising, but critics may say there is not yet enough historical evidence in favor of it - typical for any newer approach.

It really comes down to what philosophy one embraces, and being aware of the pros and cons and having a good way to handle the cons.


     

TOSCA as a spec can go in may directions, but whatever direction we end up going, it should provide consistent/complete mechanisms that support portability and inter-operability. Wrt to what to use where (TOSCA or not TOSCA) - I don't think TOSCA can solve every issue of a large deployment, and neither should it try. But when we choose to use TOSCA as part of a solution, it seems to me that the part of the solution has to be completely under the control of a TOSCA-consuming orchestrator. Whether that portion of a solution is larger or smaller - that is where architects come in to make a solid decision based on pros/cons, and I don't have any preconceived notions.


     

For example, MSO in ONAP does not have to be based on TOSCA (it isn't now). But it may identify actions that are best delegated to a TOSCA-consuming orchestrator. In this case, let that portion be controlled completely by that TOSCA-consuming orchestrator (everything belonging to that sub-domain is fully controlled by TOSCA), and that makes that portion easier to handle as a black box with inputs/outputs, rather than a situation of a spaghetti ball of interactions between multiple systems, where each of the systems takes turns to become the master of the sub-domain.


     

Best regards,

Michael


     
     
     
     


     

On Thu, Apr 27, 2017 at 1:35 AM, BOUTIER, LUC       luc.boutier@fastconnect.fr wrote:      
     

Hi Michael,

 

I fully agree with you and that is exactly what I stressed out in the Tuesday call and I was the one feeling lonely. I also have the sentiment that during the past year we tried to close the gaps and missing elements that existed in the 1.0 yaml spec and 1.0 xml spec that both had not enough elements for interoperability. This goes from detailed (maybe still not enough) information written in the spec on how workflows should be generated and how relationships impact them to how to define workflow in a way that taken as is has all the details on how to execute TOSCA defined in the nodes operations, change node states, get output from the operation (through environment variable and get_operation_output function which we all know is not the most perfect way but that is at least a specified and interoperable way).

 

Some people claim backward compatibility but the truth is that 1.0 XML spec and 1.1 yaml spec are not, and not just about workflows. Parsing is the most obvious but there is actually more than that. Workflow I insist are not part of 1.0 specification, there is just a vague reference that BPML or BPEL COULD be used. But there is no clear specification that this is we way to go. Moreover, there is no specification on how an operation from TOSCA get generated in BPMN, I know some people have made work and extension of BPMN for TOSCA but here again this is not standard stuff neither done in BPMN working groups or TOSCA working groups.

 

I also fully agree that there is interesting work to be done to try to make all initiatives reach a common way but I also think that we should not rush to please people and lose any runtime value of the standard as the result will be that all implementers will have different ways to define things, that we will acknowledge actually not only BPMN but anything ant that if we allow that there will be no way to keep a backward compatibility with everyone AND keep interoperability.

 

As Chris stated we are improving the Operation support so any black-box can be called with a clear contract (as the contract we have with shell script and python that is clear even if not perfect) and in a way that will improve the standard while not reducing its portability (actually this will be the opposite).

 

We can do the same on workflows but as Chris explained this would have to be a next step as it is from a logical point of view and from a TC bandwidth point of view (and actually it should leverage the work started and not completed on operations). So in my opinion we should not keep losing time on having the same workflow discussion that consumed around 3/4 yaml calls while we put on hold the discussions around Artifact support that would make us go forward (both on the immediate operation thing and the potential future extended workflow support).

 

My opinion is that for now vendors that wanted to support non-normative things have custom DSL “close to TOSCA” but not TOSCA, we have one, GigaSpaces has one and I guess that while we don’t support Workflow extensions in a portable way this should be the way to go for vendors clearly marking that this template is not a portable TOSCA template but a Vendor specific “close to TOSCA” template that may have specific requirements on their solution. (for example, tosca_definition_version: my-vendor-dsl-1.0.0).

 

The other option that is the one currently supported by most of people (except Michael and myself if we follow this thread) is that we should acknowledge the fact that TOSCA support calling any kind of workflow that will leave the Orchestrator unaware of anything deployed, whether it is compliant or not with elements defined in the template and that for such use-case the orchestrator is actually not able to orchestrate anything, will not have any knowledge of the elements deployed will not be able to provide any instance model because he won’t know states or attributes of any nodes as there is right now, no ways to feed them. For such use-case the orchestrator will deploy things but won’t be able to make them interoperate with any other TOSCA nodes or deployments as too many information will be missing. In such use-case the TOSCA orchestrator will be no more than executing a command line and providing a schema that may or may not be related to the actual deployment. Note that actually such workflows may have dependencies and potentially on another TOSCA orchestrator. For example, it could refer to Cloudify specific workflow generation language that leverages the Cloudify API so the template will be TOSCA compliant and portable on any TOSCA orchestrator with the requirement to first deploy the required orchestrator. Or I could even from a TOSCA standard template refer to a vendor specific template so it makes it a “portable” TOSCA template.

 

Best regards,

Luc

 

From: tosca@lists.oasis-open.org> on behalf of Michael Brenner <michael@gigaspaces.com
Date: Thursday, 27 April 2017 at 05:27
To: shitao li <lishitao@huawei.com
Cc: Chris Lauwers <lauwers@ubicity.com>, Matthew Rutkowski <mrutkows@us.ibm.com>, Huabing Zhao <zhao.huabing@zte.com.cn>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org
Subject: [tosca] Re:
答复: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded

 

I understand there is a desire to re-use work done via BPEL/BPMN, and have no issue with that.  What I do not understand is why we rush to make a half-standard, when we could support initially an implementation that would do exactly that, without the backing of a standard. Seems like rubber-stamping something that is half-cooked, instead of working through the problems. Not the way good standards are created..

Btw - the backward compatibility however is a red herring issue, since we are talking of quite different 2 specs, and the companies that use BPEL/BPMN workflow engines (for a good reason, solving B2B issues) in fact do not use is with the XML version of TOSCA. We are bound to create a spec that cannot ensure portability and inter-operability, I cannot repeat this enough. This will NOT be a good standard though - since it creates more problems than solutions. 

I would have preferred that the community works to provide a good/complete solution to the problem, rather than introducing partial solutions in the standard. We can live with partial solution in the context of a community (e.g. ONAP) until we implement (there or elsewhere) a complete solution, then go and standardize it.

 

Bottom-line, I cannot support this approach, and at the same time I realize I may be a lonely voice - so the community will decide what it decides. No hard feelings either way:-)

 

Best regards,

Michael

 

 

On Wed, Apr 26, 2017 at 10:19 PM, Lishitao lishitao@huawei.com wrote:

Hi Michael

 

I think the intention here is to support what has already been supported in TOSCA v1.0 that external workflow engine should be allowed in TOSCA. And after several years of publishing the first version of TOSCA standard (since 2013), many TOSCA applications have still chosen to use this mechanism, such as OpenECOMP and Open-O. Some of the issues you mentioned are still there, I agree with it. And now this proposal is just a start, it contains just what TOSCA 1.0 has mentioned, nothing more, and the purpose is for backward compatible. No meter tosca-simple-profile-yaml version 1.0, 1.1 support this or not,  people still use external workflow in there TOSCA applications today. The requirement is there, we cannot just ignore it.

As I said, this proposal is just a start, if we close the door at this moment, it will make the gap between implementation and standard even bigger.

 

Regards

shitao

 

件人: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] 代表 Michael Brenner
时间: 2017427 4:22
收件人: Chris Lauwers
抄送: Matt Rutkowski; Huabing Zhao; tosca@lists.oasis-open.org
: Re: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded

 

Hi Chris,

 

I appreciate the challenges. Let me clarify that I do not discourage the native imperative workflows defined in TOSCA, and I don't think that what I suggest is in conflict with Matt's view. What I am not a big fan of is half-measures that lead to lack of portability/inter-operability ... and that was the main point of my comments.

 

Let me try to parse what I am saying:-)

 

When TOSCA promotes its native (declarative OR imperative workflows), all one describes is the intent at the end of the workflow, and nothing more. I interpret this (and any TOSCA-consuming orchestrator would do the same) that using the service template and the provided artifacts, the TOSCA-consuming orchestrator is able to accomplish the task - and it absolutely does not matter through what mechanism it does so (and that could include the use of BPEL/BPMN by some particular TOSCA-based orchestrator, if that is how it implements workflow). But TOSCA service template in this case is "workflow implementation neutral" (i.e. unaware of the engine, BPEL/BPMN/embedded in the orchestrator, or whatever else you may have) which is in-line with the TOSCA philosophy of under-specifying things (a good principle when it comes to standards that are build to last). It allows ANY orchestrator to fulfill the intent the best way possible, and does not favor or disadvantage one implementation or another. Which makes the spec support portability/inter-operability. And it gets you away from specifying all the complexities I mentioned to make the spec right. Over-standardizing is one the fireproof mechanism to "date" a standard, and it won't last.

 

But if we choose to over-specify (I don't have a Quijotian syndrome:-) then we MUST specify in such a way that the spec continues to be portable/inter-operable - which means that once we go down the slippery slope of explicitly supporting/endorsing external workflow engines, we better specify the mechanism in full, because otherwise we deliberately introduce lack of portability and inter-operability (let aside of delaying implementations or making them more complex than necessary).

 

Do we want to take the red pill or the blue pill?

 

Btw Chris, here is the attached write-up on workflows. By now we have advanced to further analyzing the topic in-depth on this thread and in the TOSCA TC meetings, but I remembered you showed interest a few weeks ago - so I am sharing it here.

 

 

Best regards,

Michael

 

On Wed, Apr 26, 2017 at 2:52 PM, Chris Lauwers lauwers@ubicity.com wrote:

I agree with Michael that our goal should be to strengthen the appeal of TOSCA. But I also agree with Matt that we should be pragmatic about this. The reality we’re faced with is that (as far as I know) there aren’t any interoperable implementations of TOSCA out there today that adopt a truly declarative paradigm. The implementations I’m aware of use TOSCA mostly for modeling but not necessarily for orchestration. Instead, they rely largely on imperative logic (such as the BPNM workflows in Open-O) provided by the service template designer (or worse, hardcoded in the Orchestrator for very specific use cases) to get a TOSCA service model deployed. What we need to get to instead is a “true” TOSCA orchestrator that provides a “TOSCA runtime” that is able to process any standards-based declarative TOSCA service template. Said a different way, we need to get to the point where people use TOSCA for its orchestration features rather than (or in addition to) its modeling features. We’re not quite there yet (although some of us are working on it J )

 

It appears we have differing opinions about the best way to get there. We could try to discourage the “imperative” use of TOSCA (as Michael suggests) with the goal of promoting the declarative paradigm, or we could support it with the goal of getting broader adoption of TOSCA models (as Matt suggests) with the goal of replacing service-specific imperative logic (such as BPMN workflows) with generic declarative support in the Orchestrator over time.

 

Chris

 

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Michael Brenner
Sent: Wednesday, April 26, 2017 7:07 AM
To: Matt Rutkowski
mrutkows@us.ibm.com
Cc: Huabing Zhao
zhao.huabing@zte.com.cn; tosca@lists.oasis-open.org


Subject: Re: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded

 

Hi Matt,

 

Thanks for the feedback, and certainly, I wish too to have been part of the discussion ... it just my wishes/interests and my committed tasks have the tendency to be able to not always coordinate:-). Like for many of us...

I'll do my best to be in other calls dedicated to this topic - but discussing over email, and reaching some tentative agreement on the issues/requirements before you propose solutions, works best for the kind of schedule I have, at least. I think if the requirements are agreed, the solution may be more straightforward to be agreed.

 

Best regards,

Michael

 

On Wed, Apr 26, 2017 at 9:42 AM, Matt Rutkowski mrutkows@us.ibm.com wrote:

Hi Michael,

Wish you had been on the call yesterday (perhaps you can read my meeting notes posted to TOSCA?)...  We touched on most of these issues with Luc echoing many of your thoughts.  

In the end, TOSCA has taken the philosophy of recognizing that exiting providers use existing tooling for installs/configs (including BPEL/BPMN workflows) and that we wanted to embrace these providers and recognize/point out the pitfalls and encourage them (when able) to move to declarative.  In addition, if we can treat these tools (including ansible, or other) as "black boxes" that can return us to a known state (consuming inputs in the model and providing access to outputs) that is the general view of processing.  Of course, we have other proposals for operational "hints" on expected processing time (will not call it timeout) for the orchestrator to gauge how long it should continue.

All agreed, that an instance model/API would be needed to allow full introspection after the "black boxes" complete and that these workflows should not cause changes to the other parts of the topology.  These are all things we will discuss in text.  Please also account for the Artifact Processor entity which will also have information for the orchestrator (for invocation) and can also have properties/configurations, etc.

In addition, we agreed not to call this "delegate" as our existing delegate does not match this behavior proposed.

Can you attend the WG call in subsequent weeks?

Kind regards,
Matt




From:        Michael Brenner michael@gigaspaces.com
To:        Huabing Zhao zhao.huabing@zte.com.cn
Cc:        tosca@lists.oasis-open.org
Date:        04/26/2017 07:57 AM
Subject:        Re: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded
Sent by:        tosca@lists.oasis-open.org

                             


                           




Hi Huabing, all:

I reviewed the proposed changes to support external workflow engines via "delegate" mechanism, and I think this is something that can complement TOSCA in special cases - e.g. re-using workflows previously implemented outside of TOSCA, in particular those requiring interactions between external entities.

The problem that I have is that the current proposal leaves us with many unsolved issue, and renders a TOSCA-consuming orchestrator with more questions than the answers that an external workflow engine can provide. I would prefer us to work on resolving all the issues to provide a workable and portable solution, rather than inserting a half-baked mechanism that we do not know yet how it will converge to the full solution.

Here are some of the issues I observe are unsolved:

1. TOSCA philosophy is to specify "what" (intent) and not "how" (implementation). How a TOSCA consuming orchestrator resolves the TOSCA-driven requirements is typically irrelevant, but the expectation is that the result fulfills the requirements. This philosophy is now infringed by the proposal, because of several issues - see below.
1.a: If we "standardize" the artifact, i.e. have some standard artifact name or suffix that a TOSCA parser needs to recognize, we are going from "what" to "how". And we also create a precedent that would require constant changes - because other such "keynames" will emerge. Perhaps this could be solved with a separate registry, but I don't think it should be standardized as part of the TOSCA spec.
1.b: on the other hand, if the parser does not have a way to identify whom to delegate, it is at a loss about what to do with the artifact. So it is sort of a catch 22 situation.
2. Assuming we find the right solution for 1. above, we still have a major portability issue. Again, typically a TOSCA-consuming orchestrator should not understand/parse the content of the artifacts, but just execute them or pass them along to other artifacts for consumption. The proposal does not specify what the TOSCA-consuming orchestrator is supposed to do with the artifact that is passed to the delegate workflow. And that gets us into a different catch22.
2.a: If the delegate artifact is opaque to TOSCA-consuming orchestrators, 2 different orchestrators may process the artifact quite differently in the best case, or would not know what to do it (beyond parsing) in the worst case. So this requires a clear specification of how the TOSCA-consuming orchestrator is supposed to process the artifact, in order to consistently get the same result. Obviously, that moves us from "what" to "how".
2.b: Assuming there is a good solution to 2.a above, we run into a different issue, and that becomes an implementation and compliance issue. Each TOSCA-consuming orchestrator would have to be able to support the mechanism described for processing the delegate artifact, but for every different artifact (e.g. BPEL vs. BPMN ... and this is just the beginning precedent), the mechanism would have to have specific parts, in addition to the generic parts, most likely. That basically forces a TOSCA-based orchestrator implementation to support in a standard way ANY potential mechanism to delegate to any potential workflow engine. This is not something one should ask a vendor that will be forced into compliance, and it is completely atypical for a standard to ask for this. The solution would be to define a one-time generic mechanism of passing the artifact, regardless of which what external workflow engine is required to process the artifact.
3. TOSCA service template defines a topology, with nodes that have certain states. When control is being passed to the delegated external workflow engine, it is not clear in the proposal what the expectations (and constraints) are with respect to changes to the topology and/or nodes and/or states of the nodes by the external entity. A stable solution would be advantaged by a single source of truth for topology, nodes and states - in this case that source of truth is the TOSCA-consuming orchestrator that implements and maintains the TOSCA service template. That would argue that the delegated workflow engine cannot change topology, nodes or node states? If this is the intent, it should be stated in the changes to the TOSCA spec. If the intent is different (i.g. external workflow engine can change topology, nodes, and their states) then how do we ensure stability of the solution? No mechanism is included in the proposal for communicating back to the TOSCA-consuming orchestrator what has changed and how.

4. That brings us to another general issue. While the proposal attempts to define a mechanism that gives an external entity the delegation to execute a workflow (and I described above why that portion needs more work to ensure portability), the proposal does not address how the control is returned to the TOSCA-consuming orchestrator, neither is it defined when the control is returned. TOSCA-consuming orchestrator is the master/manager of the topology/nodes/states that it deployed or is in course of deploying. It uses the topology and the relationship between nodes to traverse the topology in a certain order, and execute the lifecycle management of the different nodes in the topology based on the declaration of intent in the model.. Therefore, any mechanism delegating work outside the TOSCA-consuming orchestrator is incomplete unless it describes how the control is returned to the TOSCA-consuming orchestrator, and when, and with what results.


On the how/when, I can see several options that would have to be defined:
4. a: delegate and forget. In this case, the TOSCA-consuming orchestrator does not block to wait the result of the external workflow execution, and instead continues to work on implementing the intent described in the service template. No results are expected from the external workflow processing that are needed by the TOSCA-consuming orchestrator to know about.
4.b: delegate and sync up later. This is a similar case as 4.a, but in this case there may be results from the external workflow execution available later on, that are of interest. In this case, a mechanism needs to be defined to allow a TOSCA service template to describe how to wait/block for those results later on.
4.c: delegate and wait/block indefinitely. In this case, as soon as TOSCA-consuming orchestrator delegates a workflow externally, it would stop executing any further, and wait for the workflow to complete and return control - possibly with results.
4.d: delegate and wait/block for a period of time. This is similar to 4.c above, but a timer is associated, and if the external workflow engine does not return control to the TOSCA-based orchestrator within the defined time interval, the latter will continue execution. A further option would be to add also the mechanism described in 4.b, i.e. to allow for a timed-out case to sync up again later.

There may be other situation we need to consider. In any case, the main point I want to make is that we do need to think about these issues and provide a consistent and portable solution. This is a complex mechanism if we want to do it right. And not doing it right ... well, it is just not right, and weakens, rather than strengthening the appeal of TOSCA specification. I am sure that we can all agree that our interest is to make the TOSCA spec better.

Best regards,
Michael



On Tue, Apr 25, 2017 at 10:47 PM, Huabing Zhao zhao.huabing@zte.com.cn wrote:

 

Document Name: Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx

                                   


                                 

No description provided.
Download Latest Revision
Public Download Link

                                   


                                 

Submitter: Huabing Zhao
Group
: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder
: Working Documents
Date submitted
: 2017-04-25 19:47:19





--

Michael Brenner, Chief Architect NFV

                                 


                               

M: +1-732-895-5772

http://getcloudify.org

@cloudifysource

      




 



 

--

Michael Brenner, Chief Architect NFV

                                 


                               

M: +1-732-895-5772

http://getcloudify.org

@cloudifysource

      


 



 

--

Michael Brenner, Chief Architect NFV

                           


                         

M: +1-732-895-5772

http://getcloudify.org

@cloudifysource

      


 



 

--

Michael Brenner, Chief Architect NFV


M: +1-732-895-5772

http://getcloudify.org

@cloudifysource

      


 


     
     
     --      
     

Michael Brenner, Chief Architect NFV


M: +1-732-895-5772

http://getcloudify.org

@cloudifysource

      


             

 



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




--

Michael Brenner, Chief Architect NFV


M: +1-732-895-5772

http://getcloudify.org

@cloudifysource

      


 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]