Re: First Podcast

[Avia Efrat]

Maybe something like
ARIA and TOSCA Podcast - ep01 - Introduction

In addition, create a Youtube playlist for the podcasts.

On Thu, Nov 23, 2017 at 2:54 PM, Thomas Nadeau <tnadeaua...@gmail.com>
wrote:

>
> Fine with me. Thoughts, ideas and suggestions are welcome! *)
>
> —Tom
>
>
> > On Nov 23, 2017, at 3:33 AM, Avia Efrat <a...@cloudify.co> wrote:
> >
> > And maybe make the video name a little bit more descriptive and
> appealing =)
> >
> > On Nov 21, 2017 13:46, "Thomas Nadeau" <tnad...@lucidvision.com> wrote:
> >
> >> Thanks for the correction!
> >>
> >>> On Nov 20, 2017, at 4:52 PM, Miguel Angel Jimenez Achinte <
> >> mig...@rigiresearch.com> wrote:
> >>>
> >>> Hi Tom,
> >>> The correct link is: https://www.youtube.com/watch?v=nZH-Fuo-b7M
> >>>
> >>> Miguel
> >>>
> >>> --
> >>> Miguel Jimenez, PhD student
> >>> Department of Computer Science
> >>> University of Victoria
> >>> Engineering/Computer Science Building (ECS), Room 412
> >>> Victoria, BC
> >>> V8W 3p6 Canada
> >>>
> >>> On Mon, Nov 20, 2017 at 1:50 PM, Thomas Nadeau <tnadeaua...@gmail.com>
> >>> wrote:
> >>>
> >>>>
> >>>>   Hi folks:
> >>>>
> >>>>   Tal and I took a swipe at the project’s first podcast.  This
> >>>> is the link to the podcast:
> >>>>
> >>>> https://www.youtube.com/edit?video_id=nZH-Fuo-b7M <
> >>>> https://www.youtube.com/edit?video_id=nZH-Fuo-b7M>
> >>>>
> >>>>   We plan to do these on some cadence that works with
> >>>> intertwining this with the dev work that is underway. If you have
> >>>> ideas and/or would like to participate, by all means please
> >>>> get in touch with me as we’d love to have you!
> >>>>
> >>>>   —Tom
> >>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: operation dependencies

[Avia Efrat]

Never mind, I already got an answer from the spec =)

On Wed, Nov 22, 2017 at 6:29 PM, Tal Liron <t...@cloudify.co> wrote:

> Less cumbersome, sure. But it also breaks the object-oriented contract.
>
> Imagine this situation: a third party develops a powerful node type (let's
> say: a virtual router) with many well-defined and polished operations on
> custom interfaces (with their own types), custom workflows for various
> advanced features, and even comes with custom ARIA-based tooling for
> real-time analysis and monitoring.
>
> Someone can come along and create a node template based on this node type
> that changes the operation inputs. For this to work properly, that someone
> *should* also provide a new operation implementation that would deal with
> these different inputs. But, these inputs must be sent for this to work: so
> the custom workflows must also be changed, as well as the custom tooling.
> And if new tools come along from that that third party, they will not work.
>
> Object-oriented is cumbersome, sure. :) But that's also the design
> principle of TOSCA, and this is a case that breaks it. We either want our
> node types to have extensible contracts, or allow them to have breakable
> contracts. It doesn't make sense to me to be somewhere in between:
> strictness should be all the way.
>
> Finally, I don't understand this question:
>
> On Wed, Nov 22, 2017 at 7:21 AM, Avia Efrat <a...@cloudify.co> wrote:
>
> > By the way, do you see a way of not being able to derive the value of an
> > intrinsic function's 'result'? (I know it is not currently supported)
> >
>

Re: First Podcast

[Avia Efrat]

And maybe make the video name a little bit more descriptive and appealing =)

On Nov 21, 2017 13:46, "Thomas Nadeau"  wrote:

> Thanks for the correction!
>
> > On Nov 20, 2017, at 4:52 PM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com> wrote:
> >
> > Hi Tom,
> > The correct link is: https://www.youtube.com/watch?v=nZH-Fuo-b7M
> >
> > Miguel
> >
> > --
> > Miguel Jimenez, PhD student
> > Department of Computer Science
> > University of Victoria
> > Engineering/Computer Science Building (ECS), Room 412
> > Victoria, BC
> > V8W 3p6 Canada
> >
> > On Mon, Nov 20, 2017 at 1:50 PM, Thomas Nadeau 
> > wrote:
> >
> >>
> >>Hi folks:
> >>
> >>Tal and I took a swipe at the project’s first podcast.  This
> >> is the link to the podcast:
> >>
> >> https://www.youtube.com/edit?video_id=nZH-Fuo-b7M <
> >> https://www.youtube.com/edit?video_id=nZH-Fuo-b7M>
> >>
> >>We plan to do these on some cadence that works with
> >> intertwining this with the dev work that is underway. If you have
> >> ideas and/or would like to participate, by all means please
> >> get in touch with me as we’d love to have you!
> >>
> >>—Tom
> >>
> >>
> >>
>
>

Re: operation dependencies

[Avia Efrat]

I think keeping the ability to accept ad-hoc inputs (at least for now) is a
good idea =). This will (among other thing) make the job of writing custom
service template less cumbersome. Just mentioning again that this is the
place I see a possible justification for ad-hoc 'additions', as we don't
have an operation type, in contrast to other entities.

the suggestion of 'cfg' is only valid if we enable ad-hoc inputs, so if at
the end we will drop this support, I don't think 'cfg' is a good idea.

By the way, do you see a way of not being able to derive the value of an
intrinsic function's 'result'? (I know it is not currently supported)

On Thu, Nov 9, 2017 at 9:02 PM, Tal Liron <t...@cloudify.co> wrote:

> Thanks for keeping the discussion going, Avia.
>
> Yeah, I do not think that my interpretation is rock solid at all and it's
> definitely forced. It's not hard to find examples in the spec that
> contradict my interpretation, but also there are others that contradict the
> opposite. I think we can all agree at least that the TOSCA spec writers did
> not pin down this topic well enough so it's necessary for us to fill in the
> gaps. I'm still sure that my interpretation is the most inherently correct
> because it preserves the OOP base contract. If we allow ad-hoc inputs we
> are making it that much harder to inherit existing node types while
> expecting their existing implementations to continue working. If we allow
> ah-hoc inputs, why not go ahead and allow a complete free-for-all here and
> allow dynamic monkey patching of derived types? (This is actually what the
> NFV csd04 profile is trying to do: "deprecate" parts of
> tosca.nodes.Compute, which of course will break tooling that relies on that
> contract.) The whole point of having type derivation in TOSCA seems to be
> to allow reuse of tools, and I insist that is especially true for operation
> inputs.
>
> Your idea of supporting a "cfg" (or similar) input in ARIA is something we
> considered. (I don't think it's something we will have in the ARIA profile,
> because we need it supported by *all* operations, including the normative
> ones, and including custom ones created by template writers: so it would be
> have to be hardcoded support in the ARIA codebase.) However, the problem
> with this idea is that non-ARIA TOSCA parsers will fail. The whole idea of
> using the "dependencies" hack was to allow such templates to at least parse
> successfully with other parsers. Their are pros and cons to each approach,
> though, and I'm open to reopening this.
>
> By the way, the next commit to ARIA adds a configuration option for the
> parser: whether to support "ad-hoc inputs" or not. The default is to allow
> them: something that as you know I am very reluctant to do, but feel we
> have no choice at present. But, to do this properly, I think we need to
> also find a way to preserve the type in intrinsic functions, as mentioned
> in this discussion. It would still leave cases where it's possible to have
> type-less inputs, but I guess that's just how it is right now.
>
> [as for the side note: there are *lots* of bugs in the included TOSCA
> examples, including outright typos, so it's hard to consider them as
> canonical...]
>
>
> On Sat, Nov 4, 2017 at 9:26 AM, Avia Efrat <a...@cloudify.co> wrote:
>
> > ​​​I know this is an old thread, but since this is an important issue
> (and
> > I'm doing a review of old and interesting mails), I thought I'll take a
> > shot at a reply.
> >
> > I'm not relying on one example in the spec. actually, we can see that
> > inputs are defined under the normative "Standard" and "Configure"
> > interfaces and their operations many time throughout the spec. Isn't the
> > fact that inputs are assigned to interfaces and operations that do not
> have
> > the corresponding definition, in addition to the sentence from
> [3.5.13.3],
> > in addition to the interfaces being are the only entities in TOSCA that
> do
> > not have explicit distinction between definition and assignment enough to
> > suggest that this may have been intentional?
> >
> > These usages of untyped inputs are still there in v1.2, and
> unfortunately,
> > artifact definitions still do not have a properties-like field.
> >
> > I liked your idea suggesting that "untyped" inputs get their type
> > definition from the intrinsic functions, that seems to settle between the
> > unusualness of interface definitions, and the fact that TOSCA gives us
> the
> > notion that assignment should be derived from a definition. This could
> also
> > be a (temporary?) solution to the lack of "operation type" concep

Re: ariatosca.org sync with git repo: ARIA-400

[Avia Efrat]

I prefer option 1.
But we should take into consideration different README/getting-started for
different ARIA versions. Although if we plan to stabilize the API after the
1.0 release, this is less of an issue.

On Fri, Oct 27, 2017 at 1:14 AM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> I like option 1
>
> Sent from my iPhone
>
> On Oct 26, 2017, at 3:38 PM, Thomas Nadeau > wrote:
>
>
>I wanted to ask peoples’ opinions on this issue.
>
>A little background: after 3 people have come to the project fresh, and
> tried to
> get up and running, they all encountered difficulty with the instructions
> for building
> and setup of the project.  To this end, Vish and I took on the tasks
> related to
> getting this repaired.
>
>The first subtask I took on was ARIA-400. After investigating this
> subtask
> which relates to synchronization of the specific getting started
> information,
> I looked into how the ariatosca.org <
> http://ariatosca.org/> site is built and how it relates to
> the main code repo.
>
>For reference, there are two GitHub repos in question are:
>
> This is a mirror of apache’s repo for the code of the project:
>
> https://github.com/apache/incubator-ariatosca  incubator-ariatosca>
>
> This is a set of self-contained, Jekyll/static web pages.  These are
> reflected (i.e.: copied)
> over to the apache site when PRs are merged:
>
> https://github.com/apache/incubator-ariatosca-website <
> https://github.com/apache/incubator-ariatosca-website>
>
>
> The problem I discovered is that the contents of the main README file:
>
> https://github.com/apache/incubator-ariatosca/blob/master/README.rst <
> https://github.com/apache/incubator-ariatosca/blob/master/README.rst>
>
>has been manually synchronized with its corresponding
> file on the *-website:
>
> https://github.com/apache/incubator-ariatosca-website/
> blob/master/gettingstarted.md  incubator-ariatosca-website/blob/master/gettingstarted.md>
>
>So what has happened over time, is that these two files have
> effectively diverged, and require some manual intervention.  I looked into
> options
> for doing auto-sync after PRs are pushed to either repo (both have CI
> processes
> setup), but I think that a simpler solution is to simply have either of
> the files
> refer to the other, effectively keeping on as the “master of record”.  In
> summary,
> these are the options, so I’d like to get some feedback before taking
> action on
> this:
>
>1) Make the incubator-ariatosca/README.rst point at the file that is on
>the incubator-ariatosca-website/gettingstarted.md (and others).
>
>Put comments instructing anyone wishing to modify the README.rst
> file
>to push changes into the other file/s.
>
>2) The inverse of 1.
>
>
>
>My preference would be for 1
>
>Thanks,
>
>—Tom
>
>
>
>
>
>

Re: operation dependencies

[Avia Efrat]

