[aria] TOSCA YAML Profile version and Support for Topology Substitution

[Steve Baillargeon]

Hi Tom

Sorry I lost track of the plans if any for supporting topology substitution 
defined in TOSCA YAML Profile 1.0 and TOSCA YAML Profile 1.0 (all features).
Here are a few questions:

- Can you confirm all versions of ARIA up to the latest release (i.e. 
apache-ariatosca 0.2.0) only support TOSCA YAML Profile 1.0?
- Does apache-ariatosca 0.2.0 (or earlier release) support topology 
substitution defined in TOSCA YAML Profile 1.0?
- When will ARIA support topology substitution defined in TOSCA YAML Profile 
1.0?
- When will ARIA support TOSCA YAML Profile 1.1?

Thank you

Regards
Steve B

Abstract Node Template Matching

[Steve Baillargeon]

Hi
I just read section 14.3 called Abstract Node Matching in latest YAML Profile 
1.2.
It is also applicable to YAML Profile 1.0.

All of the examples in section 14.3 do NOT involve any topology substitution.
Basically the spec states the orchestrator MUST to do its best to replace an 
abstract node template (by searching in other service templates) which will 
lead to a node implementation and even provide suggestions if no match is found.

How does it work today?
Does ARIA skip and do nothing when it finds an abstract node template (node 
template without implementation artifact for create operation)?
Does ARIA actually try to find a valid match implementation through its 
catalogs including the plugin type repository ?
How will ARIA handle this feature in the future?
Regards
Steve B

RE: Node Template Substitution

[Steve Baillargeon]

Hi Avia
I don't access to the design doc. Am I missing something?

Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
Or is it postponed to later?

-Steve

-Original Message-
From: Avia Efrat [mailto:a...@cloudify.co] 
Sent: Tuesday, October 17, 2017 4:44 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There are plans to extend substitution mappings support to TOSCA 1.2, just as 
any other change/improvement in the 1.2 profile.

A CSAR with one 'main' service template and other service templates will be 
stored as one service template, and will have one unique name.

The design doc:
https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_TPqLpvXjzj98NXrAmcjc


Additional v1.2 issues (a non-exhaustive list):
https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_oVrZXQ3z4030U6JIXdJ84/edit


On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi Avia
> One more question.
>
> Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> top-level ST and a bunch of low-level STs.
> I am assuming all those TOSCA service templates (all of them have a 
> full topology section) will be stored as a single “service-template” 
> in ARIA and a single unique name is needed to represent such single 
> “service-template”
> composed of multiple topologies.
> Is this correct?
>
> -Steve
>
> -Original Message-
> From: Steve Baillargeon
> Sent: Wednesday, October 11, 2017 11:29 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> Is it possible to review the design documentation for it?
> Do you have a doc or a few notes describing how ARIA will perform 
> "best matching" based on YAML 1.0/1.1 profile?
>
> The full support for NFV Profile 1.0 requires Node Template 
> Substitution defined in YAML 1.2 profile.
> Any future plans for ARIA to extend Node Template Substitution as 
> defined in YAML 1.2 profile ?
>
> Regards
> Steve B
>
> -Original Message-
> From: Arthur Berezin [mailto:art...@cloudify.co]
> Sent: Tuesday, October 10, 2017 12:20 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> Avia, can you please post a link to the design?  thanks
>
> On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat <a...@cloudify.co> wrote:
>
> > Currently the design is finished, and it is on a small hold for now.
> > The plan is to support the 1.0/1.1 profile.
> >
> > On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi
> > > Can we have a status update on the availability of the Node 
> > > Template Substitution feature (aka substitution mappings)?
> > > Will it support the "capabilities" defined in YAML Profile 1.0 or 
> > > YAML Profile 1.2?
> > >
> > > Regards
> > > Steve B
> > >
> > >
> >
>

Loading Custom Workflows from CSAR

[Steve Baillargeon]

Hi
As far as I know the implementation string associated with the aria.Workflow 
type must call or execute a Python function (using the dot notation) that is 
stored in ARIA, like a plugin.
When will it be possible to refer to  a .py file stored in the CSAR instead?
Do you have any Jira for this enhancement?

Regards
Steve B

RE: Attribute and Property Reflection

[Steve Baillargeon]

Hi Tal
I found the magic statement in 3.5.8.1.1
Yes the reflected attribute name must be the same as the property name for the 
reflection feature.
Now I understand your second point. Thanks for your patience.

Why do you think it is a bad feature?
Property is the desired value while reflected attribute is the actual value.
It seems logical to show actual value.
Or are you saying the actual value will always be the same as the desired value 
and the reflected attribute is useless?

-Steve



-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, November 16, 2017 3:49 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Attribute and Property Reflection

The reflection feature is mentioned very, very briefly in just that one 
sentence in the spec. They is no mention of changing names, so I am expecting 
that the attribute names would be identical to the property names. In that 
case, there would be a conflict if an attribute has the same name as a property 
-- otherwise how would the property be reflected? That's why I'm assuming that 
for this to work we should not allow an attribute name to override a property 
name.

My preferred solution is not to add any custom prefixes in ARIA, because they 
would not be portable

The TOSCA spec has many authors, and it would be hard to track down the 
particular one who wrote this sentence... Personally, I think this is an awful 
and unclear feature.

On Thu, Nov 16, 2017 at 2:43 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Back 1 step please.
> Are you saying that attribute names and property names within a Type 
> MUST be different?
> As far as I know they can be the same e.g.   = 
> 
>
> attributes:
>   :
> type:string
> properties:
>   :
>   type:string
>
>
> Back to reflection.
> I am proposing  = actual_ But I think 
> it is best if I ask further clarification from YAML Profile authors.
> What do you think?
> What is your preferred solution?
>
> -Steve
>
>
>
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 16, 2017 3:15 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Attribute and Property Reflection
>
> Steve, we cannot change the TOSCA spec, and the spec does not say 
> anything about naming conventions here.
>
> I think, though, that an obvious part of this JIRA will be to emit an 
> error if an attribute name is the same as a property name, because 
> obviously this would break this feature.
>
> On Thu, Nov 16, 2017 at 2:12 PM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > I see the following text in the JIRA:
> > According to the TOSCA 1.0 spec, property value should be 'exposed', 
> > with the same name, as attributes.
> >
> > Does the spec really say to use the same name? As far as I know it 
> > does not.
> > What about using a better reflected attribute naming convention like 
> > “actual_”?
> > Can I add this to the JIRA?
> >
> > -Steve B
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Thursday, November 16, 2017 2:48 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Attribute and Property Reflection
> >
> > Not right now, but there is an open JIRA to support it.
> >
> > On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon < 
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi
> > > Does ARIA support "attribute and property reflection" defined in
> > 3.5.10.1?
> > >
> > > Regards
> > > Steve B
> > >
> > >
> >
>

RE: Attribute and Property Reflection

[Steve Baillargeon]

Back 1 step please.
Are you saying that attribute names and property names within a Type MUST be 
different?
As far as I know they can be the same e.g.   = 

attributes:
  :
type:string
properties:
  :
  type:string


Back to reflection.
I am proposing  = actual_ 
But I think it is best if I ask further clarification from YAML Profile authors.
What do you think?
What is your preferred solution?

-Steve




-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, November 16, 2017 3:15 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Attribute and Property Reflection

Steve, we cannot change the TOSCA spec, and the spec does not say anything 
about naming conventions here.

I think, though, that an obvious part of this JIRA will be to emit an error if 
an attribute name is the same as a property name, because obviously this would 
break this feature.

On Thu, Nov 16, 2017 at 2:12 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> I see the following text in the JIRA:
> According to the TOSCA 1.0 spec, property value should be 'exposed', 
> with the same name, as attributes.
>
> Does the spec really say to use the same name? As far as I know it 
> does not.
> What about using a better reflected attribute naming convention like 
> “actual_”?
> Can I add this to the JIRA?
>
> -Steve B
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 16, 2017 2:48 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Attribute and Property Reflection
>
> Not right now, but there is an open JIRA to support it.
>
> On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > Does ARIA support "attribute and property reflection" defined in
> 3.5.10.1?
> >
> > Regards
> > Steve B
> >
> >
>

RE: Attribute and Property Reflection

[Steve Baillargeon]

I see the following text in the JIRA:
According to the TOSCA 1.0 spec, property value should be 'exposed', with the 
same name, as attributes. 

Does the spec really say to use the same name? As far as I know it does not.
What about using a better reflected attribute naming convention like 
“actual_”?
Can I add this to the JIRA?

-Steve B

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, November 16, 2017 2:48 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Attribute and Property Reflection

Not right now, but there is an open JIRA to support it.

On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> Does ARIA support "attribute and property reflection" defined in 3.5.10.1?
>
> Regards
> Steve B
>
>

Attribute and Property Reflection

[Steve Baillargeon]

Hi
Does ARIA support "attribute and property reflection" defined in 3.5.10.1?

Regards
Steve B

RE: attributes

[Steve Baillargeon]

Hi
A follow-up question.
I am trying to understand the meaning of "function" here.

Is the solution as simple as defining an attribute (say of type string), skip 
the attribute assignment in the template and let the plugin decides the "value" 
for the attribute which can be a calculated value or any function implemented 
by the plugin? Yes I agree this is not portable.
Did I miss something?

-Steve

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, November 15, 2017 4:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: attributes

Well, this is a bit complex.

Attributes are ostensibly filled during runtime by other systems, for example 
during the install workflow an ip_address would get its real value.
It's not really clear how another system would be able to insert a function 
here, but it's not impossible. In ARIA's case, functions are implemented as 
pickled Python classes, so it would be possible to do this, however obviously 
it would not be portable.

But, you can also give attributes default values. For default values, obviously 
you can use functions.

On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi  wrote:

> General TOSCA question.  Is there anything in the spec that requires 
> attributes to be values rather than functions?  IOW, is there anything 
> in there that prevents an orchestrator from representing an attribute 
> read as more of a "getter", rather than a database fetch?  I ask 
> because I've run across a case where I'd prefer an attribute reference 
> to return a calculated value.  Seems more flexible if allowed, and if 
> not allowed, it should be allowed.
>
> DeWayne
>

Attributes

[Steve Baillargeon]

The required column  for attributes is below.
Required = yes --> Mandatory to fill in ?
Required = no --> Optional to fill in ?


[cid:image001.png@01D35D72.28B74270]

RE: Attributes

[Steve Baillargeon]

As an example, does ARIA always expose the "optional" private_address for a 
Compute node instance?
If so, what method is used by ARIA to select the primary OAM IP address when 
multiple IPs are associated with the Compute node instance?

-Steve

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, November 14, 2017 5:27 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Attributes

ARIA exposes all defined attributes, even if they have no default value (in 
which case they will be null).

Note that three attributes (tosca_id, tosca_name, state) are automatically 
filled by ARIA, if they are available. Any node type inheriting from 
tosca.nodes.Root will have them.

I'm not sure what you mean by "optional" or "mandatory": there is no way to 
define attributes that way. See section 3.5.10.2 in the spec.

