Yes, there is only the representation graph. But during design you can still see it: put in inputs, see the resulting representation graph, and ensure that it is valid. That's all I mean by "template graph" (I keep
changing my wording to try to explain better) -- it's the representation graph that you can see without having to deploy your template to the cloud.
Weâre getting extremely confused about terminology again here:
-
None of what youâre describing in the preceding paragraph is âdesign timeâ. The only thing that gets created during service design is the topology template that contains the node templates (that may have dangling requirements). These designs (the âtemplate
graphsâ) are typically stored in a catalog. In the âOperational Modelâ in Section 4 of the Version 2.0 spec, we call these âtemplate graphsâ the ânormalized topology templatesâ.
-
The ârepresentation graphâ is created at Deployment Time, not at Design Time. At deployment time, an operator (not a designer) provides values for the inputs defined in the topology template. The TOSCA processor then creates a representation graph from the
template graph by applying these input values (and presumably stores it in some inventory somewhere). Creation of the representation graph also involves:
-
Fulfilling dangling requirements (using other node representations in the inventory)
-
Substituting nodes marked for substation.
-
Creation of the representation graphs does not cause anything to run in the real cloud, nor does it require information from systems running on the cloud. All thatâs required is:
-
One or more templates from the catalog
-
Input values
-
Access to node representations in some inventory.
The operational model in Section 4 clearly shows that these fully validated topology representations are created before any orchestration takes place.
-
After a complete representation graph has been created, there is a separate step to ârealizeâ this graph into the real world (onto the âplatformsâ as we have called them in the operational model). If youâre using pure TOSCA this is done by running workflows
that call interface operations that are implemented by processing artifacts, but itâs perfectly fine to hand off this representation graph to some other system for âorchestrationâ.
I thought all of this was perfectly clear when we agreed to the Operational Model in Section 4. To further clarify and to avoid this type of confusion in the future, I propose we do the following:
-
Cleary define which activities take place during Design (Day 0), Deployment (Day 1), and ongoing management (Day 2)
-
Further split up Service Deployment into two phases:
-
Service Provisioning: the creation of a complete service representation graph in inventory
-
Service Activation: taking the actions required to ârealizeâ the representation graph on the external platforms.
Unless anyone objects, Iâll update the document accordingly.
Thanks,
Chris