You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by Steve Baillargeon <st...@ericsson.com> on 2017/09/08 20:56:19 UTC
Selecting and installing a specific stack
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
Re: Selecting and installing a specific stack
Posted by Ran Ziv <ra...@cloudify.co>.
In your example, did you mean that the pairs A&D, B&E, C&F are supposedly
of the same "abstract type" (e.g. C&F are both DBs, etc.)?
If so, substitution mapping might be useful here as well.
Otherwise, I'm not really sure why you'd see the two templates as "linked"
or similar in any way.
On Sat, Sep 9, 2017 at 2:09 AM, Tal Liron <ta...@cloudify.co> wrote:
> 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.baillargeon@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
> >
> >
>
Re: Selecting and installing a specific stack
Posted by Tal Liron <ta...@cloudify.co>.
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.baillargeon@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
>
>