On Tue, Nov 14, 2017 at 4:05 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> The YAML spec is confusing about when the service or node instance 
> actually exposes the value of an attribute.
> Does ARIA always implement and expose the values of all attribute 
> definitions (optional and mandatory) defined in normative types?
>
> Related observation: it is very strange that the YAML spec does not 
> support a REQUIRED keyname for the attribute definition. Then how do 
> we go about declaring an optional vs mandatory attribute definition in 
> custom type definitions? For now, I am almost ready to conclude that 
> all attributes SHOULD be exposed by the TOSCA orchestrator regardless 
> if it is required or not.
>
> -Steve
>

Attributes

[Steve Baillargeon]

Hi
The YAML spec is confusing about when the service or node instance actually 
exposes the value of an attribute.
Does ARIA always implement and expose the values of all attribute definitions 
(optional and mandatory) defined in normative types?

Related observation: it is very strange that the YAML spec does not support a 
REQUIRED keyname for the attribute definition. Then how do we go about 
declaring an optional vs mandatory attribute definition in custom type 
definitions? For now, I am almost ready to conclude that all attributes SHOULD 
be exposed by the TOSCA orchestrator regardless if it is required or not.

-Steve

RE: decoupling type definitions from CSAR

[Steve Baillargeon]

Hi Vaish
I agree.

We should also consider the same idea for NFV and ONAP types (as opposed to 
make them built-in). 
I suspect those types may get updated without the need to update the ARIA 
orchestrator version.

Is it just a matter of allowing the admin user to load/delete type definitions 
files  into the ARIA local host and specifying the repository option in the 
import definition?
Similar to plugins?

For instance:

For individually managed plugins:
-file : plugin.yaml
  repository: plugins

For individually managed type definitions files:
-file : typedefintion.yaml
  repository: definitions


Regards
Steve B




-Original Message-
From: Vaishnavi K.R [mailto:vaishnavi@ericsson.com] 
Sent: Friday, November 10, 2017 6:30 AM
To: dev@ariatosca.incubator.apache.org
Subject: decoupling type definitions from CSAR

Hi,


With the current ARIA, in order to use the type definitions that are user 
defined, it must be imported in the Service Template. The definitions files are 
imported by specifying the relative paths in the 'imports' section. These type 
definition files can rather reside in the localhost running ARIA or can be made 
available by bundling along with the service templates in a CSAR. For remote 
executions, the latter holds good.


However if the type definitions are so common and can be used across Service 
Templates, it becomes mandatory to include the same file in different CSARs.


In order to reuse the type definitions that are common across service 
templates, it would be better to maintain the user defined type definitions 
separately and every service template can use it irrespective of their CSARs.


This makes the user defined type definitions to be loaded once and the service 
templates could import it.


I would like to know your view on this.


Thanks,

/Vaish

Support for namespace prefix

[Steve Baillargeon]

Hi
Say I have a topology template using the following node templates:


  *   Node A from type tosca.nodes.Compute --> This is the TOSCA standard 
Compute node type. The tosca namespace prefix is not explicitly used here.
  *   Node B from type abc: tosca.nodes.Compute --> This is an imported custom 
Compute node type with the same type URI as the standard Compute (bad idea) but 
different namespace prefix

Will ARIA distinguish these 2 node types?

Regards
Steve B

Implementation Artifact Override

[Steve Baillargeon]

Hi
Does ARIA support the ability to override an implementation artifact that is 
already been specified in the node type?
For instance:

node_types:
  aria.openstack.nodes.Server:
derived_from: tosca.nodes.Compute
...
interfaces:
  Standard:
create:
  implementation: cloudify-openstack-plugin > nova_plugin.server.create


topology_template:
  node_templates:
fortigate_vnf:
  type: aria.openstack.nodes.Server
  interfaces:
Standard:
  create:
implementation: my_script.py



Regards
Steve Baillargeon

Multiple local storages for Compute Node Template

[Steve Baillargeon]

Hi
Is this a valid set of requirement assignments for a node template of type 
Compute?
All have the same requirement assignment name (as per Compute Node Type 
definition) but pointing to different node template names.

requirements:
  - local_storage: my_storage_1
  - local_storage: my_storage_2
  - local_storage: my_storage_3

When must I have to use the extended notation?
When using topology substitution?

Regards
Steve

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[Steve Baillargeon]

Hi

I have few follow-up questions/comments related to import definitions and 
plugins.

1) Does ARIA actually support  namespace_uri and namespace_prefix for each 
import definition as defined in YAML 1.1 spec. See multi-line grammar below:
imports:  
  - file: 
repository: 
namespace_uri: 
namespace_prefix: 

2) What does ARIA do with this information today especially the namespace 
prefix? I guess it is currently ignored but could be used in the future (?)

3) When creating a type definition file, is it important to  ensure all new 
type names defined in the imported file are using the declared namespace prefix 
(assuming namespace prefix is provided in the import definition)?

4) Is it bad practice to mix new types from different namespace prefixes in the 
same type definition file (assuming namespace prefix is *not* provided in the 
import definition)? 

5) For plugins, is it possible to support a more specific filename instead of a 
static/fixed name like plugin.yaml? What about using 
-.yaml? I see the need for ST authors to retrieve 
these files for analysis and the last thing I want to do is to rename them.

6) The user should be able to import a specific yaml file using - file: 
- with repository: plugins as described earlier by 
DJ. The - is an alias for the 
plugin_name>-.yaml file.

7) To simplify the import definition for plugins, the user should also be able 
to import a plugin name without specifying the version. For instance:
- file: 
  repository: plugins
Here   is an alias always pointing to the latest version of the 
-.yaml file.



Regards
Steve B


-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Friday, October 20, 2017 11:56 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

That looks good to me! Any thoughts from other committers?

On Fri, Oct 20, 2017 at 4:37 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> We have started to work on the plugin import part. Just to re-confirm 
> we would going with the below convention and contributing it back to ARIA.
> Please let me know if you have any comments.
>
> imports:
> - file: -
>   repository: plugins
> - file: -
>   repository: plugins
>
> Example:
>
> imports:
> - file: openstack-1.0
>   repository: plugins
> - file: kubernetes-1.0
>   repository: plugins
>
> NOTE: We are not looking at having the extension ".yaml" mandated.
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, September 26, 2017 11:56 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> That's how ARIA implements it right now. I consider the TOSCA 1.0 spec 
> on "imports" to be an error because it contradicts the rest of the 
> document, so we have always used the correction as it now appears in 
> 1.2. This is not the only place where we had to resolve 
> contradictions, by any means. :)
>
> I'm getting very close to finishing work the complete parser test 
> suite, so it will give us a good centralized place to check and confirm 
> grammar.
>
> By the way, take care to mention TOSCA specifically when you refer to 
> versions. "YAML 1.1" refers to the YAML spec. (We actually use YAML 
> 1.2.)
>
>
> On Tue, Sep 26, 2017 at 1:06 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > Are we looking at the below syntax for plugins, with the changes in 
> > YAML
> > 1.1
> >
> > Imports:
> > - file: openstack-1.0
> >   repository: plugins
> > - file: kubernetes-1.0
> >   repository: plugins
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> > Sent: Monday, September 25, 2017 11:24 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Contribution for https://issues.apache.org/
> > jira/browse/ARIA-118
> >
> > Hi
> > YAML1.0 spec is incorrect for import definitions.
> > YAML1.2 spec has updated the import grammar as follows.
> > It will be great for ARIA to support parts of the YAML1.2 spec soon 
> > especially for areas that are corrected.
> >
> > From YAML 1.2 spec:
> > 3.5.8.2 Grammar
> > Import definitions have one the following grammars:
> > 3.5.8.2.1 Single-line grammar:
> > imports:
> >   - 
> >   - 
> > 3.5.8.2.2 Multi-line grammar
> > imports:
> >   - file: 
> > repository: 
>

Defining a Metadata keyname as a list?

[Steve Baillargeon]

Hi
The metadata section is defined as a map where each entry has a keyname and 
value.
Example:
: 
...
: 

Can I further define a metadata keyname as a list of values ?
Example:
: 
: [, ,...]

Regards
Steve B

RE: Definition names

[Steve Baillargeon]

Let me use a concrete example by modifying the compute node type a little.
See below.
Assume this is for a single node type


requirements:
  - :
  capability: tosca.capabilities.Attachment
  node: tosca.nodes.BlockStorage
  relationship: tosca.relationships.AttachesTo
  occurrences: [0, UNBOUNDED]
capabilities:
   :
type: tosca.capabilities.Container
valid_source_types: [tosca.nodes.SoftwareComponent]
  :
type: tosca.capabilities.Endpoint.Admin


1)  I am assuming capability definition name 1 and capability definition name 2 
must be different. Do you agree?

2) I am assuming requirement definition name 1 and capability definition name 1 
can be the same. Do you agree?

-Steve

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, October 26, 2017 2:37 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Definition names

I'm not entirely sure what you mean... here's a reply according to what I 
understand.

In most cases there is no ambiguity because the language is YAML-based. A dict 
in YAML has unique keys, so it follows that definitions would be unique. (We 
discussed the issue of importing in a previous thread, and opened a JIRA for 
it.)

There is one curious exception: sequenced lists. In node templates, you define 
requirements as a sequenced list, meaning that you are allowed to specify the 
same requirement name multiple times. This makes perfect sense, and matches the 
"occurrences" field in the the node type.

However ... at the node type the requirement definition is *also* a sequenced 
list. There is no technical reason for this: I believe TOSCA defined it this to 
make it match the node template style, though in my personal opinion this was a 
wrong choice because by definition the requirement is unique per node type. 
ARIA treats the requirements sequenced list in the node type the same way the 
YAML parser treats keys in a dict:
if there is a key of the same name, it will overwrite a previous key of that 
name.

On Thu, Oct 26, 2017 at 1:04 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> The TOSCA YAML Profile is not 100% clear about duplicate definitions names.
> What are the guidelines for ARIA?
>
> Should all definitions names be unique across definitions "classes"
> (attributes, properties, requirements, capabilities,...) within a 
> given node type definition?
> Or is it OK to only have unique definitions names within a given 
> definition "class"?
>
> Regards
> Steve B
>
>

Definition names

[Steve Baillargeon]

Hi
The TOSCA YAML Profile is not 100% clear about duplicate definitions names.
What are the guidelines for ARIA?

Should all definitions names be unique across definitions "classes" 
(attributes, properties, requirements, capabilities,...) within a given node 
type definition?
Or is it OK to only have unique definitions names within a given definition 
"class"?

Regards
Steve B

RE: Version for Type Definitions Documents

[Steve Baillargeon]

Hi Tal
I have discussed the NFV Profile with YAML WG today and such profile will 
likely be replaced to become NFV Types 1.0 to import.
I notice those custom types also have the _extensions section.

If I need to define my own custom types, is it best if I also add the 
_extensions section to them?
Maybe it is best to have all types loaded in ARIA with such _extensions section.
Please advise

Thanks again

-Steve