ng an intrinsic function, which could
> carry the type with it... but nowhere in the spec is any mechanism like
> that explained. Many of the examples in the TOSCA spec are wrong or
> incomplete, too, so I wouldn't be shocked if this one is wrong as well.
>
> Anyway, none of this addresses the core issue in my opinion, which I keep
> returning to: these kinds of parameters we add here -- SSH user, password,
> etc. -- are meant as *directives to our execution plugin*, conceptually
> very different from operation inputs. Mixing them together is confusing
> (what do you do with name overlaps?) as well as a major security concern.
> These two kinds of values simply should not be mixed together. Indeed, in
> TOSCA 1.2 they might end up being artifact properties.
>
>
> On Mon, Sep 11, 2017 at 11:25 AM, Avia Efrat <a...@cloudify.co> wrote:
>
> > In contrary to most of the TOSCA entities, TOSCA does not differentiate
> > between 'definition' and 'assignment' in the context of operations. There
> > are only "operation definitions" [3.5.13]. Logically, there is a partial
> > differentiation [3.5.13.1], where inputs in node type operations are
> > expected to be property definitions, and inputs in node template
> operation
> > are expected to be property assignments (which are actual value
> > assignments). Both of these options are listed under "operation
> > definition".
> >
> > Under [3.5.13.3] it is explicitly stated that
> > "Template authors MAY provide property *assignments* on operation inputs
> on
> > *templates* that do not necessarily have a property definition defined in
> > its corresponding type." (my emphasis)
> >
> > That is, from this paragraph, I think that it is clear that you can
> define
> > operation inputs in node templates (level #3) without them being defined
> in
> > the node template's type. In fact, [2.14.2] is an example of doing just
> > that. And out parser treats such a syntax as valid, see:
> > https://github.com/apache/incubator-ariatosca/blob/
> > master/tests/parser/test_tosca_simple_v1_0/test_end2end.py#L73
> >
> > Me thinking it was a good idea to construct TOSCA that way is another
> thing
> > =)
> >
> > On Mon, Sep 11, 2017 at 6:35 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Feel free to change the wiki, Ran, to whatever name you find
> appropriate.
> > >
> > > I think what Avia discovered is not new to us and actually doesn't
> solve
> > > the problem, unfortunately. Let me go over what is clearly allowed and
> > not
> > > allowed in TOSCA, confusing because there are a few levels of
> inheritance
> > > here.
> > >
> > > 1. Interface types. Obviously, you are allowed to inherit an interface
> > type
> > > and add or override inputs. (ARIA insists that overridden input types
> be
> > > derived from what it is they are overriding, too, to keep the OO
> contract
> > > intact.)
> > >
> > > 2. Node types. In the "interfaces" section you can define several
> > > interfaces of various types. Here, again, TOSCA lets you add/override
> > > inputs. Though note here that the line of inheritance is quite complex:
> > you
> > > can override inputs from the interface type, but *also* from the parent
> > > node type. (ARIA here has to do some work to make sure that you are
> doing
> > > it all OK and not breaking the OO contract, it's a rather complex part
> of
> > > the parser code.)
> > >
> > > I think the above is what Avia discovered. However, the third level is
> > > locked to us:
> > >
> > > 3. Node templates. Unfortunately, here we can not add inputs ad hoc.
> The
> > > "interfaces" section here is not the same DSL format as those above: it
> > is
> > > operation *assignments* rather than operation *definitions*. When you
> > > assign input values here, they are validated against the defined types.
> > It
> > > would make no sense in TOSCA to just assign values without a type.
> > >
> > > So, because we can't add inputs at level #3, we still have a problem:
> we
> > > would have to derive new node types for every type of execution. SSH
> > would
> > > require its own node types, Juju would require its own node types,
> Puppet
> > > would require its own node types, etc. And that's for *all* your node
> > > types. This seems extremely un-scalable.
> > >
> > > But also, as I try to explain in the wiki page, I ins

Re: Node Template Substitution

[Avia Efrat]

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

Re: Node Template Substitution

[Avia Efrat]

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: operation dependencies

[Avia Efrat]

In contrary to most of the TOSCA entities, TOSCA does not differentiate
between 'definition' and 'assignment' in the context of operations. There
are only "operation definitions" [3.5.13]. Logically, there is a partial
differentiation [3.5.13.1], where inputs in node type operations are
expected to be property definitions, and inputs in node template operation
are expected to be property assignments (which are actual value
assignments). Both of these options are listed under "operation
definition".

Under [3.5.13.3] it is explicitly stated that
"Template authors MAY provide property *assignments* on operation inputs on
*templates* that do not necessarily have a property definition defined in
its corresponding type." (my emphasis)

That is, from this paragraph, I think that it is clear that you can define
operation inputs in node templates (level #3) without them being defined in
the node template's type. In fact, [2.14.2] is an example of doing just
that. And out parser treats such a syntax as valid, see:
https://github.com/apache/incubator-ariatosca/blob/master/tests/parser/test_tosca_simple_v1_0/test_end2end.py#L73

Me thinking it was a good idea to construct TOSCA that way is another thing
=)

On Mon, Sep 11, 2017 at 6:35 PM, Tal Liron  wrote:

> Feel free to change the wiki, Ran, to whatever name you find appropriate.
>
> I think what Avia discovered is not new to us and actually doesn't solve
> the problem, unfortunately. Let me go over what is clearly allowed and not
> allowed in TOSCA, confusing because there are a few levels of inheritance
> here.
>
> 1. Interface types. Obviously, you are allowed to inherit an interface type
> and add or override inputs. (ARIA insists that overridden input types be
> derived from what it is they are overriding, too, to keep the OO contract
> intact.)
>
> 2. Node types. In the "interfaces" section you can define several
> interfaces of various types. Here, again, TOSCA lets you add/override
> inputs. Though note here that the line of inheritance is quite complex: you
> can override inputs from the interface type, but *also* from the parent
> node type. (ARIA here has to do some work to make sure that you are doing
> it all OK and not breaking the OO contract, it's a rather complex part of
> the parser code.)
>
> I think the above is what Avia discovered. However, the third level is
> locked to us:
>
> 3. Node templates. Unfortunately, here we can not add inputs ad hoc. The
> "interfaces" section here is not the same DSL format as those above: it is
> operation *assignments* rather than operation *definitions*. When you
> assign input values here, they are validated against the defined types. It
> would make no sense in TOSCA to just assign values without a type.
>
> So, because we can't add inputs at level #3, we still have a problem: we
> would have to derive new node types for every type of execution. SSH would
> require its own node types, Juju would require its own node types, Puppet
> would require its own node types, etc. And that's for *all* your node
> types. This seems extremely un-scalable.
>
> But also, as I try to explain in the wiki page, I insist that these kinds
> of configuration parameters are essentially not the same as operation
> inputs. They are not meant to be used by the operation itself (script,
> charm, recipe, etc.), rather by the mechanism that executes the operation
> (SSH, Juju, Puppet, etc.). Especially I point out the security hole: you
> don't want an SSH password exposed and sent over the wire to the script
> itself. It is simply not an input.
>
> By the way, it seems that there's some acknowledgement by other folk in
> OASIS about this gap in TOSCA, and there's an interest to use artifact
> types in TOSCA 1.2 as a way to solve this problem. I don't think it's a bit
> awkward, but at least there will be a standard solution.
>
>
> On Sun, Sep 10, 2017 at 2:13 AM, Ran Ziv  wrote:
>
> > Avia's mentioned at one point that we might have misunderstood the spec
> at
> > this section, and that in fact it can be possible to pass arbitrary
> inputs
> > into operations regardless of the interface definition - which would mean
> > this notion of  "configuration" might be unnecessary.
> >
> > Also, note that the doc page is talking about "executors", which is
> > confusing as that's a different concept in ARIA (see the base executor
> > class); Supposedly up until now we've simply called these "operation
> > plugins".
> >
> >
> > On Sat, Sep 9, 2017 at 1:43 AM, Tal Liron  wrote:
> >
> > > Yes:
> > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > Execution+Configuration
> > >
> > > On Fri, Sep 8, 2017 at 4:45 PM, DeWayne Filppi 
> > > wrote:
> > >
> > > > I see in the examples a list of dependencies for scripts in
> operations,
> > > for
> > > > example:
> > > >
> > > > implementation:
> > > >   primary: scripts/configure.sh
> > > >   

Substitution Mappings Property Mappings in TOSCA v1.2

[Avia Efrat]

I'm not sure I see a use case of the new properties field that is newly
defined under substitution_mappings in v1.2.

The description is:

"A property mapping allows to map the property of a substituted node type
to a property definition or value (mapped as a constant value property
definition) within the topology template.

A property mapping may refer to an input of the topology, to the property
of a node template in the topology or be assigned to a constant value."


So, as it seems, it allows to assign values, within the substitution
template, to properties defined in the substitution type.

In v1.0 and v1.1, the only use of substitution type properties was in the
top-level template, where the properties (that were defined in the
substitution node type) were assigned values. These values were passed as
inputs during the instantiation of the substituting template.


The only usage of these properties was during the substituting template
instantiating. These properties weren't 'real' in the sense of regular node
properties. The substitutable node isn't a real node in the sense that it
is not instantiated in itself, but only the nodes that it represents.


TOSCA v1.2 introduced the notion of property mapping in substitution
mappings, similar to the notions of capability and requirement mappings in
v1.0.


But, why should we use this property mapping ability, if the only thing
substitution_mappings properties are used for is a medium to transfer input
values?

Re: Support for TOSCA Simple Profile NFV 1.0

[Avia Efrat]

We indeed removed tosca.capabilities.nfv.VirtualStorage requirement from
the VDU.Compute node since this capability is not defined in csd04, but is
just mentioned by name.

The VirtualLinkable capability was in csd03, but removed from the TOSCA
spec in csd04. It seems as a leftover from csd03 that the authors didn't
properly removed all of its mentions. Regarding the reasoning behind this
decision, see the last paragraph of the email.

tosca.relationships.nfv.VirtualLinksTo was in csd03, but removed in csd04.
tosca.relationships.nfv.VDU.AttachedTo wasn't even in csd03.

One might wonder (and indeed you wondered) how to deal with all the missing
parts and inconsistencies throughout the TOSCA NFV specification. The
answer, simply put, is that this is a work in progress, still on a draft
level. A lot of effort is invested currently in TOSCA around the questions
of creating a NFV profile that combines 'naturally' with the simple TOSCA
profile. This is quite an intricate task to be honest. You can try to
contact the authors of the NFV profile for questions and possible
participation.


