tosca message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [tosca] Groups - Issue_TOSCA318_Lack of BPMN BPEL support-v-2017-04-25.pptx uploaded
- From: "Matt Rutkowski" <mrutkows@us.ibm.com>
- To: Michael Brenner <michael@gigaspaces.com>
- Date: Wed, 26 Apr 2017 08:42:46 -0500
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:
-- Michael
Brenner, Chief Architect
NFV | |
|
M: +1-732-895-5772 | | @cloudifysource |
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]