-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, October 24, 2017 7:20 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Version for Type Definitions Documents

We are definitely going with "option A". ARIA aims to support all versions 
TOSCA, not just the latest.

The _extension section is not about version managements, but about providing a 
bridge between YAML and Python code, as well as various debugging information. 
Is is entirely internal to ARIA, as are all these YAML files.

On Tue, Oct 24, 2017 at 5:12 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> I currently see a YAML document called tosca-simple-1.0.yaml that 
> imports the following files:
>
>
>   *   artifactcs.yaml
>   *   capabilities.yaml
>   *   data.yaml
>   *   groups.yaml
>   *   interfaces.yaml
>   *   nodes.yaml
>   *   policies.yaml
>   *   relationships.yaml
>
> Each imported file has a set of normative types and each type provides 
> a reference to a YAML profile specification version.
>
> YAML Profile 1.2 introduces new types.
> YAML Profile 1.2 also makes changes to normative types while keeping 
> the same type name.
>
> Option A. Is the plan to create a tosca-simple-1.2.yaml (eventually) 
> that imports a completely different set of type definitions documents?
>
> Option B. Or is the plan to continue expanding on the existing 
> normative type documents by mixing multiple YAML Profile versions in 
> the same type definitions doc?
>
> I think I prefer option A. In addition, I think we should indicate the 
> YAML specific version in the filename for each definitions document, 
> say capabilities-1.0.yaml.
> I also think the all type definitions documents including the main 
> document (e.g. tosca-simple-1.0.yaml) should include the 
> tosca_definitions_version in the first line.
> This way we can remove the specification keyname in the _extension 
> section for each type definition.
> What do you think?
>
> Regards
> Steve Baillargeon
>
>

Version for Type Definitions Documents

[Steve Baillargeon]

Hi
I currently see a YAML document called tosca-simple-1.0.yaml that imports the 
following files:


  *   artifactcs.yaml
  *   capabilities.yaml
  *   data.yaml
  *   groups.yaml
  *   interfaces.yaml
  *   nodes.yaml
  *   policies.yaml
  *   relationships.yaml

Each imported file has a set of normative types and each type provides a 
reference to a YAML profile specification version.

YAML Profile 1.2 introduces new types.
YAML Profile 1.2 also makes changes to normative types while keeping the same 
type name.

Option A. Is the plan to create a tosca-simple-1.2.yaml (eventually) that 
imports a completely different set of type definitions documents?

Option B. Or is the plan to continue expanding on the existing normative type 
documents by mixing multiple YAML Profile versions in the same type definitions 
doc?

I think I prefer option A. In addition, I think we should indicate the YAML 
specific version in the filename for each definitions document, say 
capabilities-1.0.yaml.
I also think the all type definitions documents including the main document 
(e.g. tosca-simple-1.0.yaml) should include the tosca_definitions_version in 
the first line.
This way we can remove the specification keyname in the _extension section for 
each type definition.
What do you think?

Regards
Steve Baillargeon

RE: Note template names

[Steve Baillargeon]

Hi Tal
Thanks for the info.

In summary, the last imported node template overrides the previous node 
template if they are using the same name.
I feel this is the correct behavior and the only enhancement I see is an 
indication of such occurrence back to the "user".
Another option is to add a system-wide configurable attribute to decide between 
1) override and notify/log (default) versus 2) stop and send error message.

What about node types.
Say I want to override a normative node type with my own custom type using the 
same node type name (yes this is a strange case).
Can I import a custom node type that will override a normative node type?

-Steve

-Original Message-
From: Thomas Nadeau [mailto:tnad...@lucidvision.com] 
Sent: Monday, October 23, 2017 1:38 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Note template names



> On Oct 23, 2017, at 1:12 PM, Tal Liron <t...@cloudify.co> wrote:
> 
> TOSCA says some things about how imports happen, but not that match. I 
> think we are aligned with the spec here.

That is what I suspected, but best to check explicitly.

> By the way, I'm quite proud of the implementation in ARIA: we handle 
> imports in a threadpool, so that if you are importing from many http 
> repositories at the same time, each download will happen simultaneously.
> Performance is as optimal as it can be. (We are also caching the 
> results according to the conditional http request standard.)

I had no reservations about that. 8)

—Tom


> 
> On Mon, Oct 23, 2017 at 12:06 PM, Thomas Nadeau 
> <tnadeaua...@gmail.com>
> wrote:
> 
>> 
>>Just for my own understanding, is the algorithm you describe 
>> used based on what TOSCA specifies,
>> or is this our implementation detail?I ask because you can imagine
>> process done
>> one at a time, i.e.: per-file, but the processed results can of 
>> course, be different.
>> 
>>—Tom
>> 
>> 
>> 
>>> On Oct 23, 2017, at 12:46 PM, Tal Liron <t...@cloudify.co> wrote:
>>> 
>>> Yes, you can do that. Think of imports as being essentially like a 
>>> smart copy-paste from one YAML file to another. In the end, ARIA 
>>> treats it as just one big service template.
>>> 
>>> In other words, the requirements-and-capabilities matching occurs 
>>> only after all imports were done and the final service template is valid.
>>> 
>>> On Mon, Oct 23, 2017 at 10:45 AM, Steve Baillargeon < 
>>> steve.baillarg...@ericsson.com> wrote:
>>> 
>>>> Thank you Tal
>>>> 
>>>> Can ARIA handle the case when ST1 imports ST2 with a relationship 
>>>> (link) between source node template AA defined in ST1 and target 
>>>> node template
>> BB
>>>> defined in ST2?
>>>> For instance, a SoftwareComponent node is defined in ST1 with a 
>>>> specific requirement to run on a Compute node that is defined in ST2.
>>>> 
>>>> -Steve
>>>> 
>>>> -Original Message-
>>>> From: Tal Liron [mailto:t...@cloudify.co]
>>>> Sent: Thursday, October 19, 2017 2:18 PM
>>>> To: dev@ariatosca.incubator.apache.org
>>>> Subject: Re: Note template names
>>>> 
>>>> Some good questions here. Let me try to break it down,
>>>> 
>>>> On Thu, Oct 19, 2017 at 12:39 PM, Steve Baillargeon < 
>>>> steve.baillarg...@ericsson.com> wrote:
>>>> 
>>>>> Node template names must be unique within  a given service template.
>>>>> 
>>>> 
>>>> Yes. Actually, there is an "interesting" issue with this: in YAML, 
>>>> a
>> dict
>>>> could have multiple keys with the same name. What happens in that 
>>>> case
>> is
>>>> that subsequent keys (node template names in this case) override
>> previous
>>>> ones of the same name. So, you can syntactically have two node
>> templates of
>>>> the same name, but only one will count.
>>>> 
>>>> We tried to find ways in ARIA to emit an error in this case, but
>> actually
>>>> it's very hard to do because it's a YAML spec issue that allows it.
>>>> 
>>>> 
>>>>> What about the case when ST1 imports ST2 as follows.
>>>>> ST1 has 2 node templates: template A derived from node type X and 
>>>>> template B derived from node type Y.
>>>>> ST2 has 1 node template: template A derived from node type Z .
>>>>> 
>>>> 
>>>> Actually, the "imports" keyword isn't 100% clear in the TOSCA spec. 
>>>> What we do in ARIA is merge the dicts, and again identical keys 
>>>> (node
>> template
>>>> names) will override without error. So, the final behavior will be 
>>>> undefined.
>>>> 
>>>> However, I think that in this particular case ARIA can do something
>> more,
>>>> because we handle merging ourselves (it's not an issue of the YAML
>> spec). I
>>>> have opened a new JIRA about this:
>>>> https://issues.apache.org/jira/browse/ARIA-390
>>>> 
>> 
>> 

RE: Note template names

[Steve Baillargeon]

Thank you Tal

Can ARIA handle the case when ST1 imports ST2 with a relationship (link) 
between source node template AA defined in ST1 and target node template BB 
defined in ST2?
For instance, a SoftwareComponent node is defined in ST1 with a specific 
requirement to run on a Compute node that is defined in ST2.

-Steve

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, October 19, 2017 2:18 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Note template names

Some good questions here. Let me try to break it down,

On Thu, Oct 19, 2017 at 12:39 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Node template names must be unique within  a given service template.
>

Yes. Actually, there is an "interesting" issue with this: in YAML, a dict could 
have multiple keys with the same name. What happens in that case is that 
subsequent keys (node template names in this case) override previous ones of 
the same name. So, you can syntactically have two node templates of the same 
name, but only one will count.

We tried to find ways in ARIA to emit an error in this case, but actually it's 
very hard to do because it's a YAML spec issue that allows it.


> What about the case when ST1 imports ST2 as follows.
> ST1 has 2 node templates: template A derived from node type X and 
> template B derived from node type Y.
> ST2 has 1 node template: template A derived from node type Z .
>

Actually, the "imports" keyword isn't 100% clear in the TOSCA spec. What we do 
in ARIA is merge the dicts, and again identical keys (node template
names) will override without error. So, the final behavior will be undefined.

However, I think that in this particular case ARIA can do something more, 
because we handle merging ourselves (it's not an issue of the YAML spec). I 
have opened a new JIRA about this:
https://issues.apache.org/jira/browse/ARIA-390

Note template names

[Steve Baillargeon]

Hi
Node template names must be unique within  a given service template.
What about the case when ST1 imports ST2 as follows.
ST1 has 2 node templates: template A derived from node type X and template B 
derived from node type Y.
ST2 has 1 node template: template A derived from node type Z .
Will this work?

Regards
Steve B

RE: Node Template Substitution

[Steve Baillargeon]

Hi Avia
One more question.

Say we have a CSAR that contains multiple TOSCA YAML files e.g. a top-level ST 
and a bunch of low-level STs.
I am assuming all those TOSCA service templates (all of them have a full 
topology section) will be stored as a single “service-template” in ARIA and a 
single unique name is needed to represent such single “service-template” 
composed of multiple topologies.
Is this correct?

-Steve

-Original Message-
From: Steve Baillargeon 
Sent: Wednesday, October 11, 2017 11:29 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi Avia
Is it possible to review the design documentation for it?
Do you have a doc or a few notes describing how ARIA will perform "best 
matching" based on YAML 1.0/1.1 profile?

The full support for NFV Profile 1.0 requires Node Template Substitution 
defined in YAML 1.2 profile.
Any future plans for ARIA to extend Node Template Substitution as defined in 
YAML 1.2 profile ?

Regards
Steve B

-Original Message-
From: Arthur Berezin [mailto:art...@cloudify.co]
Sent: Tuesday, October 10, 2017 12:20 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

Avia, can you please post a link to the design?  thanks

On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat <a...@cloudify.co> wrote:

> Currently the design is finished, and it is on a small hold for now.
> The plan is to support the 1.0/1.1 profile.
>
> On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > Can we have a status update on the availability of the Node Template 
> > Substitution feature (aka substitution mappings)?
> > Will it support the "capabilities" defined in YAML Profile 1.0 or 
> > YAML Profile 1.2?
> >
> > Regards
> > Steve B
> >
> >
>

Service-template name

[Steve Baillargeon]

Hi
When we say service-templates must have unique names, can someone clarify it is 
applicable for all service-templates including plugin service-templates?

Regards
Steve B

RE: Fortigate VNF template

[Steve Baillargeon]

Hi DeWayne
Thank you for the great example.

Two follow-up questions:

1) I don't see the Standard interface definitions for the Openstack related 
nodes in the main service template (except for private_network_subnet). Did I 
miss something?