On Mon, Sep 11, 2017 at 4:35 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> HI Avia,
>
>
>
> I had to post these questions but it took sometime for me.
>
>
>
> With the csd04, I could not see the below capabilities in the spec
>
>
>
> - tosca.capabilities.nfv.VirtualStorage
>
> - tosca.capabilities.nfv.VirtualLinkable
>
>
>
> I think since the capability " tosca.capabilities.nfv.VirtualStorage" is
> missing, you had removed the requirement for "virtual_storage" for a
> VDU.Compute node.
>
> Capability "tosca.capabilities.nfv.VirtualLinkable" is one of the
> requirement "virtual_link" for the node type VduCpd. I see this requirement
> is commented in the node type. Is this a common understanding that the
> VduCpd wont have a requirement on a virtual link ? I believe a VduCpd has
> requirement on both Compute and Virtual link as mentioned in the spec.
>
>
>
>
>
> Also these 2 relationships are missing too from the spec
>
>
>
> - tosca.relationships.nfv.VirtualLinksTo ( Relationship
> of VduCpd with a virtual link )
>
> - tosca.relationships.nfv.VDU.AttachedTo ( Relantionship
> required for virtual storage with compute node)
>
>
>
>
>
> How to address the missing parts from the spec ?
>
>
>
> Regards,
>
> DJ
>
>
>
> -Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Tuesday, June 13, 2017 2:59 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for TOSCA Simple Profile NFV 1.0
>
>
>
> Hi DJ,
>
>
>
> Just updating that the pull request was merged.
>
>
>
> Note that there are some inconsistencies in csd04, so if you have any
> questions regarding our reasoning in resolving them, feel encouraged to ask.
>
>
>
> On Wed, Jun 7, 2017 at 10:09 AM, D Jayachandran <
> d.jayachand...@ericsson.com
>
> > wrote:
>
>
>
> > Thanks for the update Avia.
>
> >
>
> > Regards,
>
> > DJ
>
> >
>
> > -Original Message-
>
> > From: Avia Efrat [mailto:a...@gigaspaces.com]
>
> > Sent: Wednesday, June 07, 2017 3:03 AM
>
> > To: dev@ariatosca.incubator.apache.org<mailto:dev@
> ariatosca.incubator.apache.org>
>
> > Subject: Re: Support for TOSCA Simple Profile NFV 1.0
>
> >
>
> > Hi DJ,
>
> >
>
> > I've created a pull request for the issue that Tal opened:
>
> > https://github.com/apache/incubator-ariatosca/pull/147
>
> > I expect it to be merged on Thursday/Friday.
>
> >
>
> > On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron <t...@gigaspaces.com<mailto:tal
> @gigaspaces.com>> wrote:
>
> >
>
> > > Thanks DJ, I opened a new JIRA issue for this if you want to track it:
>
> > >
>
> > > https://issues.apache.org/jira/browse/ARIA-275
>
> > >
>
> > > It shouldn't be too hard to do, just some busy work in YAML. Anyone
>
> > > on the mailing list want to tackle this?
>
> > >
>
> > > On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran <
>
> > > d.jayachand...@ericsson.com<mailto:d.jayachand...@ericsson.com>>
>
> > > wrote:
>
> > >
>
> > > > Hi,
>
> > > >
>
> > > > I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft
> 03.
>
> > > > The Latest available TOSCA NFV profile is Simple profile NFV 1.0
>
> > > > draft
>
> > 

Re: Service Composition / Substitution Mapping

[Avia Efrat]

On Tue, Sep 5, 2017 at 6:09 PM, Tal Liron  wrote:

>
> Just like you can specify a specific node template for a requirement, I
> believe it can be useful and often necessary to specify a substituted
> service template.
>

​Even​ if it is needed, the question is how to do that. Using a policy
seems too much like a catch-all solution. In the spec, there is the notion
of the "substitutable" directive [2.10.2]. At first I thought it was meant
as a general concept, but then I noticed that:

1. node templates have a `directives` field, that is described as "an
optional list of directive values to provide processing instructions to
orchestrators and tooling" [3.7.3.1].
2. section [2.10.2] does not mention "substitutable directive", but rather
"substitutable" directive. It seems that their intention is the adding the
"substitutable" string to the `directives` field of the node template is
the mean by TOSCA is designating a node to be substituted.
3. section [2.9] extensively deals with abstract nodes. It mentions another
use of the `directives` field, this time the "selectable" directive (also
in [3.7.3.1], [3.7.3.3]).

Although section [3.3.3] states that there are no defined directives in
TOSCA 1.0, the de facto usages of the directive field indicates at least
that there is intent of using this field, and maybe define it more
explicitly in future versions.

Bottom line, currently I see the `directives` field as the the indicator of
substitutable nodes (by specifying the "substitutable" directive). It is
needed to enquire OASIS regarding their future plans of TOSCA.

Re: Service Composition / Substitution Mapping

[Avia Efrat]

1) Substitutable nodes (abstract nodes) are defined by their type. And a
node type should represent specific node/subsystem characteristics. Having
two node types ( with the same name) that represent different logical
entities seems odd, and indicates a possible bug in the design. That is
another reason why using so-called namespaces while creating type
hierarchies is a good practice.

You could argue that if you have multiple sources for templates (e.g. your
own storage and a external catalog), there could be unexpected name
collisions of node types names. Having said that, we need to remember the
entire process of the substitution mapping.

First, as you said, we are trying to locate a service template that has a
substitution mapping definition of the same type of the abstract node in
the top level template. But choosing the service template is only the first
step. The second step is instantiating the top level template along with
the substitution template. During the instantiation, requirements and
capabilities are matched. If not all requirements are satisfied
(considering both top level and substituting template), the substitution
mapping is not considered successful, and the instantiation fails.

If that is the case, it makes sense to go ahead and try the next
substitution template that fits the type, and continue like so until we
find a substitution where all the requirements are satisfied during
instantiation.

At this point you may be wondering, "what if the instantiation was
successful, but the source of the substitution template wasn't the one that
*I* wanted?". Well, You have to think about this issue in substitution
mapping terms. that is, when you use an abstract node, actually what you
are saying is "I want something of type t, the has the capabilities c, and
requires r. regarding the internals, I don't care, I just want it to work".
So actually, selecting a specific substituting template (as long as the
type, the requirements and the capabilities are as expected, of course), is
somewhat against the spirit of the substitution mapping feature.

2) I'm sorry, but I didn't get to the bottom of your question. Could you
elaborate a bit more, and include a small example?




On Thu, Aug 31, 2017 at 11:35 AM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi,
>
> With respect to substituting stored service templates, I have few things
> to be clarified
>
> 1) Handling substitution when multiple service templates matches for the
> abstract node type .
> Would the 1st match would be used for substitution  or Are we
> looking at policy to enable user to select particular service templates for
> substitution with multiple service templates ?
> 2) Custom node types as abstract node type.
> With custom node types as abstract node type, there seems to be a
> need to implicitly import that custom node type in our top level service
> template so that the parser recognizes this custom type.
> Assuming the abstract node type would be substituted from a stored
> substituting service template, we need to at least import the custom node
> types and have it part of the same CSAR package.
> Would this be a challenge for the top-level service template
> author in including and importing the custom node types as abstraction ? or
> Is this how we are looking at custom node types ?
> Is it possible to identify an abstract node during parsing , such
> as if it does not contain any implementation ( The SPEC does not say
> anything on this )?
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Wednesday, August 16, 2017 6:19 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> I agree, especially when the benefit of being able to use an existing
> service - yet only one which hasn't been deployed via a workflow - doesn't
> seem all that interesting IMO.
>
> Another concern I could add to the ones you've mentioned is the service's
> inputs - the substituting template's inputs should be received via the
> properties of the abstract node in the top level service template. If the
> service already exists, these inputs would not be passed as expected.
>
> Ran
>
> On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Ran,
> >
> > When Tal mentioned about "substituting service", I thought it was
> > about the services which dint have any associated executions/workflows
> triggered.
> > Am also in favor of  "substituting service templates" rather than
> > "substituting service".
> > With "substituting service" approach (when the service is not
> > instantiated), I see some open points
> > - In a multi-user scenario, what will happen when a service is
> > composed using the substituting service and at the sametime a
> > workflow is triggered for the substituting service. ?
> > - Is it okay to delete(dissolve) the 

Re: cli throwing PresenterNotFoundError

[Avia Efrat]

A quick late night thought - try this:
https://issues.apache.org/jira/browse/ARIA-110

Another solution, try installing via 'make install' only.

On Fri, Aug 18, 2017 at 3:47 AM, DeWayne Filppi  wrote:

> I'm running 'aria service-template validate' against a CSAR, and getting a
> 'PresenterNotFoundError'.  I installed from source using 'make
> install-virtual'.  Version 0.1.1.
>

Re: Version support for different TOSCA types

[Avia Efrat]

First, I agree with both of you about not adding this currently to the ARIA
core, as it is not certain that it is intended as a part of 1.0

As for I meant by backwards-compatibility, I'll try to give an example:
Suppose there is a cloud-provider database node type: cp.nodes.complexdb,
which corresponds with the cloud-provider's implementation of this
database. You interact with this database via API of version 1.

After a new version (version 2) of the cloud provider is released, a new
configurable feature is added to that database. It still represent the same
type of database (the cloud provider treats it as the same), just with an
extra feature.

In such a case, I don't see an immediate need for a new node type, as the
new database and old database represent the same logical entity. We could
just create a new node type (like cr.nodes.complexdb.v2), but I think using
a different version field better describes the differences between the
version 1 database and version 2 database.



On Wed, Aug 9, 2017 at 4:21 PM, Thomas Nadeau <tnad...@lucidvision.com>
wrote:

>
> > On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > Why just to add functionality? (You should use inheritance in that
> case.) A
> > new version of a type might as well also remove functionality, or really
> > change everything as you said,
> >
> > In any case, TOSCA 1.0 doesn't tell us what to do with versions, so at
> this
> > point we should indeed do nothing in ARIA core.
>
> I’d agree with that. Its tempting to do an ARIA-specificly
> supported
> extension to support this and then offer that as an update to TOSCA, but
> we should think through that carefully if that is indeed what we want to
> do.
>
> —Tom
>
>
> >
> > On Wed, Aug 9, 2017 at 7:19 AM, Avia Efrat <a...@cloudify.co> wrote:
> >
> >> Actually, I can see the version field used as a backwards-compatibility
> >> mechanism that will enable to keep the same node type, while adding
> >> functionality. (maybe even modifying functionality, but that is more
> >> complex).
> >>
> >> In general, I agree that the 1.0 spec is not clear about using this
> version
> >> field, but the fact that version is consistently mentioned as a field in
> >> all the types, allows imo for a possible use of it within ARIA. There is
> >> not such a usage example of the version field in the 1.0 spec, I agree.
> >>
> >> On Tue, Aug 8, 2017 at 8:40 PM, Tal Liron <t...@cloudify.co> wrote:
> >>
> >>> The process is simply to open a JIRA ticket. However, it may be better
> to
> >>> first discuss it on this mailing list.
> >>>
> >>> For this enhancement, I think it's important to spec out how such a
> tool
> >>> would look. Let's say the inputs are two templates. What would be the
> >>> output?
> >>>
> >>> At least for TOSCA 1.0, I think this type version feature might be of
> >> more
> >>> use for "meta" tools that might be built on top of ARIA and allow some
> >> kind
> >>> of search or analysis. For example, a tool to rummage through a huge
> >>> directory of templates (or CSAR files) and do a search for node
> templates
> >>> or types that inherit from a specific base type and have a version of X
> >> or
> >>> X or similar. I don't know if such tools should be included in
> >> ARIA
> >>> proper, but they can definitely make use of ARIA as an SDK.
> >>>
> >>> On Tue, Aug 8, 2017 at 11:02 AM, Steve Baillargeon <
> >>> steve.baillarg...@ericsson.com> wrote:
> >>>
> >>>> 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 b

Re: Service Composition / Substitution Mapping

[Avia Efrat]

