OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Submitter's message Revision highlighting an example from ETSI NFV illustrating the need for passing parameters from service template to scripts. -- Ms. Priya TG Document Name : TOSCA Imperative Workflows supporting custom workflow language Description This contribution attempts to highlight the gaps in current v1.3 grammar of TOSCA Imperative workflows supporting custom workflow language. Download Latest Revision Public Download Link Submitter : Ms. Priya TG Group : OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Folder : Working Documents Date submitted : 2019-07-01 04:38:25 Revision : 1

Hi Priya,
 
I think that the best way to solve this problem, that already works with TOSCA v1.3 specification is to use an imperative workflow, where the input is received from the outside and in its only step uses the inline activity
to inline an external (i.e. Mistral) workflow. The inline activity should have the new form we introduced in v1.3 where we provide inputs to the called workflow. Since it is inside the pther workflow, both the inputs from outside and inputs that are taken
from the nodes can be freely mixed.
 
For example the following snippet:
 
workflows:
 
  wf2_external_mistral:
    inputs:
      wf2in1:
        type: string
      wf2in2:
        type: string
    outputs:
      wf2out:
        type: string
 
  wf1_called_from_outside_api:
    inputs:
      wf1in1:
        type: string
      wf1in2:
        type: string
    steps:
      main:
        target: vnfNode
        activities:
       - inline:
            workflow: wf2
            inputs:
              wf2in1: { get_input: wf1in1}
              wf2in2: { get_property: [ vnfNode, property1 ] }
 
BR,
/Calin
 

From: <tosca@lists.oasis-open.org> on behalf of Priya TG <priya.g@netcracker.com>
Date: Monday, 1 July 2019 at 13:39
To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded


 

Submitter's message
Revision highlighting an example from ETSI NFV illustrating the need for passing parameters from service template to scripts.

-- Ms. Priya TG




Document Name :

TOSCA Imperative Workflows supporting custom workflow language





Description
This contribution attempts to highlight the gaps in current v1.3 grammar of
TOSCA Imperative workflows supporting custom workflow language.
Download
Latest Revision
Public Download Link





Submitter : Ms. Priya TG
Group : OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder : Working Documents
Date submitted : 2019-07-01 04:38:25
Revision : 1




 

Calin,
 
Thank you for your inputs. In last week s discussion,  we talked about making the entire topology template available to the external workflow engine since there could be many input parameters and defining each
of them as inputs to the external workflow could be an overhead.
Hoping to continue the discussion in today s meeting.
 
Regards,
Priya

 


From: Calin Curescu [mailto:calin.curescu@ericsson.com]

Sent: Tuesday, July 2, 2019 6:19 PM
To: Priya T G <priya.g@netcracker.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded


 
Hi Priya,
 
I think that the best way to solve this problem, that already works with TOSCA v1.3 specification is to use an imperative workflow, where the input is received from the outside and in its only step uses the inline activity to inline an
external (i.e. Mistral) workflow. The inline activity should have the new form we introduced in v1.3 where we provide inputs to the called workflow. Since it is inside the pther workflow, both the inputs from outside and inputs that are taken from the nodes
can be freely mixed.
 
For example the following snippet:
 
workflows:
 
  wf2_external_mistral:
    inputs:
      wf2in1:
        type: string
      wf2in2:
        type: string
    outputs:
      wf2out:
        type: string
 
  wf1_called_from_outside_api:
    inputs:
      wf1in1:
        type: string
      wf1in2:
        type: string
    steps:
      main:
        target: vnfNode
        activities:
       - inline:
            workflow: wf2
            inputs:
              wf2in1: { get_input: wf1in1}
              wf2in2: { get_property: [ vnfNode, property1 ] }
 
BR,
/Calin
 

From:
< tosca@lists.oasis-open.org > on behalf of Priya TG < priya.g@netcracker.com >
Date: Monday, 1 July 2019 at 13:39
To: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded


 

Submitter's message
Revision highlighting an example from ETSI NFV illustrating the need for passing parameters from service template to scripts.

-- Ms. Priya TG




Document Name :

TOSCA Imperative Workflows supporting custom workflow language







Description
This contribution attempts to highlight the gaps in current v1.3 grammar of
TOSCA Imperative workflows supporting custom workflow language.
Download
Latest Revision
Public Download Link







Submitter : Ms. Priya TG
Group : OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder : Working Documents
Date submitted : 2019-07-01 04:38:25
Revision : 1




 

 



The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
 

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. 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.) 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. 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. 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: MyDBMS: derived_from: DBMS interfaces: Backup: type: Backup events: OutOfResources: type: OutOfResources event_types: OutOfResources: properties: timestamp: type: timestamp 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.