2) Say I want to use cloud-init to inject data (say one remote IP address and a 
trusted CA certificate) from a config drive when the VNF is initially deployed. 
Should I use/import the Cloudify cloud-init plugin instead?
https://github.com/cloudify-incubator/cloudify-utilities-plugin/tree/master/cloudify_cloudinit

Regards
Steve B

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Wednesday, October 11, 2017 10:08 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Fortigate VNF template

Perfect!

Thx man.

—Tom


> On Oct 11, 2017, at 9:30 AM, DeWayne Filppi  wrote:
> 
> I already provided more detail.  I'll see if I can boil it down into a 
> focused example.
> 
> On Tue, Oct 10, 2017 at 5:02 PM, Tal Liron  wrote:
> 
>> Thanks, Tom. I'm pretty sure there already is just a JIRA... anyway, 
>> I edited yours just to remove the other things, because DeWayne is 
>> reporting a different issue here.
>> 
>> DeWayne, could you you pretty please provide us with something more 
>> than "blows a gasket"? What happens exactly and when, and could you 
>> please try to isolate it to a minimal case?
>> 
>> On Tue, Oct 10, 2017 at 3:24 PM, Thomas Nadeau 
>> 
>> wrote:
>> 
>>> 
>>>I created https://issues.apache.org/jira/browse/ARIA-388 to 
>>> capture this.
>>> 
>>>—Tom
>>> 
>>> 
 On Oct 10, 2017, at 4:09 PM, DeWayne Filppi 
>> wrote:
 
 Ok.  The interesting thing is that not only does it allow you to 
 have ad-hoc inputs, it also blows a gasket when you try to define them.
 
 On Tue, Oct 10, 2017 at 3:02 PM, Tal Liron  wrote:
 
> ARIA right now lets you throw in ad hoc inputs, but I consider 
> this to
>>> be a
> bug. So yes, I would say you absolutely need to declare your inputs.
> 
> On Tue, Oct 10, 2017 at 2:46 PM, DeWayne Filppi 
> 
> wrote:
> 
>> So you'd agree that it should have required an explicit 
>> definition of
>>> the
>> inputs?
>> 
>> On Tue, Oct 10, 2017 at 2:17 PM, Tal Liron  wrote:
>> 
>>> Any help in debugging would be appreciated!
>>> 
>>> On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <
>> dewa...@cloudify.co>
>>> wrote:
>>> 
 For reasons that somewhat mystify me, the template is 
 installing
>> with
>> no
 errors now.  I fixed it by removing the inputs definition I had 
 in
> the
 terminal.yaml file, which is counter-intuitive.  I used to 
 have, in
> the
 node type definition:
 
   interfaces:
 Standard:
   create:
 implementation: cloudify-utilities-plugin > 
 cloudify_terminal.tasks.run
 inputs:
   calls:
 type: list
 entry_schema: call_type
 
 I defined the inputs because I thought I had to.  This was the
>> source
>> of
 the error I mentioned in another thread (regarding yaml-1.1).  
 In
>> any
>>> case,
 by commenting it out, I got no validation errors, and the 
 terminal
>> calls
 are made as expected.  In the node template, I still pass inputs:
 
 interfaces:
   Standard:
 create:
   inputs:
 calls:
   - action: exit
 
 This doesn't seem as though it should be possible.  In any 
 case,
>> the
>>> latest
 has been pushed to the repo:
 https://github.com/dfilppi/fortigate-tosca-example
 
 DeWayne
 
 On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <
> dewa...@cloudify.co>
 wrote:
 
> For those interested, I'm in the process of implementing a 
> TOSCA
>>> template
> for the initial deployment and configuration of a Fortigate 
> VNF in Openstack.  It uses a couple of borrowed Cloudify 
> plugins: one for Openstack itself 
> (https://github.com/cloudify-
>>> cosmo/cloudify-openstack-
> plugin), and one for the terminal plugin (part of the Cloudify
>>> incubator
> "utilities" project (https://github.com/cloudify- 
> incubator/cloudify-utilities-plugin).
> 
> The basic idea is that a network and router is created with 
> public
 access,
> and a private network with no direct public access.  In 
> between is
>> the
> Fortigate firewall VNF that controls 

RE: Node Template Substitution

[Steve Baillargeon]

Hi Avia
Is it possible to review the design documentation for it?
Do you have a doc or a few notes describing how ARIA will perform "best 
matching" based on YAML 1.0/1.1 profile?

The full support for NFV Profile 1.0 requires Node Template Substitution 
defined in YAML 1.2 profile.
Any future plans for ARIA to extend Node Template Substitution as defined in 
YAML 1.2 profile ?

Regards
Steve B

-Original Message-
From: Arthur Berezin [mailto:art...@cloudify.co] 
Sent: Tuesday, October 10, 2017 12:20 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

Avia, can you please post a link to the design?  thanks

On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat <a...@cloudify.co> wrote:

> Currently the design is finished, and it is on a small hold for now.
> The plan is to support the 1.0/1.1 profile.
>
> On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > Can we have a status update on the availability of the Node Template 
> > Substitution feature (aka substitution mappings)?
> > Will it support the "capabilities" defined in YAML Profile 1.0 or 
> > YAML Profile 1.2?
> >
> > Regards
> > Steve B
> >
> >
>

RE: Unique identification of an instance element across services

[Steve Baillargeon]

Hi
About the UUID. 
As far as I know and mentioned a number of times, ARIA already support 
different kinds of ID generation. 
I have nothing to add on this topic.

I would like to focus on the service-template name and the 'already exist' 
error generated by ARIA when the user submits a service-template with a name 
that is "already-in-use".
When will this problem be resolved? Do we have a Jira for it?
As previously indicated, ARIA must allow for duplicate service-template names.

Here are the best practices for API regarding individual resource names and 
resource IDs.

1) The resource name is generated by the API consumer. It is optional. The 
resource name does *not* need to be globally unique. The resource name is 
usually human-readable.
2) If resource name is not generated by the API consumer, the API producer does 
not need to (automatically) generate a resource name. 
3) The resource identifier is generated by the API producer. The resource 
identifier must be "globally unique". The resource ID does not need to be 
human-readable.
4) The API producer must use the resource identifier to uniquely identify the 
resource. It shall not use the resource name for identification purpose. The 
resource name (if provided) is metadata associated with the resource.
5) The API consumer must provide the resource ID when performing an operation 
on an existing resource.

Regarding CLI and the existing Jira.
https://issues.apache.org/jira/browse/ARIA-221
I don't think it is a good idea.
In fact, I think the API guidelines should apply to CLI as well.
The main difference will be on the choice of the resource identifier algorithm.
If CLI user wants a "human-readable" ID, then selects one that is appropriate 
for it.
If API user wants a true UUID, the selects a version 1 UUID for instance.
I suspect the choice of the resource identifier algorithm can be system-wide or 
per interface (?)

-Steve B



-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, October 02, 2017 11:52 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Unique identification of an instance element across services

I suggest that this discussion isn't too important now.

What's important is that we have support for user configuration in ARIA, and 
that it is possible to easily switch between different kinds of ID generation.

Once we have that working, we can go back to discussing what the default should 
be. As users gain some experience playing with different IDs we could get 
feedback.

On Thu, Sep 28, 2017 at 9:29 AM, Vaishnavi K.R 
wrote:

> Thanks Tal.
>
>
> I think many of us are not convinced with the inclusion of the UUID 
> for element identification.
>
> As of now, we have ID for the unique identification. So why should we 
> restrict the users from giving duplicate names for the service templates.
>
>
> I wish to confirm if anyone has a second opinion in allowing duplicate 
> names.
>
> If not, I can raise a JIRA issue and fix it.
>
> Looking forward to your comments.
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron 
> Sent: Tuesday, September 26, 2017 2:04:50 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Unique identification of an instance element across 
> services
>
> DeWayne, I think you missed parts of this discussion where we answered 
> some these issues:
>
> 1) ARIA *does* allow you configure you choice of ID generation, and I 
> agree it can be an integration requirement. (We have a JIRA open to 
> give this configuration a CLI.)
> 2) ARIA has a choice of UUID formats beyond the very long 36-character hex.
> Base57 is 22 characters and designed for human readability.
> 3) All the costs you mention seem very negligible to me. ARIA's 
> database storage is tiny. UUID generation happens only when new nodes 
> are created, and is many orders of magnitude faster than storing anything in 
> a database.
>
> It doesn't easy to resolve this issue, as there are two camps here. 
> But I'm very convinced that Vaish and I are correct here. :) Node (and 
> service) names in the real world are used for other systems beyond 
> ARIA once the nodes are installed: names become domain names linked to 
> IP addresses, names of operating system services, registration IDs for 
> message queues, analytics IDs, etc. For all of these a collision is 
> disastrous, and Vaish is right that if it's set up initially by ARIA 
> there is no need to do anything else.
>
> The only possible user discomfort is in using the "aria nodes show", 
> which frankly is a command that I have never even used myself. As for 
> logs, in any install that has more than one service you will be 
> filtering by workflow ID or service ID anyway.
>
> Also, in case there was any confusion: we are talking about node names 
> here, not database IDs. The database IDs are entirely handled within 
> the database and are obviously unique only per table and per 
> 

Node Template Substitution

[Steve Baillargeon]

Hi
Can we have a status update on the availability of the Node Template 
Substitution feature (aka substitution mappings)?
Will it support the "capabilities" defined in YAML Profile 1.0 or YAML Profile 
1.2?

Regards
Steve B

RE: Relationships and Order of Node instantiation

[Steve Baillargeon]

> As for target_changed, I don't think ARIA checks the state when executing any 
> operation.
YAML profile spec states the following:
"In addition, whenever the node state of its target node changes, the 
target_changed operation is invoked on it to address this change."
I guess ARIA is not compliant here (?).


>> Does the ST designer need to specify an implementation artifact for 
>> such operation?
>No, ARIA will just skip operations without implementations. *However*, 
>it will still change the state accordingly: an operation without an 
>implementation is considered always to succeed in this case. (And the 
>opposite is also true: if an implementation artifact fails to run, the 
>state will not be changed, and indeed the workflow as a whole will 
>fail.)

I think the ST designer needs to specify an implementation for the 
target_changed operation if the ST designer wants the source node to 
change/override its state.
Now looking back I think it is a  bad idea to create an implementation script 
(associated with target_changed operation) that will change the state of the 
source node since it is not the way states are handled in TOSCA.
Node states are always independent regardless of relationships.
Do you agree?

