The only thing you can configure in pure TOSCA is the inputs, so it's not
so easy a problem to solve. If we have node templates for all the nodes, we
could configure their requirements for each using intrinsic functions that
rely on the inputs, so that the final topology could change.
Let me try to show this with a simpler example, where we have nodes A and B
and want to pick between them. Node Z could use either one of them
depending on the input:
topology_template:
inputs:
node_choice:
type: string
default: A
node_templates:
A:
type: MyNode1
B:
type: MyNode2
Z:
type: MyNode3
requirements:
- stack:
capability: MyCap
node: { get_input: node_choice }
The problem in this case is that both nodes A and B will be instantiated
whatever the topology, though there will be only one relationship. If you
want to the unwanted node to not be instantiated, you need to set its
default_instances to 0:
node_templates:
A:
type: MyNode1
capabilities:
scalable:
properties:
default_instances: 0
Two challenges with this:
1) The expression language in TOSCA is quite thin, so there's no way to do
an "if" to set default_instances to 0 or 1 depending on the choice. So, we
would likely have to add more inputs:
topology_template:
inputs:
node_choice:
type: string
default: A
A.instances:
type: integer
default: 1
B.instances:
type: integer
default: 0
node_templates:
A:
type: MyNode1
capabilities:
scalable:
properties:
default_instances: { get_input: A.instances }
B: ...
2) Another problem is that TOSCA normative types only give the "scalable"
capability to Compute nodes. If your nodes do not inherit from Compute, you
can either declare the tosca.capabilities.Scalable capability yourself for
your node types, or with ARIA use the aria.Scaling policy:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Types
The above is all rather complicated and awkward. This scenario is rather
poorly handled in pure TOSCA.
I think it's better solved at this point by a higher-level tool that can
generate the TOSCA YAML code for you according to your needs. ARIA
intrinsically supports Jinja templates if your service templates end with a
".yaml.jinja" extension. With Jinja you have much richer programming logic:
"if" control flow, "for" loops, etc. So you can generate your final service
template more powerfully.
On Fri, Sep 8, 2017 at 3:56 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:
> Hi
> I have a service template with 2 stacks.
> Stack 1 has nodes A, B and C.
> Stack 2 has nodes D, E and F.
> Both stacks must be defined in the same service template.
>
> What is the easiest way to describe a service template allowing the ARIA
> user/orchestrator to select one of them for instantiation?
> Is it with groups?
>
> Regards
> Steve B
>
>
