I took an action item during last week’s Simple Profile meeting to capture our discussions in the latest version of the Simple Profile spec. However, I’m struggling a bit with how to start, since there doesn’t seem to be a single section in the document where the deployment process is described.
- In the early (introductory) sections of the document, we show service template examples that use normative node types and state that “orchestrators are expected to know how to deploy all normative node types”. I understand that this decision was made the keep the profile “Simple”, but I believe that may limits what can be deployed using TOSCA to only very simple service topologies.
- The document then introduces examples that introduce scripts, but it suggests that those scripts are used to “extend” the behavior of the Normative Types in areas where some customization is needed. However, I can’t find a place in the document that definitively states where these scripts are to be executed. I think the descriptions in the document imply that these scripts are supposed to be executed on the Compute node that is the target of the HostedOn relationship of the node, but if that’s the case we should state that explicitly.
- The document should also prescribe those cases where the “run the script on the HostedOn target” approach doesn’t work:
o Some nodes have a HostedOn relationship that doesn’t point to a Compute node. For example, DB nodes are HostedOn DBMS systems. Those DBMS systems in turn are HostedOn a Compute node. Should we modify the “rule” to say that an orchestrator needs to follow the HostedOn chain until it hits a Compute node?
o Some nodes may not have a HostedOn requirement. Luc suggested that for those nodes, they rule should be that scripts need to be run in the context of the Orchestrator rather than in the context of a Compute node. Is this an acceptable extension of the rule?
o Some nodes may have a HostedOn relationship that doesn’t ever terminate in a Compute node. For example, the Docker use cases in the spec don’t use Compute nodes. If there is a need to run additional configuration scripts, it doesn’t seem like there is a way to do this in a portable fashion.
o Some nodes may have a HostedOn relationships, but scripts/artifacts associated with that node should not be run on the HostedOn target (e.g. they may have to be processed by a puppet master instead).
- There are also inconsistencies between implementation and deployment artifacts:
o Most of the examples in the text use implementation artifacts and deployment artifacts interchangeably, but the Interface and Operation specifications only talk about implementation artifacts. There isn’t any mention of deployment artifacts.
o Processing of deployment artifacts gets two paragraphs (in section 5.8.4.3) but that section doesn’t really prescribe a definitive way of deploying such artifacts.
o From the prose, it’s not clear if the “dependencies” section in Operations specifications only apply to implementation artifacts or also to deployment artifacts
- Derek mentioned last week that in order to process some types of artifacts, the orchestrator may need to deploy an entire subtopology that acts as the “processor” responsible for the deployment. Should it be possible to specify this subtopology in a service template?
In any event, apologies for not getting any prose written but I’m hoping that the points above can help guide the discussion tomorrow.
Thanks,
Chris