In summary, I think it is better if one completely avoid using the normative 
Configure interface (tosca.interfaces.relationship.Configure) with ARIA or any 
TOSCA orchestrator since the target node is always instantiated before the 
source node and operation interleave is not supported for normative 
deploy/undeploy workflows. 
Bottom-line, it looks like the Configure interface 
(tosca.interfaces.relationship.Configure) is only valid when both source and 
target nodes are instantiated concurrently. Do you agree?

-Steve

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, October 03, 2017 1:11 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Relationships and Order of Node instantiation

On Tue, Oct 3, 2017 at 11:58 AM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

>
> It looks like for the normative install workflow, the target node is 
> always created before the source node regardless of the relationship 
> (and regardless if it is a normative or custom relationship).
> Is this correct? And only a custom workflow can change this "default 
> direction/ordering", right?
>

Correct.


> For instance, if I stop the target node (target node state goes from 
> STARTED to CONFIGURED), will ARIA actually perform a target_changed 
> operation on the source node?
>

How do you stop just one node? You would a custom workflow for that, and I 
imagine behavior would have to be very domain-specific if you want the service 
to remain stable.

As for target_changed, I don't think ARIA checks the state when executing any 
operation. The state is there for you to access and possibly consider when 
implementation the operation. But ARIA can't know what to do.


> If so, what is the information provided in the target_changed?
>

The operation is defined in the normative interface type as empty, without 
inputs.

That said, ARIA provides a rich interface to the complete context:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Context


> Does the ST designer need to specify an implementation artifact for 
> such operation?
>

No, ARIA will just skip operations without implementations. *However*, it will 
still change the state accordingly: an operation without an implementation is 
considered always to succeed in this case. (And the oppoiste is also true: if 
an implementation artifact fails to run, the state will not be changed, and 
indeed the workflow as a whole will fail.)


> In your opinion, should the state of the source node also changed to 
> CONFIGURED in such case, say for a hosted on relationship?
>

My opinion doesn't matter too much here, since we are trying to follow the spec 
as closely as possible... and I recall we had some challenges here, because 
there was some conflicting information.

If you can make a convincing case one way or another, with reference to the 
spec and its potential errors, then of course we can implement it.

RE: Relationships and Order of Node instantiation

[Steve Baillargeon]

Hi Tal
I was trying to clarify how ARIA behaves "by default".
It looks like for the normative install workflow, the target node is always 
created before the source node regardless of the relationship (and regardless 
if it is a normative or custom relationship).
Is this correct?

And only a custom workflow can change this "default direction/ordering", right?

I have a related question about the Configure interface
I know the target_changed operation is supported by ARIA but how far does it go?
For instance, if I stop the target node (target node state goes from STARTED to 
CONFIGURED), will ARIA actually perform a target_changed operation on the 
source node?
If so, what is the information provided in the target_changed?
Does the ST designer need to specify an implementation artifact for such 
operation?
In your opinion, should the state of the source node also changed to CONFIGURED 
in such case, say for a hosted on relationship?

Thanks again for your help.

Regards
Steve B

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, October 03, 2017 12:07 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Relationships and Order of Node instantiation

As far as I can tell we do a general reverse topological sort of the graph, so 
that *all* relationships are considered. So all relationship target nodes would 
appear before relationship source nodes.

I'm not 100% sure this is a great idea. Though all the normative relationships 
seem to have that order -- attaches to, binds to, hosted on, depends on, etc. 
-- users might be creating other directions, or indeed having more complex 
inter-relationships. Of course it's generally impossible to make one size fits 
all, so ARIA at least lets you create your own custom workflows with whatever 
ordering you need.

But I would guess those are edge cases. Are you encountering an issue or just 
generally wondering?

On Mon, Oct 2, 2017 at 4:55 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> What are the normative relationships where ARIA will instantiate the 
> target node before the source node (assuming the install workflow for 
> instance)?
> Are they DependsOn and HostedOn?
>
> Regards
> Steve B
>

Renaming the install and uninstall normative workflows

[Steve Baillargeon]

Hi
The YAML Profile 1.1 has officially named the normative workflows to be:
* deploy: is the workflow used to instantiate and perform the 
initial deployment of the topology.
* undeploy: is the workflow used to remove all instances of a 
topology.
I suggest we rename the current install/uninstall workflows in ARIA with the 
new names.
What do you think?
Regards
Steve B

Relationships and Order of Node instantiation

[Steve Baillargeon]

Hi
What are the normative relationships where ARIA will instantiate the target 
node before the source node (assuming the install workflow for instance)?
Are they DependsOn and HostedOn?

Regards
Steve B

TOSCA state

[Steve Baillargeon]

Hi DJ
Does ARIA  support the "state" runtime attribute that reflects the actual state 
of a node instance?
Does it get its value and any changes to its value from the IaaS plugin in 
real-time including push notification?
If so, how does it map the IaaS resource state value to the TOSCA node state 
value?

Regards
Steve B

RE: Openstack plugin

[Steve Baillargeon]

What is the purpose of the Validation interface with the creation and deletion 
operations?
What workflow invokes those operations?

Thanks

Regards
Steve B

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Sunday, October 01, 2017 10:24 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Openstack plugin

Hi,

The cloudify openstack plugin has validation interfaces, Do they still hold 
good with ARIA with the use of adapter ?


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co]
Sent: Tuesday, August 08, 2017 5:33 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

For future readers of this thread, you can find an example on how to use this 
plugin here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/OpenStack+Hello+World

On Wed, Jul 26, 2017 at 6:25 PM, Maxim Orlov  wrote:

> you got most of it right :). You would need to follow these steps:
> 1. Install the adapter
> 2. Using ARIA, Install the wagon of the plugin.
> 3. Utilize the corresponding plugin.yaml found in the repo in your 
> templates.
>
> The reason the adapter does not come with ARIA is it's an adapter for 
> Cloudify based plugins, and hence it cannot be a part of the ARIA code 
> base.
> In the future ARIA would have its own plugins, and will not need the 
> adapter for Cloudify plugins.
>
> On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Max,
> >
> > IF I understand correctly,
> > we need to take the cloudify openstack plugin and replace 
> > the plugin.yaml with the one found in the repo.
> > Install this updated plugin with ARIA
> > Install the adapter found in this repo to make use of the 
> > plugin
> >
> > Am I right with my understanding ?  Also why this adapter is not 
> > included with ARIA by default ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, July 24, 2017 9:17 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > Hey DJ,
> >
> > Basically ARIA indeed has an adapter for cloudify-based plugins. 
> > This enables support for any cloudify plugins (Provided the 
> > plugin.yaml has
> been
> > translated into TOSCA). Note that later on, ARIA will have native 
> > plugins and will not rely on kindness of Cloudify.
> > You can find the Cloudify repo here
> > . It 
> > holds some examples, the plugin.yaml and the adapter itself.
> >
> > On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Thanks for the information Tal.  What is the adapter which you are 
> > > referring here ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Friday, July 21, 2017 8:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Openstack plugin
> > >
> > > ARIA has an adapter that can use Cloudify plugins, and it has been 
> > > tested successfully with both OpenStack and AWS so far.
> > >
> > > Unfortunately there are no instructions on how to use it. I know 
> > > just the right person to write it and will ask him to do so. :)
> > >
> > > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Will openstack plugin be available as part of any ARIA release ?
> > > > Is this already been looked upon or in the backlog ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[Steve Baillargeon]

Hi
YAML1.0 spec is incorrect for import definitions.
YAML1.2 spec has updated the import grammar as follows.
It will be great for ARIA to support parts of the YAML1.2 spec soon especially 
for areas that are corrected. 

From YAML 1.2 spec:
3.5.8.2 Grammar
Import definitions have one the following grammars:
3.5.8.2.1 Single-line grammar:
imports:
  - 
  - 
3.5.8.2.2 Multi-line grammar
imports:  
  - file: 
repository: 
namespace_uri: 
namespace_prefix: 

-Steve B

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, September 25, 2017 11:39 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

So, this is one of the cases where the spec seems to be wrong: the 
 is probably a mistake. None of the other examples in the spec 
have it, nor do we see it in other TOSCA examples.

Note that if we needed an  than it would even have to be for the 
short form. So:

imports:
 - importname1: myfile.yaml
 - importname2: otherfile.yaml
 - importname3:
 file: lastfile.yaml

The above seems wrong (also, what role does the import name have?). In ARIA we 
treated this as an error in the spec, so we do not have the import name.

On Mon, Sep 25, 2017 at 8:52 AM, D Jayachandran  wrote:

> Hi Tal,
>
> As per the grammer in the SPEC, seems the import should take a 
> . Your example dint have a  but started with 
> respository as such.
>
> :
>
>   file: 
>
>   repository: 
>
>   namespace_uri: 
>
>   namespace_prefix: 
>
>
> With your example can we have multiple repositories ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, September 21, 2017 9:31 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> I do suggest the repository, because it seems like the more TOSCA way 
> to do this. These are special imports that are not part of the CSAR 
> but rather provided in a special way by ARIA. A special repository 
> seems to be the right way to handle this.
>
> On Thu, Sep 21, 2017 at 2:40 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > I had a space between the plugin and filename. The correct one would 
> > like this.
> >
> > import
> >   - plugin:openstack-1.0
> >
> > By this way it won't conflict with YAML convention. Do you still 
> > suggest to use the repository conventions ?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Wednesday, September 20, 2017 9:38 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Contribution for https://issues.apache.org/
> > jira/browse/ARIA-118
> >
> > I think the format you suggest is awkward in YAML. Because ":" is 
> > reserved, you would have to wrap the string in quotes:
> >
> > imports:
> >  - this/is/a/string/import.yaml
> >  - this is also a string .yaml
> >  - "plugins: but here we have to add quotes because of the colon.yaml"
> >
> > The TOSCA way to handle name ambiguity is to use a repository in the 
> > long-form of the import. What we can do is create a built-in 
> > repository called "plugins". So it would look like this:
> >
> > imports:
> >  - mytypes.yaml
> >  - repository: plugins
> >file: openstack.yaml
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 20, 2017 at 3:49 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > With respect to this JIRA issue.
> > > I would like to contribute on the first part, which is specific to 
> > > plugin implementation.
> > >
> > > " If a plugin contained its plugin.yaml as part of its wagon 
> > > archive, then once installed, users could import the yaml file 
> > > more easily using a notation such as plugins/openstack.yaml (or 
> > > perhaps openstack.yaml, having the import mechanism iterate over 
> > > plugins looking for this resource file or so)"
> > >
> > > Instead of "plugins/openstack.yaml", I would like to suggest the 
> > > following
> > > "plugins: openstack-"
> > > Please let me know if this fine with you.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Thursday, July 20, 2017 6:24 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Contribution for https://issues.apache.org/
> > > jira/browse/ARIA-118
> > >
> > > It's unassigned, so I don't see why not!
> > >
> > > On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Do you have any plans on working on this JIRA issue ?
> > > > https://issues.apache.org/jira/browse/ARIA-118
> > > > Can we contribute on this ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

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

ARIA install on virtualenv

[Steve Baillargeon]