; > > 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 nice user would like to
> > instantiate
> > > > > them
> > > > > > > first? This seems very reasonable to me.
> > > > > > >
> > > > > > > 3. If indeed another service satisfies this, a special node
> > > > > > > is
> > > added
> > > > to
> > > > > > the
> > > > > > > current service (with the correct type -- but without a
> > > > > > > service
> > > > > template
> > > > > > > foreign key), which serves as a proxy of the other service
> > > template.
> > > > > I'm
> > > > > > > not sure how we would mark this exactly. We can't use the
> > > service_fk
> > > > > > field,
> > > > > > > because it's still in our current service. So perhaps
> > > > > > > there's
> > need
> > > > of a
> > > > > > new
> > > > > > > fk field, maybe substituted_service_fk?
> > > > > > >
> > > > > > > The above might be "sensible defaults," but it seems to me
> > > > > > > that
> > > users
> > > > > > > really need control over this. So I propose to add a new
> > > > > aria.Composition
> > > > > > > policy that would let you provide hints for this mechanism.
> > > > > > > For
> > > > > example,
> > > > > > > you might want to "filter" the target service by service
> > > > > > > template
> > > > name
> > > > > > and
> > > > > > > even by metadata in the service template. For example, you
> > > > > > > might
> > > want
> > > > > to
> > > > > > > require version 1.2.2 of a specific service, no less.
> > > > > > >
> > > > > > > Those are some quick thoughts. Exactly how such a policy
> > > > > > > would
> > look
> > > > > with
> > > > > > > require more thought...
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 1, 2017 at 2:20 PM, Avia Efrat
> > > > > > > <a...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > I'm starting to work on a full implementation of
> > > > > substitution_mapping,
> > > > > > > > which will lead to the ability of service composition.
> > > > > > > >
> > > > > > > > For those unacquainted with substitution mapping, here are
> > > > > > > > some
> > > > quick
> > > > > > > > resources:
> > > > > > > > *From the spec
> > > > > > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > > > > YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html>,
> > > > > > > > sections:*
> > > > > > > > 2.10
> > > > > > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > > > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_
> > > > Toc471725208>,
> > > > > > > > 2.11
> > > > > > > > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > > > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_
> > > Toc471725209>
> > > > > > > > (theory and examples)
> > > > > > > > 3.8.1, 3.8.2 (grammar)
> > > > > > > > *From Tal's amazing lecture on TOSCA
> > > > > > > > <https://www.youtube.com/watch?v=6xGmpi--7-A>:*
> > > > > > > > 00:00 until 12:30.
> > > > > > > >
> > > > > > > > If anyone wishes to:
> > > > > > > > * ask questions regarding this feature
> > > > > > > > * suggest real-life use cases
> > > > > > > > * offer their insight about vague parts of the spec
> > > > > > > > * anything else about substitution mapping and service
> > > composition
> > > > > > > > Then please, feel encouraged to leave your feedback!
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Version support for different TOSCA types

[Avia Efrat]

Actually, I can see the version field used as a backwards-compatibility
mechanism that will enable to keep the same node type, while adding
functionality. (maybe even modifying functionality, but that is more
complex).

In general, I agree that the 1.0 spec is not clear about using this version
field, but the fact that version is consistently mentioned as a field in
all the types, allows imo for a possible use of it within ARIA. There is
not such a usage example of the version field in the 1.0 spec, I agree.

On Tue, Aug 8, 2017 at 8:40 PM, Tal Liron  wrote:

> The process is simply to open a JIRA ticket. However, it may be better to
> first discuss it on this mailing list.
>
> For this enhancement, I think it's important to spec out how such a tool
> would look. Let's say the inputs are two templates. What would be the
> output?
>
> At least for TOSCA 1.0, I think this type version feature might be of more
> use for "meta" tools that might be built on top of ARIA and allow some kind
> of search or analysis. For example, a tool to rummage through a huge
> directory of templates (or CSAR files) and do a search for node templates
> or types that inherit from a specific base type and have a version of X or
> X or similar. I don't know if such tools should be included in ARIA
> proper, but they can definitely make use of ARIA as an SDK.
>
> On Tue, Aug 8, 2017 at 11:02 AM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > 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 <
> > d.jayachand...@ericsson.com>
> > 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: 

Re: pip executable expected as part of plugin install.

[Avia Efrat]

Hi DJ,
It seems you are correct, I don't see a reason for not using the pip
library.
Maybe it was that way since we didn't want to add pip as a dependency
explicitly (this code is from the beginning of ARIA).

Feel free to open an issue about that =)

On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran  wrote:

> Hi,
>
> Am using a Ubuntu version of linux for my development and ARIA does not
> find the correct path of pip during the plugin install.
> To be precise this happens when pip freeze is executed.
>
> @staticmethod
> def _pip_freeze():
> """Run pip freeze in current environment and return the output"""
> bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> pip_path = os.path.join(sys.prefix, bin_dir,
> 'pip{0}'.format('.exe' if os.name == 'nt'
> else ''))
> pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> stdout=subprocess.PIPE)
> pip_freeze_output, _ = pip_freeze.communicate()
> assert not pip_freeze.poll()
> return pip_freeze_output
>
> Now the question is why are we executing a pip command directly and not
> using pip as a library.
>
>
> Regards,
> DJ
>

Service Composition / Substitution Mapping

[Avia Efrat]

Hello all,

I'm starting to work on a full implementation of substitution_mapping,
which will lead to the ability of service composition.

For those unacquainted with substitution mapping, here are some quick
resources:
*From the spec
,
sections:*
2.10
,
2.11

(theory and examples)
3.8.1, 3.8.2 (grammar)
*From Tal's amazing lecture on TOSCA
:*
00:00 until 12:30.

If anyone wishes to:
* ask questions regarding this feature
* suggest real-life use cases
* offer their insight about vague parts of the spec
* anything else about substitution mapping and service composition
Then please, feel encouraged to leave your feedback!

Re: Aria Backlog

[Avia Efrat]

In the view you linked to, the issues are listed in a numerical order (only
issues that are not resolved/closed are shown there).
You can see their priority by the small icon to the right of the issue name.

Personally, I don't use this view. I use:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARIA%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)

There, you can easily sort and search the issues.

On Tue, Aug 1, 2017 at 9:33 PM, Thomas Nadeau 
wrote:

>
> Forgive me for asking a dumb question here, but is the backlog as
> listed here groomed?
> That is, are the stories/epics listed in priority order or just
> numerically?
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=150=ARIA=planning.nodetail <
> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=150=ARIA=planning.nodetail>
>
> —Tom
>
>

Re: Query on operation inputs

[Avia Efrat]

Quick update on this issue:
We merged the relevant pull request:
https://github.com/apache/incubator-ariatosca/pull/187
Now inputs behave as expected.


On Tue, Jul 11, 2017 at 5:39 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Avia,
>
> Thanks for the detailed explanation. Finally we have better clarity and
> are in the same page.
>
> Regards,
> DJ
>
> -----Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Tuesday, July 11, 2017 3:42 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> Here is the Jira issue:
> https://issues.apache.org/jira/browse/ARIA-313
>
> On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Avia, could you please create a JIRA issue for this?
> >
> >
> > On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:
> >
> > > Hello DJ,
> > >
> > > I ran the example you provided: https://github.com/djay8887/Ar
> > > ia-operationInputs [It should be noted that you can't just parse the
> > > service template kubernetes-deployment.yaml as is. I needed to
> > > create a folder named type and place kubernetes_type.yaml in there,
> > > as the import: section in your service templates contains `-
> > > *types*/kubernetes_type.yaml`]
> > >
> > > *Short answer:*
> > > You are correct, the example should pass, and we will change the
> > > code accordingly.
> > >
> > > *Longer answer + explanations:*
> > > I will separate my answer into three parts. I will repeat some of
> > > what
> > was
> > > said before me, but I think it will help clear the situation.
> > > 1. The result of my run.
> > > 2. Why do we currently get this error.
> > > 3. Our revised understanding of the TOSCA spec regarding the
> > > required
> > field
> > > of node type operation inputs.
> > >
> > > *1.* *The result of my run:*
> > > The commands I ran were:
> > > aria plugins install sample-1.0.0-py27-none-any.wgn aria
> > > service-templates store kubernetes-deployment.yaml dj aria services
> > > create -t dj dj aria executions start -s dj install after running
> > > the last command I got:
> > > Declared parameters "labels" have not been provided values
> > >
> > > *2.* *Why do we currently get this error:* First, let my just
> > > clarify, that this error has no relation whatsoever to the contents
> > > of the inputs section under topology_template.
> > > We are dealing here only with the inputs section of an operation,
> > > which
> > is
> > > section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> > > Currently, when we execute a workflow (aria executions start ...),
> > > we
> > check
> > > the inputs of each operation in the following manner (ignoring
> > > interface inputs for now):
> > > we check that every input defined in the input section of the node
> > template
> > > operation, whether the input is required or not has a value, has a
> value.
> > > This check is done in the merge_parameters_value function, inside
> > > aria/modelling/utils, so you can check the logic yourself.
> > >
> > > Anyway, these values can be supplied directly from the service
> > > template,
> > or
> > > in an indirect way via execution inputs, or programmatically when
> > creating
> > > workflow tasks. The latter method shouldn't concern us now, as we
> > > are dealing with the operation inputs that were provided in the
> > > inputs
> > section
> > > of the operation.
> > >
> > > So, in conclusion, we get this error since the labels input is not
> > assigned
> > > a value in the inputs section of the operation inside the node
> template.
> > > This happens even if the input is defined as required: false in the
> > inputs
> > > section of the operation inside the node *type*.
> > >
> > > *3. **Our revised understanding of the TOSCA spec regarding the
> > > required field operation definition inputs:* After rechecking the
> > > spec, we feel that an operation input that has
> > > required:
> > > false  indeed allows it not to be defined in the corresponding
> > > operation
> > in
> > > the service template. We base this on section 3.5.13.1 Operation
> > Definition
> > > keyname <https://goo.gl/g5bMtV>. This section clear

Re: Unique identification of an instance element across services

[Avia Efrat]

First, good arguments from both 'sides'.

I am for at least adding a uuid as an option, as ARIA is intended to be
used at scale as well.
But currently, I am for the simple ids to be used as default (and not
uuids). Like it or not, right now ARIA is more at a 'TOSCA playground'
stage, and I think that's perfectly fine =)
And at this stage, I think simple ids will be better, as they easier to use
via the CLI, but more importantly, don't clog the logs with long
meaningless strings. As ARIA matures, we could switch the default to UUIDs.

And BTW, as our log format is configurable, there could be other ways than
UUIDs to distinguish between nodes with the 'same id' in a central logging
system, e.g using the user name as another indicator.

On Thu, Jul 27, 2017 at 10:20 AM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> Thanks for the active discussion.
>
>
> Having UUID at the node instance level will just make the nodes unique.
>
> And these names will not be used by the user directly as no operations are
> happening on the node instance name.
>
> But at the service template and the service level, UUID will be of great
> help considering the multi user and multi tenancy situations.
>
>
> So in a large scale perspective, the node names and the service template
> names have high probability of being same.
>
> When these enter into the automated world, it will create more problem
> when name conflicts occur and its adds overhead to make changes every time
> to overcome the conflict.
>
>
> UUID at service template and the service level: will be of much use in the
> above scenario and operations by user on these are less
>
> UUID at node instance level: makes the node much unique and no operation
> happens on it
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron 
> Sent: Wednesday, July 26, 2017 8:48:40 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Unique identification of an instance element across services
>
> I just don't see users having to deal much with node IDs outside of simple
> hello-world style tutorials, and I'd hate for the first impressions that
> users get out of ARIA is that it's just a playground for TOSCA. It should
> be ready out-of-the-box for the real world.
>
> On Wed, Jul 26, 2017 at 9:13 AM, DeWayne Filppi 
> wrote:
>
> > Such is their strength.  I'm just advocating using them as a last resort
> > because they are user unfriendly and gigantic.
> >
> > On Tue, Jul 25, 2017 at 12:55 PM, Tal Liron  wrote:
> >
> > > Let's consider a mass deployment: thousands of service instances of the
> > > same service template, created by many different users with their own
> > ARIA
> > > installations (and databases). In that case, assuming we use sequential
> > > IDs, you would have the same node ID appear many times. You would have
> to
> > > identify it via the particular user and service instance. If you're
> > > centralizing logs, this can quickly be cumbersome. A UUID will identify
> > it
> > > globally and avoid any confusion.
> > >
> > > I think the default should be something that avoids such problems. For
> > > users who insist on shorter IDs, we can allow them to configure it.
> > >
> > > On Tue, Jul 25, 2017 at 2:42 PM, DeWayne Filppi 
> > > wrote:
> > >
> > > > True uuids are seductive, because of their simplicity.  But they are
> > > huge,
> > > > overkill, and meaningless.  Imho a structured id is superior if it
> can
> > be
> > > > made to work without a global locking scheme.
> > > >
> > > > - DeWayne
> > > >
> > > > On Jul 25, 2017 12:11 PM, "Tal Liron"  wrote:
> > > >
> > > > > It's not an issue of thread safety -- it could be entirely
> different
> > > > > processes, on different machines, accessing the same db. It can be
> > > solved
> > > > > via a SQL transaction, but I feel the whole issue can be avoided by
> > > using
> > > > > UUIDs.
> > > > >
> > > > > Using the CLI to access specific nodes is not something I see
> > > happening a
> > > > > lot outside of debugging. And when you do debug, you'll probably be
> > > > copying
> > > > > and pasting a node ID from the logs, so shorter names do not add
> much
> > > > ease
> > > > > of use.
> > > > >
> > > > > Again, I would be personally happiest if this was configurable (and
> > > > > personally think UUIDs should be the reasonable default).
> > > > >
> > > > > On Tue, Jul 25, 2017 at 2:01 PM, Maxim Orlov 
> > > wrote:
> > > > >
> > > > > > Technically we have no issue with implementing this via uuid or a
> > > > > > threadsafe solution for the current index implementation.
> > > > > >
> > > > > > Getting node data via the cli feels more intuitive using the
> index
> > > > based
> > > > > > ID, rather than the uuid based ID in my opionion.
> > > > > >
> > > > > > On Jul 25, 2017 9:49 PM, "Tal Liron"  wrote:
> > > > > >
> > > > > > Our code for 

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

