[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] TOSCA artifact processing - 2
Il 14 novembre 2016 alle 21.41 Chris Lauwers <lauwers@ubicity.com>
ha scritto:
>
>
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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]