Hi Ran
I have installed virtualenv on PC.
Can you send commands to creature a virtualenv and install ARIA in it?

Thank you

-Steve

RE: ARIA install on PC

[Steve Baillargeon]

Hi Ran
Yes it is exactly the same.

I will send you the file in a separate email since the server is removing it.

-Steve

-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Tuesday, August 15, 2017 11:58 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: ARIA install on PC

Hi Steve,

I'd definitely not give up, this seems like a rather weird yet simple error all 
in all :) For some reason you have the wrong file there.
I did not see anything attached.

Is the file you see the same as the CLI exceptions file (i.e.
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/cli/exceptions.py
) ?




On Tue, Aug 15, 2017 at 5:16 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi Ran
>
> Line 20 from version 0.1.1 on my PC has the following line:
> from ..exceptions import AriaError
>
> I have downloaded and install version 0.2.0.
> I have the same error when I run aria --version.
> Line 20 from version 0.2.0 on my PC has the following line:
> from ..exceptions import AriaError
> I have attached the doc.
>
> Should I give up :) ?
>
> -Steve
>
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Tuesday, August 15, 2017 4:29 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: ARIA install on PC
>
> Hi Steve,
>
> It seems like your aria\exceptions.py file is of a wrong version somehow.
> If you take a look at its 0.1.1 revision, you'll see the import line 
> in line 20 (the last line in your stack trace) is a different one than 
> the one mentioned in the error:
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/aria/orchestrator/exceptions.py#L20
> (The same line appears in the 0.1.0 and master revisions, by the way)
>
> A quick search for "from ..exceptions import AriaError" shows that 
> this line only appears in the aria/cli/exceptions.py module (in line 
> 20 as well)
> - I'd suggest maybe somehow this module gets loaded instead of the 
> right one, if I didn't have the stack trace to show me that it's 
> specifically "aria/exceptions.py" that's loaded - But try to open the 
> "aria/exceptions.py" file and see if it might look like this:
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/aria/cli/exceptions.py
>
>
> Ran
>
>
>
>
>
> On Mon, Aug 14, 2017 at 10:59 PM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > I am trying to install ARIA on PC.
> > It appears the install is successful but ARIA is not working as expected.
> >
> > This is what I have on PC:
> >
> >
> >   *   Windows 7, 32 bits
> >   *   pip version 9.0.1
> >   *   python 2.7.9
> >   *   setuptools 36.2.7
> >
> > When I try to install ARIA ( I tried a couple of times), this is 
> > what I
> > get:
> >
> > C:\Users\estebai\Documents\incubator-ariatosca-0.1.1>pip install .
> > Processing c:\users\estebai\documents\incubator-ariatosca-0.1.1
> >   Requirement already satisfied (use --upgrade to upgrade):
> > apache-ariatosca==0.1.1 from file:///C:/Users/estebai/
> > Documents/incubator-ariatosca-0.1.1 in c:\python27\lib\site-packages 
> > Requirement already satisfied: requests<2.14.0,>=2.3.0 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: networkx<1.10,>=1.9 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: retrying<1.4.0,>=1.3.0 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: blinker<1.5,>1.3 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: jsonpickle<=0.9.4,>0.9.0 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: ruamel.yaml<0.12.0,>=0.11.12 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: Jinja2<2.9,>=2.8 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: shortuuid<0.6,>=0.5 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: CacheControl[filecache]<0.13,>=0.11.0
> > in c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: clint<0.6,>=0.5.0 in 
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> > Requirement already satisfied: SQLAlchemy<1.2,>=1.1.0 in 
> > c:\python27\lib\site-packages (fr

Re: ARIA install on MAC

[steve . baillargeon]

Hi Ran
I succeeded to upgrade setuptools using --user python option.

The pip install did not work.
The error message is operations not permitted.
See below







Exception:
 
Traceback (most recent call last):
 
 File 
"/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/basecommand.py", 
line 215, in main
 
 status = self.run(options, args)
 
 File 
"/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/commands/install.py",
 line 342, in run
 
 prefix=options.prefix_path,
 
 File 
"/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_set.py", 
line 778, in install
 
 requirement.uninstall(auto_confirm=True)
 
 File 
"/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_install.py", 
line 754, in uninstall
 
 paths_to_remove.remove(auto_confirm)
 
 File 
"/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_uninstall.py",
 line 115, in remove
 
 renames(path, new_path)
 
 File 
"/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/utils/__init__.py", 
line 267, in renames
 
 shutil.move(old, new)
 
 File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py",
 line 302, in move
 
 copy2(src, real_dst)
 
 File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py",
 line 131, in copy2
 
 copystat(src, dst)
 
 File 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py",
 line 103, in copystat
 
 os.chflags(dst, st.st_flags)
 
OSError: [Errno 1] Operation not permitted: 
'/var/folders/73/sq1jnvgx0l7_18h9kc7v09_rgp/T/pip-w_p4Ck-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/six-1.4.1-py2.7.egg-info'

 

> 
> 
> 
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]  
> Sent: Monday, August 14, 2017 7:13 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: ARIA install on MAC
> 
> Hi Steve,
> 
> It does sound like an issue related to the setuptools version. What made you 
> unable to upgrade it?
> 
> Also, these links might be helpful:
> https://bitbucket.org/ruamel/yaml/issues/86/osx-cannot-install
> https://bitbucket.org/ruamel/yaml/issues/32/cannot-run-setup-script-on-python-2710
> https://bitbucket.org/ruamel/yaml/issues/37/osx-not-able-to-install-using-pip
> 
> 
> Ran
> 
> On Mon, Aug 14, 2017 at 7:08 PM,  wrote:
> 
> > Hi
> > I am trying to install ARIA on MACBook Pro.
> > It did not work.
> > See below.
> > Please advise.
> >
> > This is what I have running:
> >
> > - MacOS Sierra
> > - pip version 9.0.1
> > - Python version 2.7.10
> > - setuptools 18.5 ( I could not upgrade it)
> >
> > This is the error message I got during ARIA install:
> >
> > >
> > >
> > > Command "python setup.py egg_info" failed with error code 1 in
> > /private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn
> > /T/pip-build-Gjmmpp/ruamel.yaml/
> > >
> > >
> >
> >
> > Complete output is below
> >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > >
> > >
> > > Steves-Macbook-Pro:Documents steve$ cd incubator-ariatosca-0.1.1/
> > >
> > > Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ ls
> > >
> > > CHANGELOG.rst MANIFEST.in VERSION examples setup.py
> > >
> > > CONTRIBUTING Makefile appveyor.yml extensions tests
> > >
> > > DISCLAIMER NOTICE aria requirements.in tox.ini
> > >
> > > LICENSE README.rst docs requirements.txt
> > >
> > > Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ pip install .
> > >
> > > Processing /Users/steve/Documents/incubator-ariatosca-0.1.1
> > >
> > > Collecting requests<2.14.0,>=2.3.0 (from apache-ariatosca==0.1.1)
> > >
> > > Downloading requests-2.13.0-py2.py3-none-any.whl (584kB)
> > >
> > > 100% || 593kB 759kB/s
> > >
> > > Collecting networkx<1.10,>=1.9 (from apache-ariatosca==0.1.1)
> > >
> > > Downloading networkx-1.9.1-py2.py3-none-any.whl (1.2MB)
> > >
> > > 100% || 1.2MB 673kB/s
> > >
> > > Collecting retrying<1.4.0,>=1.3.0 (from apache-ariatosca==0.1.1)
> > >
> > > Downloading retrying-1.3.3.tar.gz
> > >
> > > Collecting blinker<1.5,>1.3 (from apache-ariatosca==0.1.1)
> > >
> > > Downloading blinker-1.4.tar.gz (111kB)
> > >
> > > 100% || 112kB 1.4MB/s
> > >
> > > Collecting jsonpickle<=0.9.4,>0.9.0 (from apache-ariatosca==0.1.1)
> > >
> > > Downloading jsonpickle-0.9.4.tar.gz (65kB)
> > >
> > > 100% || 71kB 3.3MB/s
> > >
> > > Collecting ruamel.yaml<0.12.0,>=0.11.12 (from 
> > > apache-ariatosca==0.1.1)
> > >
> > > Downloading ruamel.yaml-0.11.15.tar.gz (223kB)
> > >
> > > 100% || 225kB 1.7MB/s
> > >
> > > Complete output from command python setup.py egg_info:
> > >
> > > Traceback (most recent call last):
> > >
> > > File "", line 1, in 
> > >
> > > File "/private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn
> > /T/pip-build-Gjmmpp/ruamel.yaml/setup.py", line 715, in 
> > >
> > > 

RE: ARIA install on PC

[Steve Baillargeon]

Hi Ran

Line 20 from version 0.1.1 on my PC has the following line:
from ..exceptions import AriaError

I have downloaded and install version 0.2.0.
I have the same error when I run aria --version.
Line 20 from version 0.2.0 on my PC has the following line:
from ..exceptions import AriaError
I have attached the doc.

Should I give up :) ?

-Steve

-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Tuesday, August 15, 2017 4:29 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: ARIA install on PC

Hi Steve,

It seems like your aria\exceptions.py file is of a wrong version somehow.
If you take a look at its 0.1.1 revision, you'll see the import line in line 20 
(the last line in your stack trace) is a different one than the one mentioned 
in the error:
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/orchestrator/exceptions.py#L20
(The same line appears in the 0.1.0 and master revisions, by the way)

A quick search for "from ..exceptions import AriaError" shows that this line 
only appears in the aria/cli/exceptions.py module (in line 20 as well)
- I'd suggest maybe somehow this module gets loaded instead of the right one, 
if I didn't have the stack trace to show me that it's specifically 
"aria/exceptions.py" that's loaded - But try to open the "aria/exceptions.py" 
file and see if it might look like this:
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/cli/exceptions.py


Ran