[Avia Efrat]

Seeing that the overall reaction was good, I created a Jira issue:
https://issues.apache.org/jira/browse/ARIA-316

On Mon, Jul 10, 2017 at 4:13 PM, Avia Efrat <a...@gigaspaces.com> wrote:

> These presentationa are not stand-alone, as they consist of bulletins that
> were more broadly explained in the session. That being said, there is an 4
> hour video and Q session by Tal about TOSCA. We intend to upload it to
> the ARIA site soon.
> In addition, we are planning to expand our documentation, specifically
> about such concepts as custom workflows and plugins.
>
> On Mon, Jul 10, 2017 at 3:58 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
>> 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 <johndam...@apache.org>
>> 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 <a...@gigaspaces.com> 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
>> > > >
>> > >
>> > > <https://twitter.com/CloudifySource>
>> > > <https://www.linkedin.com/groups/8467478>
>> > > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-
>> cosmo
>> > >
>> > > [image: Azure Webinar]
>> > > <
>> > > http://getcloudify.org/webinars/Azure-plugin-for-
>> > cloudify-webinar.html?utm_source=signaturesatori_
>> > medium=email_campaign=general_signature
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Avia Efrat
> SW Engineer
> a...@gigaspaces.com | +972546204553
> Cloudify | http://getcloudify.org
> <http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>
>
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/groups/8467478>
> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
> [image: Azure Webinar]
> <http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>
>
>

Re: Query on operation inputs

[Avia Efrat]

Here is the Jira issue:
https://issues.apache.org/jira/browse/ARIA-313

On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Avia, could you please create a JIRA issue for this?
>
>
> On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:
>
> > Hello DJ,
> >
> > I ran the example you provided: https://github.com/djay8887/Ar
> > ia-operationInputs
> > [It should be noted that you can't just parse the service template
> > kubernetes-deployment.yaml as is. I needed to create a folder named type
> > and place kubernetes_type.yaml in there, as the import: section in your
> > service templates contains `- *types*/kubernetes_type.yaml`]
> >
> > *Short answer:*
> > You are correct, the example should pass, and we will change the code
> > accordingly.
> >
> > *Longer answer + explanations:*
> > I will separate my answer into three parts. I will repeat some of what
> was
> > said before me, but I think it will help clear the situation.
> > 1. The result of my run.
> > 2. Why do we currently get this error.
> > 3. Our revised understanding of the TOSCA spec regarding the required
> field
> > of node type operation inputs.
> >
> > *1.* *The result of my run:*
> > The commands I ran were:
> > aria plugins install sample-1.0.0-py27-none-any.wgn
> > aria service-templates store kubernetes-deployment.yaml dj
> > aria services create -t dj dj
> > aria executions start -s dj install
> > after running the last command I got:
> > Declared parameters "labels" have not been provided values
> >
> > *2.* *Why do we currently get this error:*
> > First, let my just clarify, that this error has no relation whatsoever to
> > the contents of the inputs section under topology_template.
> > We are dealing here only with the inputs section of an operation, which
> is
> > section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> > Currently, when we execute a workflow (aria executions start ...), we
> check
> > the inputs of each operation in the following manner (ignoring interface
> > inputs for now):
> > we check that every input defined in the input section of the node
> template
> > operation, whether the input is required or not has a value, has a value.
> > This check is done in the merge_parameters_value function, inside
> > aria/modelling/utils, so you can check the logic yourself.
> >
> > Anyway, these values can be supplied directly from the service template,
> or
> > in an indirect way via execution inputs, or programmatically when
> creating
> > workflow tasks. The latter method shouldn't concern us now, as we are
> > dealing with the operation inputs that were provided in the inputs
> section
> > of the operation.
> >
> > So, in conclusion, we get this error since the labels input is not
> assigned
> > a value in the inputs section of the operation inside the node template.
> > This happens even if the input is defined as required: false in the
> inputs
> > section of the operation inside the node *type*.
> >
> > *3. **Our revised understanding of the TOSCA spec regarding the required
> > field operation definition inputs:*
> > After rechecking the spec, we feel that an operation input that has
> > required:
> > false  indeed allows it not to be defined in the corresponding operation
> in
> > the service template. We base this on section 3.5.13.1 Operation
> Definition
> > keyname <https://goo.gl/g5bMtV>. This section clearly state the node
> type
> > operation inputs are of type property definitions (3.5.8)
> > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#
> > DEFN_ELEMENT_PROPERTY_DEFN>
> > .
> >
> > Therefore, the required field of a node type operation input is the same
> as
> > the required field in a node type property.
> >
> > So, just as you can omit in a node template property that has required:
> > false in its corresponding node type property, you can omit a node
> template
> > operation input that has required: false in its corresponding node type
> > operation input.
> >
> >
> >
> >
> > On Mon, Jul 3, 2017 at 10:17 PM, Tal Liron <t...@gigaspaces.com> wrote:
> >
> > > Oops, it seems your email from before was somehow tagged as read by
> > > mistake, so I missed it. I will get to it after the US holiday!
> > >
> > > On Mon, Jul 3, 2017 at 4:21 AM, D Jayachandran <
> > >

Re: Query on operation inputs

[Avia Efrat]

