These statements make it clear that operations are intended to be executed by an Orchestrator, which implies (in my opinion) that if youâre not building a TOSCA Orchestrator, these concepts
shouldnât be of concern.
Again, I'm confused. What if I'm not building a "pure" TOSCA orchestrator but integrating TOSCA into a preexisting orchestrator that has these concepts? I'm not sure why you are insisting that "TOSCA workflows, interfaces, operations, and notifications are only relevant in the context of 'pure TOSCA orchestration'". Why restrict this to "pure" TOSCA orchestrators?
ÂÂÂÂÂÂÂÂÂ
Turandot, which is not a "pure TOSCA orchestrator", supports operations of various types on pods (using the K8s control plane) and KubeVirt virtual machines (using ssh)
Perhaps I have the wrong understanding, but my impression was that Turandot delegates all orchestration to Kubernetes. If thatâs the case, which piece of
software is it that âinvokesâ the operations defined on TOSCA nodes and relationships?
Turandot handles the "invocation" in this case. (It extends K8s, it does not just translate.) But right now it does not have any built-in support for workflows. (I've started working on Argo Workflows integration.) As for what triggers the invocation, instead of a "workflow" modality Turandot uses something I call the "town-crier model". It's described briefly here and I've also given a few talks about it:
So, yes, "operations" are the building blocks (and they're also used for "notifications") but this is not a one-after-the-other DAG, it's more like an "all-at-once eventuality". My point here is just to remind us that events can be assembled together in many different ways with many different semantic paradigms in the context of orchestration. DAG workflows are just one way used by a few orchestrators.
Â
ÂÂÂÂÂÂÂÂÂ
Puccini, which is not an orchestrator at all, can
export TOSCA 1.3 workflows to BPMN2, to be used by a wide variety of orchestrators
Iâm not clear on how this would work. TOSCA operations typically need input values that are retrieved from nodes and relationships in the topology representation
graph(using TOSCA intrinsic functions). How do BPMN workflows access this information?
Iâm not trying to be difficult here. These are sincere questions. I would love to understand how you envision this working.
Puccini's main job is to produce a (valid) flat topology comprising general-purpose node representations in the Clout format. These node representations have named properties with actual (coerced) values, not TOSCA functions or anything else. It's thus straightforward to reassemble them into other declarative formats, in this case the XML-based BPMN2, which is quite rich and supports various properties per task (which in turn can be implemented by typed "objects" that bring in custom behaviors). I didn't go that far with this PoC, but one could definitely create BPMN2 profiles for specific environments. Also note that my PoC is static: it only supports "properties", not "attributes", because the latter would require not just the creation of the BPMN2 file, but also integration with the business process orchestrator that maintains state (JBoss, jBPM, Camunda, etc.). To put it another way, BPMN2 represents a workflow template rather than a workflow itself.
Adding TOSCA support to BPMN2 orchestrators is not only not new, it's probably the method used by the earliest TOSCA implementations. It is how ONAP works, for example. Although I only know of declarative workflow support, not imperative.