Re: Selecting and installing a specific stack

[Tal Liron]

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
>
>

Re: operation dependencies

[Tal Liron]

Yes:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Configuration

On Fri, Sep 8, 2017 at 4:45 PM, DeWayne Filppi  wrote:

> I see in the examples a list of dependencies for scripts in operations, for
> example:
>
> implementation:
>   primary: scripts/configure.sh
>   dependencies:
> - "ssh.user > { get_input: ssh_username }"
> - "ssh.key_filename > { get_input: private_key_path }"
> - "ssh.address > { get_attribute: [ virtual_ip,
> floating_ip_address ] }"
>
> The spec seems to indicate that the dependency list is for resources that
> need to be made available so the main script can be run.  Clearly that
> isn't the case in the example.  Is this '>' syntax documented anywhere?
>

operation dependencies

[DeWayne Filppi]

I see in the examples a list of dependencies for scripts in operations, for
example:

implementation:
  primary: scripts/configure.sh
  dependencies:
- "ssh.user > { get_input: ssh_username }"
- "ssh.key_filename > { get_input: private_key_path }"
- "ssh.address > { get_attribute: [ virtual_ip,
floating_ip_address ] }"

The spec seems to indicate that the dependency list is for resources that
need to be made available so the main script can be run.  Clearly that
isn't the case in the example.  Is this '>' syntax documented anywhere?

Selecting and installing a specific stack

[Steve Baillargeon]

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