; > > (true or
> > > > > > > > > false) indicating whether or not the property is required.
> > > > > > > > > If this keyname is not present on a property definition,
> > > > > > > > > then the property SHALL be considered required (i.e., true)
> > by default.
> > > > > > > > >
> > > > > > > > > It is not clear to whom this property is required or not ?
> > > > > > > > >
> > > > > > > > > With your argument, it seems we always need to provide a
> > > > > > > > > default value to an input, when we don’t declare in my
> > > > > > > > > service
> > > > template.
> > > > > > > > > Is my understanding correct here ?
> > > > > > > > > But the TOSCA spec says the default value is always an
> > > > > > > > > optional
> > > > > one.
> > > > > > > > > Also since the parser validates the service template
> > > > > > > > > inputs according to the "required" field am not sure why
> > > > > > > > > we need another validation during the execution ?
> > > > > > > > >
> > > > > > > > > I also don’t find any reference in TOSCA spec which says,
> > > > > > > > > all inputs defined in node type be declared in node
> > > > > > > > > template to be used by any operation. Could you please
> > > > > > > > > help me with that reference
> > > > > > in TOSCA spec ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > DJ
> > > > > > > > >
> > > > > > > > > -Original Message-
> > > > > > > > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > > > > > > > Sent: Thursday, May 25, 2017 5:16 PM
> > > > > > > > > To: dev@ariatosca.incubator.apache.org
> > > > > > > > > Subject: Re: Query on operation inputs
> > > > > > > > >
> > > > > > > > > Yes, I understand the confusion here. The issue is that,
> > > > > > > > > despite its name, the "required" field isn't what defines
> > > > > > > > > whether an input is optional or not
> > > > > > > > > - it is only relevant during the parsing phase (This is
> > > > > > > > > according to our understanding of the TOSCA spec. Tal
> > > > > > > > > could probably expand more on
> > > > > > > > this).
> > > > > > > > > What's relevant for deciding whether an input is required
> > > > > > > > > or not for actual execution is whether it has a default
> > > > > > > > > value - so all inputs would have a value when the actual
> > > > > > > > > execution
> > > takes
> > > > place.
> > > > > > > > >
> > > > > > > > > I hope this helps clearing this confusing issue..
> > > > > > > > >
> > > > > > > > > Ran
> > > > > > > > >
> > > > > > > > > On Thu, May 25, 2017 at 2:08 PM, D Jayachandran <
> > > > > > > > > d.jayachand...@ericsson.com
> > > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Ran,
> > > > > > > > > >
> > > > > > > > > > Thanks for your response.
> > > > > > > > > >
> > > > > > > > > > In my case, I have defined the inputs as optional under
> > > > > > > > > > the create operation of my custom node type.
> > > > > > > > > > Since it is an optional input, I haven't declared it in
> > > > > > > > > > my
> > > > > > > > node-template.
> > > > > > > > > > I assume optional input may or may not be declared in a
> > > > > > > > > > service template
> > > > > > > > > ?
> > > > > > > > > > Am I missing something here ?
> > > > > > > > > >
> > > > > > > > > > Please find below the node type and node template in my
> > case.
> > > > > > > > > >
> > > > > > > > > > # python /root/incubator-ariatosca/aria/cli/main.py
> > > > > > > > > > executions start -s
> > > > > > > > > > demo-sr-1 install
> > > > > > > > > > Required inputs [u'labels'] have not been specified -
> > > > > > > > > > expected
> > > > > > > inputs:
> > > > > > > > > > [u'isService', u'name', u'exposed_port', u'image',
> > > > > > > > > > u'labels', u'target_port', u'target_host']
> > > > > > > > > >
> > > > > > > > > > Node-type
> > > > > > > > > >
> > > > > > > > > > node_types:
> > > > > > > > > > test.nodes.Container.Application:
> > > > > > > > > > derived_from: tosca.nodes.Root
> > > > > > > > > > properties:
> > > > > > > > > > name:
> > > > > > > > > >   type: string
> > > > > > > > > >   required: true
> > > > > > > > > > image:
> > > > > > > > > >   type: string
> > > > > > > > > >   required: true
> > > > > > > > > > port:
> > > > > > > > > >   type: integer
> > > > > > > > > >   required: false
> > > > > > > > > > interfaces:
> > > > > > > > > > Standard:
> > > > > > > > > > type: tosca.interfaces.node.
> > > lifecycle.Standard
> > > > > > > > > > create:
> > > > > > > > > > inputs:
> > > > > > > > > > name:
> > > > > > > > > > type: string
> > > > > > > > > > required: true
> > > > > > > > > > image:
> > > > > > > > > > type: string
> > > > > > > > > > required: true
> > > > > > > > > > exposed_port:
> > > > > > > > > > type: integer
> > > > > > > > > > required: false
> > > > > > > > > > target_port:
> > > > > > > > > > type: integer
> > > > > > > > > > required: false
> > > > > > > > > > target_host:
> > > > > > > > > > type: integer
> > > > > > > > > > required: false
> > > > > > > > > > labels:
> > > > > > > > > > type: string
> > > > > > > > > > required: false
> > > > > > > > > > isService:
> > > > > > > > > > type: boolean
> > > > > > > > > > required: false
> > > > > > > > > > implementation:
> > > > > > > > > > primary: sample >
> > > > > > > > > > sample.samplemethod
> > > > > > > > > >
> > > > > > > > > > Node template:
> > > > > > > > > >
> > > > > > > > > > web_app:
> > > > > > > > > > type: test.nodes.Container.Application
> > > > > > > > > > properties:
> > > > > > > > > > name: { get_input: web_app_name }
> > > > > > > > > > image: { get_input: web_app_image }
> > > > > > > > > > port: { get_input: web_app_port }
> > > > > > > > > > requirements:
> > > > > > > > > > - dependency:
> > > > > > > > > >   node: database
> > > > > > > > > >   relationship:
> > > > > > > > > >   type:
> > tosca.relationships.DependsOn
> > > > > > > > > > interfaces:
> > > > > > > > > > Standard:
> > > > > > > > > >  create:
> > > > > > > > > > inputs:
> > > > > > > > > > name: { get_input:
> > web_app_name }
> > > > > > > > > > image: { get_property: [
> > > > > > > > > > web_app, image]
> > > > > > > }
> > > > > > > > > > exposed_port: {
> > > > > > > > > > get_property: [ web_app, port] }
> > > > > > > > > > target_host: { get_property:
> > > > > > > > > > [ database, name] }
> > > > > > > > > > target_port: { get_property:
> > > > > > > > > > [ database, port] }
> > > > > > > > > > isService: true
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > DJ
> > > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > > > > > > > > Sent: Thursday, May 25, 2017 4:07 PM
> > > > > > > > > > To: dev@ariatosca.incubator.apache.org
> > > > > > > > > > Subject: Re: Query on operation inputs
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > Weird, I remember responding to this mail before, but it
> > > > > > > > > > doesn't seem like I have.
> > > > > > > > > > In any case, it is indeed our intention that no inputs
> > > > > > > > > > may be passed into operations unless they have been
> > > > > > > > > > clearly declared in the
> > > > > > > > > service-template.
> > > > > > > > > > ARIA opts to be a strict implementation of TOSCA
> > > > > > > > > > wherever
> > > > > possible.
> > > > > > > > > >
> > > > > > > > > > Ran
> > > > > > > > > >
> > > > > > > > > > On Thu, May 25, 2017 at 1:22 PM, D Jayachandran <
> > > > > > > > > > d.jayachand...@ericsson.com
> > > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > The latest Apache-aria is throwing a validation error
> > > > > > > > > > > during the execution of a service.
> > > > > > > > > > > It demands all the operation inputs defined in a node
> > > > > > > > > > > type be declared in the service template though they
> > > > > > > > > > > are optional
> > > > > inputs.
> > > > > > > > > > > Could you please let us know if this change was
> > > intentional ?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > DJ(D Jayachandran)
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tal Liron
> > > > > > > > Senior Engineer
> > > > > > > > t...@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> > > > > > > > http://getcloudify.org
> > > > > > > > <http://getcloudify.org?utm_source=signaturesatori_
> > > > > > > > medium=email_campaign=general_signature>
> > > > > > > >
> > > > > > > > <https://twitter.com/CloudifySource>
> > > > > > > > <https://www.linkedin.com/groups/8467478>
> > > > > > > > <https://github.com/cloudify-cosmo>   <
> > > > https://github.com/cloudify-
> > > > > > cosmo
> > > > > > > >
> > > > > > > > [image: Azure Webinar]
> > > > > > > > <http://getcloudify.org/webinars/Azure-plugin-for-
> > > > > > > > cloudify-webinar.html?utm_source=signaturesatori_
> > > > > > > > medium=email_campaign=general_signature>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Tal Liron
> > > > > > > Senior Engineer
> > > > > > > t...@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> > > > > > > http://getcloudify.org
> > > > > > > <http://getcloudify.org?utm_source=signaturesatori_
> > > > > > > medium=email_campaign=general_signature>
> > > > > > >
> > > > > > > <https://twitter.com/CloudifySource>
> > > > > > > <https://www.linkedin.com/groups/8467478>
> > > > > > > <https://github.com/cloudify-cosmo>   <
> > > https://github.com/cloudify-
> > > > > cosmo
> > > > > > >
> > > > > > > [image: Azure Webinar]
> > > > > > > <http://getcloudify.org/webinars/Azure-plugin-for-
> > > > > > > cloudify-webinar.html?utm_source=signaturesatori_
> > > > > > > medium=email_campaign=general_signature>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Tal Liron
> > Senior Engineer
> > t...@gigaspaces.com | +1 (773) 828-9339
> > Cloudify | http://getcloudify.org
> > <http://getcloudify.org?utm_source=signaturesatori_
> > medium=email_campaign=general_signature>
> >
> > <https://twitter.com/CloudifySource>
> > <https://www.linkedin.com/groups/8467478>
> > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo
> >
> > [image: Azure Webinar]
> > <http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature>
> >
>
>
>
> --
> Tal Liron, Senior Solutions Architect <http://cloudify.co>
> --
> M: +1-312-375-8299 http://cloudify.co @cloudifysource
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/company-beta/17918192/>
> <https://github.com/cloudify-cosmo>
> <https://www.youtube.com/cloudifysource>
>



-- 
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

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

[Avia Efrat]

These presentationa are not stand-alone, as they consist of bulletins that
were more broadly explained in the session. That being said, there is an 4
hour video and Q session by Tal about TOSCA. We intend to upload it to
the ARIA site soon.
In addition, we are planning to expand our documentation, specifically
about such concepts as custom workflows and plugins.

On Mon, Jul 10, 2017 at 3:58 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> 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 <johndam...@apache.org>
> 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 <a...@gigaspaces.com> 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
> > > >
> > >
> > > <https://twitter.com/CloudifySource>
> > > <https://www.linkedin.com/groups/8467478>
> > > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-
> cosmo
> > >
> > > [image: Azure Webinar]
> > > <
> > > http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> >
>



-- 
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

Re: [VOTE] publish ariatosca 0.1.0 (#2)

[Avia Efrat]

gt; > > The file is signed (.asc) and its MD5 / SHA512 checksums may be
> found
> > > in
> > > > > that folder as well.
> > > > >
> > > > >
> > > > > In addition, I've created packages for (Pythonic-)source & binary
> > > > > distributions, which would be uploaded to PyPI if the release is
> > > > approved.
> > > > > These artifacts may be found here:
> > > > > Source distribution:
> > > > >
> > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-sdist/
> > > > > Binary distribution:
> > > > >
> > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-bdist/
> > > > >
> > > > >
> > > > >
> > > > > The list of issues Resolved for this release are simply all the
> > issues
> > > > that
> > > > > have been resolved thus far, seeing as this would be the first
> > release
> > > :)
> > > > > Those can be found here:
> > > > > https://issues.apache.org/jira/browse/ARIA-295?filter=-1;
> > > > > jql=project%3Dariatosca%20and%20status%20in%20(resolved%2C%
> 20closed)
> > > > >
> > > > >
> > > > > Instructions for installation etc. may be found in the README file
> > > inside
> > > > > the tarball.
> > > > > (Please note that the relevant installation instructions are for
> > > "source
> > > > > installation", not "install from PyPI")
> > > > >
> > > > >
> > > > > To use RAT to validate package conformance with ASF standards,
> please
> > > use
> > > > > the ".rat-excludes" file, for example:
> > > > > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E
> .rat-excludes
> > > > >
> > > > >
> > > > >
> > > > > The vote will last 72 hours.
> > > > >
> > > > > Please vote:
> > > > >
> > > > > [ ] +1: Good to go!
> > > > > [ ] 0: I don't care
> > > > > [ ] -1: Don't release this because...
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Ran
> > > > >
> > > >
> > >
> >
>



-- 
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

Re: Support for TOSCA Simple Profile NFV 1.0

[Avia Efrat]

Hi DJ,

Just updating that the pull request was merged.

Note that there are some inconsistencies in csd04, so if you have any
questions regarding our reasoning in resolving them, feel encouraged to ask.

On Wed, Jun 7, 2017 at 10:09 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Thanks for the update Avia.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Wednesday, June 07, 2017 3:03 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for TOSCA Simple Profile NFV 1.0
>
> Hi DJ,
>
> I've created a pull request for the issue that Tal opened:
> https://github.com/apache/incubator-ariatosca/pull/147
> I expect it to be merged on Thursday/Friday.
>
> On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > Thanks DJ, I opened a new JIRA issue for this if you want to track it:
> >
> > https://issues.apache.org/jira/browse/ARIA-275
> >
> > It shouldn't be too hard to do, just some busy work in YAML. Anyone on
> > the mailing list want to tackle this?
> >
> > On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran <
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft 03.
> > > The Latest available TOSCA NFV profile is Simple profile NFV 1.0
> > > draft
> > 04,
> > > released on 11 May 2017.
> > >
> > > Could you kindly confirm the current level of support from ARIA for
> > > NFV profiles and do you have any timelines to support draft 04 ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
> >
> >
> > --
> > Tal Liron
> > Senior Engineer
> > t...@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> > http://getcloudify.org
> > <http://getcloudify.org?utm_source=signaturesatori_
> > medium=email_campaign=general_signature>
> >
> > <https://twitter.com/CloudifySource>
> > <https://www.linkedin.com/groups/8467478>
> > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo
> >
> > [image: Azure Webinar]
> > <http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature>
> >
>
>
>
> --
> Avia Efrat
> SW Engineer
> a...@gigaspaces.com | +972546204553
> Cloudify | http://getcloudify.org
> <http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/groups/8467478>
> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
> [image: Azure Webinar]
> <http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>



-- 
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

Re: Support for TOSCA Simple Profile NFV 1.0

[Avia Efrat]

Hi DJ,

I've created a pull request for the issue that Tal opened:
https://github.com/apache/incubator-ariatosca/pull/147
I expect it to be merged on Thursday/Friday.

On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron <t...@gigaspaces.com> wrote:

> Thanks DJ, I opened a new JIRA issue for this if you want to track it:
>
> https://issues.apache.org/jira/browse/ARIA-275
>
> It shouldn't be too hard to do, just some busy work in YAML. Anyone on the
> mailing list want to tackle this?
>
> On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi,
> >
> > I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft 03.
> > The Latest available TOSCA NFV profile is Simple profile NFV 1.0 draft
> 04,
> > released on 11 May 2017.
> >
> > Could you kindly confirm the current level of support from ARIA for NFV
> > profiles and do you have any timelines to support draft 04 ?
> >
> >
> > Regards,
> > DJ
> >
>
>
>
> --
> Tal Liron
> Senior Engineer
> t...@gigaspaces.com | +1 (773) 828-9339
> Cloudify | http://getcloudify.org
> <http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/groups/8467478>
> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
> [image: Azure Webinar]
> <http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>



-- 
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

[jira] [Assigned] (ARIA-180) Convert many-to-many for parameter models to one-to-many

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat reassigned ARIA-180:
---

Assignee: Avia Efrat

> Convert many-to-many for parameter models to one-to-many
> 
>
> Key: ARIA-180
> URL: https://issues.apache.org/jira/browse/ARIA-180
> Project: AriaTosca
>  Issue Type: Task
>Reporter: Tal Liron
>    Assignee: Avia Efrat
>Priority: Minor
>
> We must first discuss this as a team to see if we agree that this is the best 
> solution. (There was an early discussion between Tal and Maxim.)
> First let's point out that one-to-many is a special case of many-to-many, so 
> that everything works fine now and continue to work fine.
> However, logically our code right now treats them as one-to-many: there is no 
> case in which a {{Parameter}} model belongs to more than one model. 
> Parameters are always copied to the new model, for example during 
> instantiation, or during task creation.
> There are cons to using many-to-many in our case:
> * We generate lots of extra secondary tables, one for each potential 
> relationship
> * Crawling back from a {{Parameter}} to its containing model is quite costly, 
> as it involves a new SQL query to check for each possible relationship
> * Logical confusion: if we do not write our code to support one parameter 
> belonging to one model, and yet a user can create such a relationship, what 
> would happen?
> * Slower
> The one advantage of many-to-many is that we *could* potentially optimize in 
> some cases where the parameter has an identical value and we know would never 
> change, and thus could safely link it multiple times instead of copying it. 
> This optimization, however, requires us to be 100% sure that the parameter is 
> immutable: otherwise, if a user changes it (for example in a task) it would 
> change for all other containers. The questions are: 1) are we ever sure of 
> immutability? and 2) is this optimization worth the effort of implementing 
> it? The optimization would only seem to save some disk space.
> Another advantage is that it's much easier to add new models that use 
> {{Parameter}} by adding an extra table (many-to-many) rather than adding fk 
> columns to an existing table. To that there is a simple answer: new models 
> can definitely create many-to-many relationships to anything else. Using 
> one-to-many for our own models doesn't preclude that. (And we can even add 
> code that automatically tries to look through such many-to-many relationships 
> in order to find a container.)
> If we decide to switch to one-to-many, we have two approached:
> * Straightforward: one foreign key in {{Parameter}} per each possible 
> containing relationship. Pros: naturally supported in SQL, cons: we will have 
> lots of fk columns per row in the {{Parameter}} table, whereby only one will 
> be non-null.
> * Polymorphic one-to-many (type-and-id joins): {{Parameter}} only has a 
> single general-purpose fk column and another column specifying the type of 
> the fk (node, interface, task, etc.). Cons: we would need to investigate how 
> to accomplish this in SQLAlchemy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARIA-250) Sporadic Appveyor failures even if all tests pass