On Mon, Aug 14, 2017 at 10:59 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> I am trying to install ARIA on PC.
> It appears the install is successful but ARIA is not working as expected.
>
> This is what I have on PC:
>
>
>   *   Windows 7, 32 bits
>   *   pip version 9.0.1
>   *   python 2.7.9
>   *   setuptools 36.2.7
>
> When I try to install ARIA ( I tried a couple of times), this is what 
> I
> get:
>
> C:\Users\estebai\Documents\incubator-ariatosca-0.1.1>pip install .
> Processing c:\users\estebai\documents\incubator-ariatosca-0.1.1
>   Requirement already satisfied (use --upgrade to upgrade):
> apache-ariatosca==0.1.1 from file:///C:/Users/estebai/
> Documents/incubator-ariatosca-0.1.1 in c:\python27\lib\site-packages 
> Requirement already satisfied: requests<2.14.0,>=2.3.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: networkx<1.10,>=1.9 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: retrying<1.4.0,>=1.3.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: blinker<1.5,>1.3 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: jsonpickle<=0.9.4,>0.9.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: ruamel.yaml<0.12.0,>=0.11.12 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: Jinja2<2.9,>=2.8 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: shortuuid<0.6,>=0.5 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: CacheControl[filecache]<0.13,>=0.11.0 
> in c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: clint<0.6,>=0.5.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: SQLAlchemy<1.2,>=1.1.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: wagon==0.6.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: bottle<0.13,>=0.12.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Collecting setuptools<36.0.0,>=35.0.0 (from apache-ariatosca==0.1.1)
>   Using cached setuptools-35.0.2-py2.py3-none-any.whl
> Requirement already satisfied: click<7.0,>=6.0 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: colorama<=0.3.9,>=0.3.7 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: PrettyTable<0.8,>=0.7 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: click_didyoumean==0.0.3 in 
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: 
> backports.shutil_get_terminal_size==1.0.0
> in c:\python27\lib\site-packages (from apache-ariatosca==0.1.1) 
> Requirement already satisfied: logutils==0.3.4.1 in 
> c:\python27\lib\site-packages (from

ARIA install on PC

[Steve Baillargeon]

tory: 
C:\Users\estebai\AppData\Local\pip\Cache\wheels\dd\c4\fc\b0237b1a121736cd985968b1076a4ca596761c4c5970e3d9c9
Successfully built apache-ariatosca
Installing collected packages: setuptools
  Found existing installation: setuptools 36.2.7
Uninstalling setuptools-36.2.7:
  Successfully uninstalled setuptools-36.2.7
Successfully installed setuptools-35.0.2

However when I type the command aria -version, this is what I get:

C:\Users\estebai\Documents\incubator-ariatosca-0.1.1>aria --version
Traceback (most recent call last):
  File "C:\Python27\Scripts\aria-script.py", line 11, in 
load_entry_point('apache-ariatosca==0.1.1', 'console_scripts', 'aria')()
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 560, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 2648, in 
load_entry_point
return ep.load()
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 2302, in 
load
return self.resolve()
  File "C:\Python27\lib\site-packages\pkg_resources\__init__.py", line 2308, in 
resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "C:\Python27\lib\site-packages\aria\__init__.py", line 26, in 
from .orchestrator.decorators import workflow, operation  # pylint: 
disable=wrong-import-position
  File "C:\Python27\lib\site-packages\aria\orchestrator\__init__.py", line 20, 
in 
from .decorators import (
  File "C:\Python27\lib\site-packages\aria\orchestrator\decorators.py", line 
25, in 
from . import context
  File "C:\Python27\lib\site-packages\aria\orchestrator\context\__init__.py", 
line 20, in 
from . import workflow, operation
  File "C:\Python27\lib\site-packages\aria\orchestrator\context\workflow.py", 
line 23, in 
from .exceptions import ContextException
  File "C:\Python27\lib\site-packages\aria\orchestrator\context\exceptions.py", 
line 20, in 
from ..exceptions import OrchestratorError
  File "C:\Python27\lib\site-packages\aria\orchestrator\exceptions.py", line 
20, in 
from ..exceptions import OrchestratorError
  File "C:\Python27\lib\site-packages\aria\exceptions.py", line 20, in 
from ..exceptions import AriaError
ValueError: Attempted relative import beyond toplevel package


Regards
Steve Baillargeon

ARIA install on MAC

[steve . baillargeon]

Hi 
I am trying to install ARIA on MACBook Pro.
It did not work. 
See below.
Please advise.

This is what I have running:

- MacOS Sierra
- pip version 9.0.1
- Python version 2.7.10
- setuptools 18.5 ( I could not upgrade it)

This is the error message I got during ARIA install:

> 
> 
> Command "python setup.py egg_info" failed with error code 1 in 
> /private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn/T/pip-build-Gjmmpp/ruamel.yaml/
> 
> 


Complete output is below 

> 
> 
> 
> 
> 


> 
> 
> Steves-Macbook-Pro:Documents steve$ cd incubator-ariatosca-0.1.1/
> 
> Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ ls
> 
> CHANGELOG.rst MANIFEST.in VERSION examples setup.py
> 
> CONTRIBUTING Makefile appveyor.yml extensions tests
> 
> DISCLAIMER NOTICE aria requirements.in tox.ini
> 
> LICENSE README.rst docs requirements.txt
> 
> Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ pip install .
> 
> Processing /Users/steve/Documents/incubator-ariatosca-0.1.1
> 
> Collecting requests<2.14.0,>=2.3.0 (from apache-ariatosca==0.1.1)
> 
>  Downloading requests-2.13.0-py2.py3-none-any.whl (584kB)
> 
>  100% || 593kB 759kB/s 
> 
> Collecting networkx<1.10,>=1.9 (from apache-ariatosca==0.1.1)
> 
>  Downloading networkx-1.9.1-py2.py3-none-any.whl (1.2MB)
> 
>  100% || 1.2MB 673kB/s 
> 
> Collecting retrying<1.4.0,>=1.3.0 (from apache-ariatosca==0.1.1)
> 
>  Downloading retrying-1.3.3.tar.gz
> 
> Collecting blinker<1.5,>1.3 (from apache-ariatosca==0.1.1)
> 
>  Downloading blinker-1.4.tar.gz (111kB)
> 
>  100% || 112kB 1.4MB/s 
> 
> Collecting jsonpickle<=0.9.4,>0.9.0 (from apache-ariatosca==0.1.1)
> 
>  Downloading jsonpickle-0.9.4.tar.gz (65kB)
> 
>  100% || 71kB 3.3MB/s 
> 
> Collecting ruamel.yaml<0.12.0,>=0.11.12 (from apache-ariatosca==0.1.1)
> 
>  Downloading ruamel.yaml-0.11.15.tar.gz (223kB)
> 
>  100% || 225kB 1.7MB/s 
> 
>  Complete output from command python setup.py egg_info:
> 
>  Traceback (most recent call last):
> 
>  File "", line 1, in 
> 
>  File 
> "/private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn/T/pip-build-Gjmmpp/ruamel.yaml/setup.py",
>  line 715, in 
> 
>  main()
> 
>  File 
> "/private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn/T/pip-build-Gjmmpp/ruamel.yaml/setup.py",
>  line 712, in main
> 
>  setup(**kw)
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py",
>  line 111, in setup
> 
>  _setup_distribution = dist = klass(attrs)
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/dist.py",
>  line 272, in __init__
> 
>  _Distribution.__init__(self,attrs)
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py",
>  line 287, in __init__
> 
>  self.finalize_options()
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/setuptools/dist.py",
>  line 326, in finalize_options
> 
>  ep.require(installer=self.fetch_build_egg)
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 2385, in require
> 
>  reqs = self.dist.requires(self.extras)
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 2617, in requires
> 
>  dm = self._dep_map
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 2606, in _dep_map
> 
>  if invalid_marker(marker):
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 1424, in is_invalid_marker
> 
>  cls.evaluate_marker(text)
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 1549, in _markerlib_evaluate
> 
>  env = cls._translate_metadata2(_markerlib.default_environment())
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 1537, in _translate_metadata2
> 
>  for key, value in env
> 
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources/__init__.py",
>  line 1536, in 
> 
>  (key.replace('.', '_'), value)
> 
>  ValueError: too many values to unpack
> 
>  
> 
>  
> 
> Command "python setup.py egg_info" failed with error code 1 in 
> /private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn/T/pip-build-Gjmmpp/ruamel.yaml/
> 
>

Import definition for top-level service template

[Steve Baillargeon]

Quick questions about YAML 1.0 and substitution mappings
In section 2.10.2 where it shows the definition of the top-level service 
template.
The example does not show the import definitions.
Can you confirm the top-level service template must import the substituting 
service template(s)?
Will ARIA currently generate a validation error if the import definition is 
missing in such case?
Will ARIA currently generate a validation error if a valid import definition is 
provided but does not contain the definitions for the abstract node?
The text refers to a "substitutable directive" in the top-level service 
template. Is Datapoint_enpoint=db the "substitutable directive"?
Regards
Steve B

RE: Service Composition / Substitution Mapping

[Steve Baillargeon]

Hi
I have looked at the data you have provided.
I am trying to catch up (understand) to current ARIA support for substitution 
mapping.
What is supported today and what are the limitations/considerations?
What is missing (hence the need for full implementation)?
Do you have an working example or set of guidelines for using substitution 
mapping today? 
Or should I avoid it completely for now?

- Steve B

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, August 07, 2017 8:41 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

Well, this is exactly what policies are for. :)

Again, I think the rule of thumb should be that users put policies in place
*only* if the defaults do not suffice.

On Mon, Aug 7, 2017 at 6:42 PM, Ran Ziv  wrote:

> The sensible defaults Tal's mentioned sound indeed sensible to me.
> I'd also like users to have control over this, though I'm a bit 
> worried about us getting too carried away with how arbitrarily we use 
> policies for configuring, well, pretty much anything. It might not be 
> a problem right now but I'm not certain that will remain the case in 
> the future when the number of them grows..
>
>
> On Wed, Aug 2, 2017 at 7:14 PM, Tal Liron  wrote:
>
> > Our goal with adding new "conventions" to ARIA, such as policies, is 
> > to always make them optional. The idea is that a plain-vanilla TOSCA
> template
> > would "just work" in ARIA via sensible defaults. The extra stuff is 
> > there if you know you are using ARIA and you want to make use of its 
> > features.
> > (The opposite is true, too: we make sure that any additions are 
> > still
> pure
> > TOSCA and would be parsed validly by other TOSCA parsers.)
> >
> > On Wed, Aug 2, 2017 at 9:08 AM, DeWayne Filppi 
> > wrote:
> >
> > > Cool.  Missed that.  That leaves things almost completely wide 
> > > open
> from
> > > the orchestrator side, IOW few predefined keys.  Too few IMHO, but 
> > > if everyone uses ARIA conventions it could work.
> > >
> > > On Tue, Aug 1, 2017 at 11:49 PM, Tal Liron  wrote:
> > >
> > > > I agree! Luckily metadata exists in the 1.0 spec. :)
> > > >
> > > > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#_
> > Toc379455044
> > > >
> > > > On Tue, Aug 1, 2017 at 7:16 PM, DeWayne Filppi 
> > > > 
> > > > wrote:
> > > >
> > > > > It occurs that it might be useful to be able to tag service
> templates
> > > > with
> > > > > arbitrary meta-data.  Perhaps at one level carried forward 
> > > > > from a
> > CSAR
> > > > > manifest, but also user definable.  This would allow 
> > > > > inter-service references to be definitive, if desired.  This 
> > > > > could be implicitly
> > > > defined
> > > > > as a capability by the orchestrator, but some kind of special
> > > requirement
> > > > > type(s) would be needed to utilize it.  This way, external 
> > > > > repos
> > could
> > > be
> > > > > used safely and directly without the separate load step.
> > > > >
> > > > > On Tue, Aug 1, 2017 at 12:43 PM, Tal Liron 
> wrote:
> > > > >
> > > > > > Thanks for the kudos. :)
> > > > > >
> > > > > > This topic was discussed on this list a while ago. It's 
> > > > > > indeed
> > tricky
> > > > to
> > > > > > get right, because TOSCA leaves a lot of room for the
> orchestrator
> > to
> > > > > > implement.
> > > > > >
> > > > > > I'm thinking of it working something like this:
> > > > > >
> > > > > > 1. The reqs-and-caps engine by default will always look for
> > > satisfiable
> > > > > > capabilities within the currently instantiated service. 
> > > > > > HOWEVER,
> if
> > > > such
> > > > > a
> > > > > > capability is not present, the option is there to look for
> another
> > > > > > instantiated service that exposes the capabilities in
> substitution
> > > > > > mappings.
> > > > > >
> > > > > > 2. If we DON'T have another instantiated service, but DO 
> > > > > > have a
> > > service
> > > > > > template that could fit the bill, perhaps we need to 
> > > > > > instantiate
> > that
> > > > > other
> > > > > > service first. One obvious option is to do this automatically.
> But
> > I
> > > > feel
> > > > > > like this can create unforeseen consequences -- for example, 
> > > > > > some
> > > dummy
> > > > > > test template that someone happened to have in the database 
> > > > > > might
> > get
> > > > > > instantiated by mistake. Also, it might need to trigger 
> > > > > > multiple
> > > > install
> > > > > > workflows at once... a big mess. So I suggest that instead 
> > > > > > we
> > > provide a
> > > > > > very detailed validation error here saying that the 
> > > > > > requirement
> > > cannot
> > > > be
> > > > > > satisfied, HOWEVER there exist service templates A, B, and C 
> > > > > > that
> > can
> > > > > > substitute for us, so maybe the 

