[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded
|
Hi Tal, everybody, Please find my thoughts inline in your mail below. Your topics touch a large problem space, and I hope my input is not too verbose
â. Best regards, /Calin
From:
<tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com> Dear group, I apologize for missing the meeting today. As you may have heard some things happened at Red Hat + IBM and we were a bit busy. :) But, I have taken some time the past weekend to think about the problem and try to create an example. I even started adding some TOSCA 1.3 features to Puccini in order to help me play around
with templates. Ultimately, I could not come up with what seemed to me like a reasonable example. Here are my thoughts. I very much hope that they will be read in a constructive tone. 1) I don't think TOSCA should define workflows at all, and I objected to the inclusion of this feature early on. TOSCA workflows enforce a
very specific orchestration model based on step-by-step operations in serial or parallel. There are few orchestrators that use such a model natively (notably Cloudify and BPMN middleware, to an extent), and other orchestrators could possibly be retrofitted
to support it with some kind of adapter layer. But, such adaptations are an offensive overhead. They hide away the orchestrator's true strengths and introduce considerable complexity and significant points of potential failure. [CC] This is how I understand workflows: As operations represent LCM actions, workflows represent the sequencing and synchronization of the operations across the topology
template elements. The original TOSCA workflows are the âdeclarativeâ workflows, i.e. the automatic workflows that are built by parsing the dependency graph, and synchronizing and sequencing operation calls based on that. The problem with this is that TOSCA
only defines such behavior for the Standard interface, and also a specific weaving with the Configure interface of relationships. Arbitrary interfaces and activities cannot be specified in conjunction with the topology driven node traversal. I believe that
in order to get around this and also to allow a more BPMN-type of fine control, imperative workflows were introduced in TOSCA v1.1. The problem with imperative workflow is that they:
To solve both the above problems, I believe we should introduce âcustom declarative workflowsâ that also follow the dependency graph of the template, but offer the possibility
to specify in detail:
I have uploaded a proposal here
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/65601/Specifying%20custom%20declarative%20workflows%20in%20TOSCA%20redux.docx . Please take a look. Note that this proposal is to extend TOSCA declarative
workflows and is totally orthogonal to this thread discussion lead by Priya that refers to external workflows that use a non-TOSCA language for specification. TOSCA interfaces and operations are more reasonable. Their calling scope is a node or a relationship or a group, the atomic units that any TOSCA orchestrator would have to implement in
one way or another, whether its a logical record or a physically provisioned resource. They provide entry points for the orchestrator without enforcing an orchestration model. (More on this in 3, below.) [CC] I still believe that the TOSCA language should be able to specify workflows (that is, the sequencing and synchronization of operation calls and other activities across
the nodes of a topology template) as intended by the designer of the topology template. Otherwise the TOSCA orchestrator would not know of such intent and ordering. 2) The example we are seeing from ETSI convinces me of this even more. If an ETSI implementation had "true" TOSCA orchestration, that would mean that it could fully run TOSCA workflows.
So ... why would it need an external Mistral workflow? Shouldn't TOSCA be used instead? And if TOSCA can't even do a better job than Mistral in this case (and I believe it could never catch up with native orchestration features), then the question as to why
we need a workflow grammar at all is even more glaring. [CC] I think that TOSCA has a unique advantage in automatically creating âdeclarativeâ workflows from the topology dependencies (i.e. like the original âintrinsicâ declarative
workflows). This will never be able to be replicated by the BPMN-like task-based (i.e. imperative) workflows for the reasons I presented above, especially the âmanualâ aspect of creating them, regardless if they are TOSCA imperative workflows or Mistral or
Camunda or other BPMN type workflows. I believe that the original TOSCA workflows did not âpick upâ due to a combination of factors (the existence of other workflow tools that were already used in the industry, the slow specification/implementation of TOSCA,
and the afore-mentioned inflexibility of the original âintrinsicâ TOSCA declarative workflows). 3) With that said, I do think TOSCA can and should go beyond interfaces to increase the operational contact with orchestrators. Rather than talk about "workflows", I think it's better to
use control language, specifically "loops". In open loops, control is delegated between subsystems. That, to me, seems to be the general problem we are trying to solve here. Open loops need full-duplex communication. Right now in TOSCA we have mostly have a one-way street via interfaces: from orchestrator to our template (well, there are return values via
get_operation_output, but that's still rather poorly defined). We do have an implementation of the other direction:
policy triggers. They are useful, but it seems to me like we can do more. [CC] With respect to that in v1.3 we have added ânotificationsâ in addition to âoperationsâ in an interface to exactly deal with the open loop aspect you mention (and to implement
the outside -> in part of the full duplex communication). Receiving a notification automatically triggers a connex event (i.e. events that are having the same name as the notification and that can be added to policy triggers) so notifications can trigger policies
that call any activities that are defined for a workflow step (i.e set_state, call_operation, inline workflow). I think they corresponds well to your thinking below. My current thinking is that it may be useful to define "events" in the TOSCA template. Events would be defined in relation to various TOSCA resources, not just policies, and they could
optionally include a "trigger" condition but also stay open ended, left for the orchestrator to implement as is appropriate to its technology. So, anywhere you can put an interface (node, relationship, group) you would also be able to put "events". Example: node_types: The orchestrator would know that nodes of this type could potentially send such an event, in which case it would take control. What it actually does -- run a "workflow"? turn on a subsystem?
-- is implementation-specific. We can provide a richer grammer of hints as to what should happen next, for example to call an operation, trigger another event upon success or failure (closed loop), etc. So, many of things that we define right now in workflow
step activities could be defined in events, instead. As with interfaces, the scope is limited to this particular node and we are not enforcing any behavioral model on how the orchestrator should work. I'll be on leave for next week's meeting, but am happy to discuss this on the mailing list if there is interest. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]