[Avia Efrat (JIRA)]

Avia Efrat created ARIA-250:
---

 Summary: Sporadic Appveyor failures even if all tests pass
 Key: ARIA-250
 URL: https://issues.apache.org/jira/browse/ARIA-250
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Avia Efrat
Priority: Minor


Sometimes, even if all the tests pass, we still get a failure from Appveyor:
{{ERROR: InvocationError: 
'C:\\projects\\incubator-ariatosca\\.tox\\pywin\\Scripts\\pytest.EXE tests 
--ignore=tests/end2end --cov-report term-missing --cov aria'}}

For reference, see:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.1484
compared to:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.1485



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ARIA-157) CLI unit tests for storing service-templates fail on appveyor

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat resolved ARIA-157.
-
   Resolution: Fixed
Fix Version/s: 0.1.0

> CLI unit tests for storing service-templates fail on appveyor
> -
>
> Key: ARIA-157
> URL: https://issues.apache.org/jira/browse/ARIA-157
> Project: AriaTosca
>  Issue Type: Bug
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
> Fix For: 0.1.0
>
>
> The failing tests are:
> test_store_no_exception
> test_store_raises_exception_resulting_from_name_uniqueness
> test_store_raises_exception
> They pass on Travis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARIA-157) CLI unit tests for storing service-templates fail on appveyor

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat reassigned ARIA-157:
---

Assignee: Avia Efrat

> CLI unit tests for storing service-templates fail on appveyor
> -
>
> Key: ARIA-157
> URL: https://issues.apache.org/jira/browse/ARIA-157
> Project: AriaTosca
>  Issue Type: Bug
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>
> The failing tests are:
> test_store_no_exception
> test_store_raises_exception_resulting_from_name_uniqueness
> test_store_raises_exception
> They pass on Travis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ARIA-210) Relative paths may cause issues in `aria service-templates` commands

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat resolved ARIA-210.
-
   Resolution: Fixed
Fix Version/s: 0.1.0

> Relative paths may cause issues in `aria service-templates` commands
> 
>
> Key: ARIA-210
> URL: https://issues.apache.org/jira/browse/ARIA-210
> Project: AriaTosca
>  Issue Type: Bug
>Reporter: Ran Ziv
>    Assignee: Avia Efrat
> Fix For: 0.1.0
>
>
> The CLI commands {{aria service-templates store}} and {{aria 
> service-templates create-archive}} use the {{os.path.dirname}} method to get 
> the directory of the main service-template file.
> In the former ({{store}} command) this causes errors when the user is already 
> in the directory of the main service-template file and passes the file 
> directly (e.g. {{aria service-templates store service-template.yaml 
> my-service-template}})) - It'll fail when trying to copy the 
> service-template's resources like so:
> {{cannot copy tree '': not a directory}}
> In the latter ({{create-archive}}), any relative path usage will result in an 
> error claiming the file does not exist.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARIA-210) Relative paths may cause issues in `aria service-templates` commands

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat reassigned ARIA-210:
---

Assignee: Avia Efrat

> Relative paths may cause issues in `aria service-templates` commands
> 
>
> Key: ARIA-210
> URL: https://issues.apache.org/jira/browse/ARIA-210
> Project: AriaTosca
>  Issue Type: Bug
>Reporter: Ran Ziv
>    Assignee: Avia Efrat
>
> The CLI commands {{aria service-templates store}} and {{aria 
> service-templates create-archive}} use the {{os.path.dirname}} method to get 
> the directory of the main service-template file.
> In the former ({{store}} command) this causes errors when the user is already 
> in the directory of the main service-template file and passes the file 
> directly (e.g. {{aria service-templates store service-template.yaml 
> my-service-template}})) - It'll fail when trying to copy the 
> service-template's resources like so:
> {{cannot copy tree '': not a directory}}
> In the latter ({{create-archive}}), any relative path usage will result in an 
> error claiming the file does not exist.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARIA-156) Workflow runner continues to run when exception is raised on task_started event

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat reassigned ARIA-156:
---

Assignee: Avia Efrat

> Workflow runner continues to run when exception is raised on task_started 
> event
> ---
>
> Key: ARIA-156
> URL: https://issues.apache.org/jira/browse/ARIA-156
> Project: AriaTosca
>  Issue Type: Bug
>Affects Versions: 0.1.0
>    Reporter: Avia Efrat
>Assignee: Avia Efrat
>
> If an exception is raised during _task_started, the engine continues to run, 
> but it finds no executable tasks or ended tasks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARIA-157) CLI service-template store tests fail on appveyor

[Avia Efrat (JIRA)]

Avia Efrat created ARIA-157:
---

 Summary: CLI service-template store tests fail on appveyor
 Key: ARIA-157
 URL: https://issues.apache.org/jira/browse/ARIA-157
 Project: AriaTosca
  Issue Type: Bug
Reporter: Avia Efrat


The failing tests are:
test_store_no_exception
test_store_raises_exception_resulting_from_name_uniqueness
test_store_raises_exception

They pass on Travis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARIA-156) Workflow runner continues to run when exception is raised in _task_started

[Avia Efrat (JIRA)]

Avia Efrat created ARIA-156:
---

 Summary: Workflow runner continues to run when exception is raised 
in _task_started
 Key: ARIA-156
 URL: https://issues.apache.org/jira/browse/ARIA-156
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Avia Efrat


If an exception is raised during _task_started, the engine continues to run, 
but it finds no executable tasks or ended tasks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-143) Cancelling of workflow execution

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-143:

Description: 
Make the process of cancelling execution more robust:
- Identify possible pitfalls and corner cases.
- Implement force cancelling.

**
*Conclusions:*
Unhandled execution status transitions resulting from cancelling an
execution via the CLI, that we indentified and tried to address:

TERMINATED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already finished, and therefore, in
SUCCEEDED status.

FAILED -> CANCELLING
You cancel the execution, but by the time we try to set the status to
CANCELLING, the execution thread had already encountered an error, and 
therefore, in
FAILED state.

TERMINATED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.

FAILED -> CANCELLED
Similar to #1, but with CANCELLED instead of CANCELLING.