RE: Version support for different TOSCA types

[Steve Baillargeon]

Hi Tal

I see that TOSCA version is optional for all types. 
Clearly it is not used for "identification purpose".

However the definition of the TOSCA version seems to be for a different purpose.
Here is a snippet:
It is important to provide a reliable, normative means to represent a version 
string which enables the comparison and management of types and templates over 
time. 
Therefore, the TOSCA TC intends to provide a normative version type (string) 
for this purpose in future Working Drafts of this specification.

I also see text about TOSCA version comparison.

It  seems like TOSCA version can be used by the parser to show differences 
between 2 templates or to highlight types with different versions in the same 
template.
I think this is a useful feature to add to ARIA. What do you think?

In general, what is the process to request an enhancement to ARIA?

 
Cheers
Steve B




-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, August 08, 2017 9:07 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Version support for different TOSCA types

My understanding has been that this is simply internal metadata, like the 
"description" field. There also does not seem any way to access the version, 
e.g. by an intrinsic function.

ARIA identifies a type by its name only, not by its version, so for the same 
parsing session you cannot have two types of the same name even if their 
version is different. If your understanding for TOSCA 1.0 is different, and you 
please show me an example of different use?

On Tue, Aug 8, 2017 at 2:28 AM, D Jayachandran 
wrote:

> Ok Tal, I agree with having a property datatype as version and using 
> them in my implementations. But to re-iterate I see the support for 
> version metadata for different types ( node, artifact, attribute, 
> capability, requirements ) in TOSCA 1.0 profile too. You can check the 
> section starting from "3.6.3 Artifact Type".
>
> Example from SPEC:
>
> 3.6.8.2
> Grammar
> Node Types
> have following grammar
> :
> <
> node_type_name
> >:
> derived_from: <
> parent_node_type_name
> >
> version: <
> version_number
> >
> description: <
> node_type_description
> >
> properties:
> <
> property_definitions
> >
> attributes:
> <
> attribute_definitions
> >
> requirements:
> -
> <
> requirement_definitions
> >
> capabilities:
> <
> capability_definitions
> >
> interfaces:
> <
> interface_definitions
> >
> artifacts:
> <
> artifact_definitions
> >
>
> Even am trying to understand the use-case which can be mapped to 
> version support with each of types.
>
> Is it like we can have same custom node types with different 
> version in my service template ?
> In that case how can the node template choose a particular 
> version of the custom node type ?
> Or Is the version only for the template author to track 
> changes about custom types over time ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, August 08, 2017 12:11 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Version support for different TOSCA types
>
> There is no special use of versions in TOSCA 1.0: it is up to you to 
> define properties or attributes or inputs of the "version" data type 
> and do with those as you please in your operation implementations. 
> TOSCA 1.1 takes it a step further and provides standardized metadata to nodes.
>
> It seems that you have a particular use case in mind. Can you 
> elaborate it to us? Perhaps we can together brainstorm a solution,
>
> On Tue, Aug 8, 2017 at 1:05 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > I agree version is now looked upon as a "data type" now. But does 
> > the orchestrator has any scope when it comes to comparing node types 
> > or templates depending on the version specified ?
> > Am more interested in this statement where the version is looked 
> > upon as a parameter when defining different types "TOSCA supports 
> > the concept of “reuse” of type definitions, as well as template 
> > definitions which could be version and change over time. "
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Monday, August 07, 2017 9:04 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Version support for different TOSCA types
> >
> > OK, you are referring to the "version" data type, and it is fully 
> > supported in ARIA, which includes:
> >
> > 1. Strict adherence to the (rather odd) specification and its regex 2.
> > Proper support for TOSCA comparative constraints for versions 
> > (greater_than, lesser_than, etc.) 3. Comparisons also work properly 
> > in Python when comparing version instances
> >
> > On Mon, Aug 7, 2017 at 12:22 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > I was referring to the section 3.2.2  in TOSCA 

Node types

[Steve Baillargeon]

Hi Tal

Q1
I see normative node types in the YAML spec. Here it makes sense to call them 
normative node types :)
I see non-normative node types in the YAML spec. Here it makes sense to call 
them normative node types :)
I also know the template author can create its own node types. Should I call 
them custom node types (which are also classified as non-normative)?

Q2
Can you confirm ARIA will ensure all node types including non-normative and 
custom will support the Standard lifecycle interface since I see the Standard 
interface defined as part of tosca.nodes.Root?

Q3
Do you have any guidelines about when it is best to create a new custom node 
type that is derived from root vs derived from an existing normative node type?
Does ARIA care?

Q4
I see the normative (generic) SoftwareComponent node type that must be hosted 
on a Compute node.
If  a "specific SW component" must be hosted on a VDU.Compute node instead, 
then I assume it is not possible to derive the specific SW component node type 
from the normative SoftwareComponent node type (?)


Regards
Steve

Workflow graph, Juju charm and node states

[Steve Baillargeon]

Hi Tal

1) Is it possible to send me an example of a custom workflow graph?

I am trying to visualize such graph or use it in my presentation



2) When executing an operation associated with a "script", what are the main 
implications or differences between executing a Juju charm vs executing a shell 
script.

Is it something like this?

- a shell script is an artifact that is included in the CSAR and is likely 
executed by the local TOSCA ARIA orchestrator

- a juju charm is not an artifact (therefore not included in the CSAR) and is 
likely executed by a remote Juju service orchestrator



3) Is it possible to create custom node states using TOSCA/ARIA?

I suspect custom node states cannot be defined in the TOSCA service template 
and must be implemented directly by the TOSCA orchestrator (?).



4) Also related to node states. It looks like the YAML specs has a couple of 
discrepancies for the normative uninstall workflow (section 5.7.4.4.2 in YAML 
1.0).

IMO the available state is not defined and the diagram at the top of the 
workflow should use the started state instead.

IMO the configured state at the bottom of the workflow diagram should be 
replaced with the initial state instead.

Do you agree?



Thanks

Regards
Steve B

RE: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Steve Baillargeon]

Hi
Do you intend to introduce "other levels" or just one label for beginners?
If you only need one level, then maybe it is best to call it "simple" or 
'basic"?

Hi Avia and Tal,
Is it possible to store the quick introduction to TOSCA and theoretical 
overview for everyone to see?
Thanks

Steve B




-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Monday, July 10, 2017 4:39 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

I'm all for it, though I don't really like "entry-level" for the name of the 
label :) Any other suggestions?


On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament 
wrote:

> I think it's a good idea.  Lots of other projects do something 
> similar.  We could link to a query with this from the proposed 
> contributing guide I emailed about earlier.  If we put the 
> contributing guide on confluence, I believe we can even embed a report.
>
> John
>
> On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat  wrote:
>
> > Today Tal (t...@gigaspaces.com) and myself had a very long and 
> > productive face-to-face session with some AT developers about 
> > ARIA. We did a quick introduction to TOSCA (as some of them where 
> > already familiar with it), followed by an theoretical overview and live 
> > demo of ARIA 0.1.0.
> >
> > Some of the AT guys were very interested in contributing to ARIA, 
> > and raised what I think is a very good suggestion. They said that 
> > since sometimes you don't know where to start when contributing to a 
> > large and unfamiliar project, and since some of them or only novice 
> > python programmers, it would very good for them to have Jiras marked 
> > with a special label, such as 'entry-level', to signal that these 
> > Jiras are suitable for beginners.
> >
> > So first, I would like to hear your opinions on this suggestion, and 
> > second, if you support it, maybe you have some better input on the 
> > name
> of
> > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some 
> > other suggestions were 'first-time-contributor' and 'trivial', but 
> > feel free to suggest your own)
> >
> > --
> > Avia Efrat
> > SW Engineer
> > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553> Cloudify | 
> > http://getcloudify.org < 
> > http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
> > 
> > 
> >     >
> > [image: Azure Webinar]
> > <
> > http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
>

RE: imperative workflows (1.1)

[Steve Baillargeon]

Hi
Good information.
How does the user troubleshoot a Python script that is not properly executed by 
ARIA NG?
Any support for CLI or API to inform client and provide cause/reason for error?

-Steve B

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Tuesday, July 04, 2017 4:23 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: imperative workflows (1.1)

Yup. We have given some thought as to how to implement 1.1 workflows including 
conditional tasks ("on_success"/"on_failure") and it maps well into the 
workflow engine, but generally speaking supporting TOSCA 1.1 is not currently a 
top item.

On Tue, Jul 4, 2017 at 8:12 AM, Tal Liron  wrote:

> Not exactly. We do not support TOSCA 1.1 imperative workflows and it's 
> not on the roadmap. Our current plan is to provide a state-of-the-art 
> TOSCA 1.0 implementation, and we're not at 100% completion yet.
>
> That said, we support something we call "custom workflows". They are 
> not defined directly in TOSCA, but rather in a Python function 
> indicated by a TOSCA policy (of type aria.Workflow).
>
> To be honest, you can do a lot more with Python than with TOSCA, but 
> of course we understand that Python is not an option for many users. 
> And of course this is an optional feature.
>
> Bottom line: we do not support TOSCA 1.1 right now, but have a very 
> powerful workaround.
>
> On Mon, Jul 3, 2017 at 3:01 PM, DeWayne Filppi 
> 
> wrote:
>
> > Is there any current support for imperative workflows (ala 1.1)?  If 
> > not, is it a priority roadmap item?
> >
> > --DeWayne
> >
>
>
>
> --
> Tal Liron, Senior Solutions Architect 
> --
> M: +1-312-375-8299 http://cloudify.co @cloudifysource 
> 
> 
> 
> 
>