In all of the above cases (#1-#4), we skip updating the execution status,
and log that the execution already succeeded/failed before we were able
to cancel it.

CANCELLING -> STARTED
You cancel the execution while it is still in pending state. Meanwhile,
while the execution status was already set to CANCELLING, we try to set
the execution status

CANCELLED -> STARTED
Similar to #5, but after the status is set to CANCELLING, it also gets
set to CANCELLED before attempting to set it to STARTED.

In cases #5-#6, we skip updtating the execution status, and nothing is logged.

  was:
Make the process of cancelling execution more robust:
- Identify possible pitfalls and corner cases.
- Implement force cancelling.



> Cancelling of workflow execution
> 
>
> Key: ARIA-143
> URL: https://issues.apache.org/jira/browse/ARIA-143
> Project: AriaTosca
>  Issue Type: Story
>Affects Versions: 0.1.0
>    Reporter: Avia Efrat
>Assignee: Avia Efrat
>
> Make the process of cancelling execution more robust:
> - Identify possible pitfalls and corner cases.
> - Implement force cancelling.
> **
> *Conclusions:*
> Unhandled execution status transitions resulting from cancelling an
> execution via the CLI, that we indentified and tried to address:
> TERMINATED -> CANCELLING
> You cancel the execution, but by the time we try to set the status to
> CANCELLING, the execution thread had already finished, and therefore, in
> SUCCEEDED status.
> FAILED -> CANCELLING
> You cancel the execution, but by the time we try to set the status to
> CANCELLING, the execution thread had already encountered an error, and 
> therefore, in
> FAILED state.
> TERMINATED -> CANCELLED
> Similar to #1, but with CANCELLED instead of CANCELLING.
> FAILED -> CANCELLED
> Similar to #1, but with CANCELLED instead of CANCELLING.
> In all of the above cases (#1-#4), we skip updating the execution status,
> and log that the execution already succeeded/failed before we were able
> to cancel it.
> CANCELLING -> STARTED
> You cancel the execution while it is still in pending state. Meanwhile,
> while the execution status was already set to CANCELLING, we try to set
> the execution status
> CANCELLED -> STARTED
> Similar to #5, but after the status is set to CANCELLING, it also gets
> set to CANCELLED before attempting to set it to STARTED.
> In cases #5-#6, we skip updtating the execution status, and nothing is logged.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ARIA-143) Cancelling of workflow execution

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat resolved ARIA-143.
-
Resolution: Fixed

> Cancelling of workflow execution
> 
>
> Key: ARIA-143
> URL: https://issues.apache.org/jira/browse/ARIA-143
> Project: AriaTosca
>  Issue Type: Story
>Affects Versions: 0.1.0
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>
> Make the process of cancelling execution more robust:
> - Identify possible pitfalls and corner cases.
> - Implement force cancelling.
> **
> *Conclusions:*
> Unhandled execution status transitions resulting from cancelling an
> execution via the CLI, that we indentified and tried to address:
> TERMINATED -> CANCELLING
> You cancel the execution, but by the time we try to set the status to
> CANCELLING, the execution thread had already finished, and therefore, in
> SUCCEEDED status.
> FAILED -> CANCELLING
> You cancel the execution, but by the time we try to set the status to
> CANCELLING, the execution thread had already encountered an error, and 
> therefore, in
> FAILED state.
> TERMINATED -> CANCELLED
> Similar to #1, but with CANCELLED instead of CANCELLING.
> FAILED -> CANCELLED
> Similar to #1, but with CANCELLED instead of CANCELLING.
> In all of the above cases (#1-#4), we skip updating the execution status,
> and log that the execution already succeeded/failed before we were able
> to cancel it.
> CANCELLING -> STARTED
> You cancel the execution while it is still in pending state. Meanwhile,
> while the execution status was already set to CANCELLING, we try to set
> the execution status
> CANCELLED -> STARTED
> Similar to #5, but after the status is set to CANCELLING, it also gets
> set to CANCELLED before attempting to set it to STARTED.
> In cases #5-#6, we skip updtating the execution status, and nothing is logged.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARIA-143) Cancelling of workflow execution

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat closed ARIA-143.
---

> Cancelling of workflow execution
> 
>
> Key: ARIA-143
> URL: https://issues.apache.org/jira/browse/ARIA-143
> Project: AriaTosca
>  Issue Type: Story
>Affects Versions: 0.1.0
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>
> Make the process of cancelling execution more robust:
> - Identify possible pitfalls and corner cases.
> - Implement force cancelling.
> **
> *Conclusions:*
> Unhandled execution status transitions resulting from cancelling an
> execution via the CLI, that we indentified and tried to address:
> TERMINATED -> CANCELLING
> You cancel the execution, but by the time we try to set the status to
> CANCELLING, the execution thread had already finished, and therefore, in
> SUCCEEDED status.
> FAILED -> CANCELLING
> You cancel the execution, but by the time we try to set the status to
> CANCELLING, the execution thread had already encountered an error, and 
> therefore, in
> FAILED state.
> TERMINATED -> CANCELLED
> Similar to #1, but with CANCELLED instead of CANCELLING.
> FAILED -> CANCELLED
> Similar to #1, but with CANCELLED instead of CANCELLING.
> In all of the above cases (#1-#4), we skip updating the execution status,
> and log that the execution already succeeded/failed before we were able
> to cancel it.
> CANCELLING -> STARTED
> You cancel the execution while it is still in pending state. Meanwhile,
> while the execution status was already set to CANCELLING, we try to set
> the execution status
> CANCELLED -> STARTED
> Similar to #5, but after the status is set to CANCELLING, it also gets
> set to CANCELLED before attempting to set it to STARTED.
> In cases #5-#6, we skip updtating the execution status, and nothing is logged.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-143) Improve cancelling of workflow execution

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-143:

Summary: Improve cancelling of workflow execution  (was: Improve cancelling 
workflow execution)

> Improve cancelling of workflow execution
> 
>
> Key: ARIA-143
> URL: https://issues.apache.org/jira/browse/ARIA-143
> Project: AriaTosca
>  Issue Type: Story
>Affects Versions: 0.1.0
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>
> Make the process of cancelling execution more robust:
> - Identify possible pitfalls and corner cases.
> - Implement force cancelling.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARIA-143) Improve cancelling workflow execution

[Avia Efrat (JIRA)]

Avia Efrat created ARIA-143:
---

 Summary: Improve cancelling workflow execution
 Key: ARIA-143
 URL: https://issues.apache.org/jira/browse/ARIA-143
 Project: AriaTosca
  Issue Type: Story
Affects Versions: 0.1.0
Reporter: Avia Efrat
Assignee: Avia Efrat


Make the process of cancelling execution more robust:
- Identify possible pitfalls and corner cases.
- Implement force cancelling.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARIA-133) Add status-related properties to Execution, Task and Node models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat closed ARIA-133.
---

> Add status-related properties to Execution, Task and Node models
> 
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
> Fix For: 0.1.0
>
>
> We are adding those properties so it will be easier to filter these models 
> from storage according to their status, and to not make use of the their 
> `status` constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add status-related properties to Execution, Task and Node models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Summary: Add status-related properties to Execution, Task and Node models  
(was: Add status-related methods to Execution, Task and Node models)

> Add status-related properties to Execution, Task and Node models
> 
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding those properties so it will be easier to filter these models 
> from storage according to their status, and to not make use of the their 
> `status` constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add status-related methods to Execution, Task and Node models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Summary: Add status-related methods to Execution, Task and Node models  
(was: Add status-related methods to the Execution, Task and Node models)

> Add status-related methods to Execution, Task and Node models
> -
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding those methods so it will be easier to filter these models from 
> storage according to their status, and to not make use of the their `status` 
> constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add status-related methods to the Execution, Task and Node models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Description: We are adding those methods so it will be easier to filter 
these models from storage according to their status, and to not make use of the 
their `status` constants outside of the models themselves.  (was: We are adding 
these methods so it will be easier to filter these models from storage 
according to their status, and to not make use of the their `status` constants 
outside of the models themselves.)

> Add status-related methods to the Execution, Task and Node models
> -
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding those methods so it will be easier to filter these models from 
> storage according to their status, and to not make use of the their `status` 
> constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add status-related methods to the Execution, Task and Node models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Summary: Add status-related methods to the Execution, Task and Node models  
(was: Add status-related methods to the Execution and Task models)

> Add status-related methods to the Execution, Task and Node models
> -
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding these methods so it will be easier to filter these models from 
> storage according to their status, and to not make use of the their `status` 
> constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add status-related methods to the Execution and Task models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Description: We are adding these methods so it will be easier to filter 
these models from storage according to their status, and to not make use of the 
their `status` constants outside of the models themselves.  (was: We are adding 
these methods so it will be easier to filter executions and tasks from the 
storage according to their status, and to not make use of the their `status` 
constants outside of the models themselves.)

> Add status-related methods to the Execution and Task models
> ---
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding these methods so it will be easier to filter these models from 
> storage according to their status, and to not make use of the their `status` 
> constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add status-related methods to the Execution and Task models

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Summary: Add status-related methods to the Execution and Task models  (was: 
Add is_active and is_ended methods to the Execution and Task model)

> Add status-related methods to the Execution and Task models
> ---
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding these methods so it will be easier to filter executions and 
> tasks from the storage according to their status, and to not make use of the 
> their `status` constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add is_active and is_ended methods to the Execution model

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Description: We are adding these methods so it will be easier to filter 
executions and tasks from the storage according to their status, and to not 
make use of the their `status` constants outside of the models themselves.  
(was: We are adding these functions so it will be easier to filter executions 
from the storage according to their status, and to not make use of the `status` 
constants outside of the Execution model.)

> Add is_active and is_ended methods to the Execution model
> -
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding these methods so it will be easier to filter executions and 
> tasks from the storage according to their status, and to not make use of the 
> their `status` constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-133) Add is_active and is_ended methods to the Execution and Task model

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-133:

Summary: Add is_active and is_ended methods to the Execution and Task model 
 (was: Add is_active and is_ended methods to the Execution model)

> Add is_active and is_ended methods to the Execution and Task model
> --
>
> Key: ARIA-133
> URL: https://issues.apache.org/jira/browse/ARIA-133
> Project: AriaTosca
>  Issue Type: Task
>    Reporter: Avia Efrat
>    Assignee: Avia Efrat
>Priority: Minor
>
> We are adding these methods so it will be easier to filter executions and 
> tasks from the storage according to their status, and to not make use of the 
> their `status` constants outside of the models themselves.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARIA-133) Add is_active and is_ended methods to the Execution model

[Avia Efrat (JIRA)]

Avia Efrat created ARIA-133:
---

 Summary: Add is_active and is_ended methods to the Execution model
 Key: ARIA-133
 URL: https://issues.apache.org/jira/browse/ARIA-133
 Project: AriaTosca
  Issue Type: Task
Reporter: Avia Efrat
Assignee: Avia Efrat
Priority: Minor


We are adding these functions so it will be easier to filter executions from 
the storage according to their status, and to not make use of the `status` 
constants outside of the Execution model.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (ARIA-124) The 'simple topologies' of the tests are not tosca complient

[Avia Efrat (JIRA)]

Avia Efrat created ARIA-124:
---

 Summary: The 'simple topologies' of the tests are not tosca 
complient
 Key: ARIA-124
 URL: https://issues.apache.org/jira/browse/ARIA-124
 Project: AriaTosca
  Issue Type: Bug
Reporter: Avia Efrat
Priority: Minor


We often use create_simple_topology_two_nodes and 
create_simple_topology_three_nodes in our tests.
Thing is, the dependent node has both the requirement and the capability, while 
actually the requirement should be a part of the dependent node, and the 
capability a part of the dependency nodes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-96) Dependency versions strictness / conflicts

[Avia Efrat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Avia Efrat updated ARIA-96:
---
Description: 
When ARIA is used by another project, it might lead to dependency versions 
conflicts.
Dependency versions should be made less strict (i.e. ranges).
Alternatively we could consider vendoring some of the more common dependencies 
inside ARIA.
--
Our conclusions:

1. Currently, don't vendor any library.

2. Use pip-tools (specifically, pip-compile) to manage our dependencies / 
requirement files.

3. requirements.in:
The requirements.in will be read into `install_requires`, and includes loose 
dependencies (as possible, and only direct dependencies), as is common when 
installing using a setup.py file.
Since we haven't tested ARIA with many versions of our dependencies, our 
dependencies are not very loose, but we are hoping to improve this as our 
project matures.
Currently, when we provide an upper bound, it is either because of python 2.6 
compatibility, or according to a semantic versioning (i.e. future versions that 
could break the current API). Lower boundaries are usually the lowest version 
that we tested with ARIA, or because version before are lacking functionality 
we are using.

4. requirements.txt:
The requirements.txt is generated from requirements.in via pip-compile, and 
includes fixed-version dependencies, including all transitive dependencies, in 
order to provide an stable environment that ARIA is ensured to work on.

5. python 2.6 compatible dependencies:
As pip-compile currently does not provide support for conditional dependencies 
(https://github.com/jazzband/pip-tools/issues/435), we are adding these 
dependencies explicitly in the setup.py via `extras_require`, and manually in 
the generated requirements.txt. We are also mentioning this issue in a comment 
in requirements.in.

  was:
When ARIA is used by another project, it might lead to dependency versions 
conflicts.
Dependency versions should be made less strict (i.e. ranges).
Alternatively we could consider vendoring some of the more common dependencies 
inside ARIA.


> Dependency versions strictness / conflicts
> --
>
> Key: ARIA-96
> URL: https://issues.apache.org/jira/browse/ARIA-96
> Project: AriaTosca
>  Issue Type: Task
>Reporter: Ran Ziv
>    Assignee: Avia Efrat
>
> When ARIA is used by another project, it might lead to dependency versions 
> conflicts.
> Dependency versions should be made less strict (i.e. ranges).
> Alternatively we could consider vendoring some of the more common 
> dependencies inside ARIA.
> --
> Our conclusions:
> 1. Currently, don't vendor any library.
> 2. Use pip-tools (specifically, pip-compile) to manage our dependencies / 
> requirement files.
> 3. requirements.in:
> The requirements.in will be read into `install_requires`, and includes loose 
> dependencies (as possible, and only direct dependencies), as is common when 
> installing using a setup.py file.
> Since we haven't tested ARIA with many versions of our dependencies, our 
> dependencies are not very loose, but we are hoping to improve this as our 
> project matures.
> Currently, when we provide an upper bound, it is either because of python 2.6 
> compatibility, or according to a semantic versioning (i.e. future versions 
> that could break the current API). Lower boundaries are usually the lowest 
> version that we tested with ARIA, or because version before are lacking 
> functionality we are using.
> 4. requirements.txt:
> The requirements.txt is generated from requirements.in via pip-compile, and 
> includes fixed-version dependencies, including all transitive dependencies, 
> in order to provide an stable environment that ARIA is ensured to work on.
> 5. python 2.6 compatible dependencies:
> As pip-compile currently does not provide support for conditional 
> dependencies (https://github.com/jazzband/pip-tools/issues/435), we are 
> adding these dependencies explicitly in the setup.py via `extras_require`, 
> and manually in the generated requirements.txt. We are also mentioning this 
> issue in a comment in requirements.in.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)