Re: [RESULT] [VOTE] Retire AriaTosca Podling

[Tal Liron]

"Free floating" does sound better than "king of nothing." ;)

On Thu, Jun 28, 2018 at 9:18 AM Suneel Marthi 
wrote:

> ...u r still an Apache committer - (free floating committer now) :-)
>
> On Thu, Jun 28, 2018 at 10:14 AM, Tal Liron  wrote:
>
> > On Thu, Jun 28, 2018 at 8:09 AM Thomas Nadeau 
> > wrote:
> >
> > > I fully intend to take the ASF Committer role seriously and help out/
> > > contribute to other projects as time permits going forward and look
> > > forward to working
> > > and collaborating with you all in the future.
> > >
> >
> > We are only committers on AriaTosca, so now that it's being retired we
> are
> > kings of nothing. :)
> >
>

Re: [RESULT] [VOTE] Retire AriaTosca Podling

[Tal Liron]

On Thu, Jun 28, 2018 at 8:09 AM Thomas Nadeau  wrote:

> I fully intend to take the ASF Committer role seriously and help out/
> contribute to other projects as time permits going forward and look
> forward to working
> and collaborating with you all in the future.
>

We are only committers on AriaTosca, so now that it's being retired we are
kings of nothing. :)

Re: [RESULT] [VOTE] Retire AriaTosca Podling

[Tal Liron]

Well, so it goes.

Many thanks to Suneel and John for their patient mentorship.

Many thanks to Cloudify for their initial seed code and funding.

On Thu, Jun 28, 2018 at 8:01 AM Suneel Marthi  wrote:

> The vote ended today and here are the results.
>
> Binding +1 : 5 (Jakob Homan, Tal Liron, Thomas Nadeau, John Ament, Suneel
> Marthi)
>
> The Vote to retire this podling has passed and will move forward with next
> steps to retire this podling.
>
> Thanks for all the votes.
>
> Suneel
>

Re: [VOTE] Retire AriaTosca Podling

[Tal Liron]

Hi Doron,

You do not have voting rights on this issue.

However, I don't think you should be too worried. The license is Apache
2.0, and you are very welcome to fork the project and continue its
development. There have been many successful forks in the history of open
source. This project may very well live long and prosper under new
management. It's also possible (so I understand) to resurrect a project
back into incubation should it prove viable in the future.

On Thu, Jun 28, 2018 at 1:08 AM Doron Bleiberg 
wrote:

> -1 At ECI Telecom we are checking whether to contribute for this project.
> This will be done as part of the work on our MANO product. We will have
> final resolution by the end of July, after we will complete our tools
> comparison and selection.
>
> -Original Message-
> From: Suneel Marthi [mailto:smar...@apache.org]
> Sent: June 28, 2018 00:19
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: [VOTE] Retire AriaTosca Podling
>
> This is a reminder that this Vote ends tomorrow and so far we seem to have
> consensus to retire this podling.
>
> On Mon, Jun 25, 2018 at 4:41 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > +1
> >
> > Sent from my iPhone
> >
> > > On Jun 25, 2018, at 3:12 PM, Jakob Homan  wrote:
> > >
> > > +1
> > >
> > >> On 25 June 2018 at 09:09, John D. Ament 
> wrote:
> > >> +1
> > >>
> > >>> On Mon, Jun 25, 2018, 10:40 AM Suneel Marthi 
> > wrote:
> > >>>
> > >>> In light of the discussion on
> > >>> https://lists.apache.org/thread.html/ccad17927b23573e0bef3062c98e7
> > >>> a
> > 72455415be959b2f5859ed6898@%3Cdev.ariatosca.apache.org%3E
> > >>>
> > >>> and given that the project has not seen any activity over the past
> > >>> 5 months and all of the active committers have no time for the
> > >>> project -
> > this
> > >>> is a call for Vote to retire the AriaTosca podling.
> > >>>
> > >>> Please Vote :
> > >>>
> > >>> +1 = Yes,. Retire AriaTosca
> > >>> -1 = No, because .
> > >>>
> > >>>
> > >>> Here's my +1.
> > >>>
> > >>>
> > >>> Suneel
> >
>
> ___
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> ___
>

Re: [VOTE] Retire AriaTosca Podling

[Tal Liron]

+1

On Mon, Jun 25, 2018 at 9:40 AM Suneel Marthi  wrote:

> In light of the discussion on
>
> https://lists.apache.org/thread.html/ccad17927b23573e0bef3062c98e7a72455415be959b2f5859ed6898@%3Cdev.ariatosca.apache.org%3E
>
> and given that the project has not seen any activity over the past 5 months
> and all of the active committers have no time for the project - this is a
> call for Vote to retire the AriaTosca podling.
>
> Please Vote :
>
> +1 = Yes,. Retire AriaTosca
> -1 = No, because .
>
>
> Here's my +1.
>
>
> Suneel
>

Re: Updated: Discuss The Future Of AriaTosca - Meeting Minutes

[Tal Liron]

Sadly, yes.

Do you have a link the formal procedure? Does it need to be proposed in
private@ or here?

On Mon, Jun 25, 2018 at 7:57 AM Thomas Nadeau  wrote:

> +1
>
> > On Jun 25, 2018, at 8:56 AM, Suneel Marthi  wrote:
> >
> > Given that its been over a month since our last meeting about the future
> of
> > AriaTosca - and wee have not heard back from Ericsson - I propose that we
> > start a [DISCUSS] to retire this project.
> >
> > Thoughts?
> >
> > On Thu, Jun 7, 2018 at 6:51 PM, Tal Liron  wrote:
> >
> >> I actually think my work is not orthogonal... It is a complete TOSCA
> parser
> >> that can do a lot of what AriaTosca does, if not more, in that respect.
> So,
> >> depending on what folk think about it my project, it might make since to
> >> move development focus there. (It's also Apache licensed.)
> >>
> >> However, it does not exactly include an orchestrator. Instead, it
> targets
> >> Kubernetes, which does your orchestration for you.
> >>
> >> If folk want an AriaTosca-style orchestrator, I don't think it would be
> too
> >> hard to add one. AriaTosca's orchestration is very simple. I have some
> >> thoughts for how to do so and can assist, though I am not personally
> >> interested in classical orchestration. A think a better option might be
> to
> >> plug it into Cloudify Community Edition, which is a serious
> orchestrator.
> >> The Cloudify folk might be interested in assisting on that, since they
> do
> >> want TOSCA support in their product.
> >>
> >> I am planning on a public release on Monday, assuming I don't have to
> much
> >> fun this weekend. :)
> >>
> >> On Thu, Jun 7, 2018 at 4:20 PM Thomas Nadeau 
> >> wrote:
> >>
> >>>Tal’s work is orthogonal to the status of the project as we
> >>> discussed.  Sunil’s
> >>> ‘ask’ hasn’t been addressed, which was your guys’ action from the
> meeting
> >>> we had about
> >>> 2 weeks ago now.
> >>>
> >>>—Tom
> >>>
> >>>
> >>>> On Jun 7, 2018, at 9:07 AM, S Shenbaga Rajan <
> >>> s.shenbaga.ra...@ericsson.com> wrote:
> >>>>
> >>>> Hi Tom,
> >>>>
> >>>> There are some internal delays anyway. But I thought we will be having
> >>> for some info from Tal's work and assess the same, before we can make a
> >>> final decision.
> >>>>
> >>>> Thanks,
> >>>> /Shen
> >>>>
> >>>> -Original Message-
> >>>> From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> >>>> Sent: Thursday, June 07, 2018 6:30 PM
> >>>> To: dev@ariatosca.incubator.apache.org
> >>>> Cc: smar...@apache.org
> >>>> Subject: Re: Updated: Discuss The Future Of AriaTosca - Meeting
> Minutes
> >>>>
> >>>> Guys,
> >>>>
> >>>> Its been a week (and well past “the end of this week”). Do you have
> any
> >>> updates ?
> >>>>
> >>>> —Tom
> >>>>
> >>>>
> >>>>> On May 30, 2018, at 1:01 AM, S Shenbaga Rajan <
> >>> s.shenbaga.ra...@ericsson.com> wrote:
> >>>>>
> >>>>> Hi Sunil,
> >>>>>
> >>>>> Give us couple of days. We are discussing around this topic.
> >>>>> I would come back by end of this week.
> >>>>>
> >>>>> Thanks,
> >>>>> /Shen
> >>>>>
> >>>>> -Original Message-
> >>>>> From: Suneel Marthi [mailto:smar...@apache.org]
> >>>>> Sent: Wednesday, May 30, 2018 5:30 AM
> >>>>> To: dev@ariatosca.incubator.apache.org
> >>>>> Subject: Re: Updated: Discuss The Future Of AriaTosca - Meeting
> >>>>> Minutes
> >>>>>
> >>>>> @DJ - any updates - we are due to submit the incubator report , let
> us
> >>> know by tomorrow as to what Ericsson's decision is.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, May 25, 2018 at 6:11 PM, Suneel Marthi 
> >>> wrote:
> >>>>>
> >>>>>> Thanks for the call this week.
> >>>>>>
> >>>>>> @DJ, please let us know by next week about Ericsson's deci

Introducing Puccini, a possible alternative to AriaTosca

[Tal Liron]

Hello AriaTosca users,

I'm happy to introduce a new project that I've been working on the past few
months. I humbly offer it for consideration as an alternative to AriaTosca:

https://github.com/tliron/puccini

There's a lot of documentation on the site, but I thought it useful to
provide the following more specific comparison with AriaTosca:

*GOALS: PARSER VS. ORCHESTRATOR*

AriaTosca's goal is to be a complete TOSCA solution, meaning that it allows
you to *both* parse *and* deploy TOSCA service templates.

It's a goal that I found problematic from the very start. First, in that it
would be quite impossible for AriaTosca to be more than a "toy"
orchestrator. It could never compete with mature packages such as Cloudify,
Ansible, Juju, etc. Second, in that it would make it that much harder to
integrate AriaTosca into a real orchestrator. I worked hard to make sure
that the parser would be as independent as possible, but it was an uphill
battle against the requirements for orchestration. Because it has an
orchestrator built in there's more "surface area" in general that you would
have to deal with when integrating it into your product. Third, I believe
that there cannot be a true "default" orchestrator for TOSCA. The language
was designed to specifically avoid dictating orchestration behavior. This
means that AriaTosca is necessarily opinionated, and as such limits the
imagination as to what TOSCA can be used for. This is painfully obvious
when targeting Kubernetes, where you never want to treat a "node instance"
(a pod? a container? a deployment?) as anything other than an
implementation detail. And yet AriaTosca requires you to think in terms of
node instances.

Puccini doesn't intend to be an orchestrator, but rather a TOSCA frontend
for orchestrators. It is designed to provide your orchestrator with exactly
what it needs to do its work. This allows it to be much more focused and
less opinionated about TOSCA. Crucially, it comes with a TOSCA profile for
Kubernetes and out of the box can deploy TOSCA directly to a Kubernetes
cluster.

I know that some AriaTosca users want orchestration. My advice is that you
should seriously consider Kubernetes as an alternative. It elegantly solves
so many tricky orchestration problems such as resource provisioning,
discovery, networking (SDN), scaling, and redundancy. Service mesh add-ons
such as Istio provide you instantaneously with powerful application
robustness, control, and visibility. There exist several production-grade,
commercially supported Kubernetes platforms, such as OpenShift
, Rancher ,
and many more are coming. And if you are thinking that Kubernetes is only
about Docker containers, think again: Intel's new Kata Containers
 allows you to use lightweight virtual machines
in Kubernetes, and the roadmap for OpenShift includes support for
full-blown virtual machines using libvirt, including Windows VMs (and
containers) on Azure or otherwise.

Generally, the "cloud native" approach to building software discourages
classical ssh-and-execute orchestration. Instead, the application itself
knows that it's running in a cloud and uses the cloud infrastructure
directly. In Kubernetes this means calling the API server, storing state on
etcd, and watching ConfigMaps
.
More advanced features, such as lifecycle management, can be achieved by
using custom operators .

Still, if you really, really insist on classical orchestration, I believe
it would not be too hard to add it to Puccini. Especially if you are
looking for something on par with AriaTosca's simplistic implementation.
Alternatively, you can write a translator or adapter that could connect
Puccini to an existing orchestrator, such as Cloudify, Ansible, etc.

*STATELESS VS. STATEFUL*

AriaTosca requires a database. Managing state is painful, and storing in a
database is slow. AriaTosca is indeed painfully slow for basic parsing.
This also adds enormous complexity to the codebase.

Puccini is stateless. It does generate compiled results, but actually you
don't even need to store them anywhere and can read them directly in your
processor. The result is that Puccini is very, very fast. Also, Puccini
requires no configuration files and doesn't even make use of environmental
variables. You run it, it does its work, and then gets out of your way.
This is the "Unix way".

*GO/JAVASCRIPT VS. PYTHON*

We worked hard to provide a well-documented Python API for AriaTosca. But
is it really necessary? In my opinion, it would have been much easier to go
the "Unix way" and just provide a CLI tool that parses TOSCA and returns a
result. Having to maintain an API, again, adds considerable complexity and
surface area. (Note that Puccini can still be used as a standalone library
to be incorporated into a Go program if you need 

Re: Updated: Discuss The Future Of AriaTosca - Meeting Minutes

[Tal Liron]

I actually think my work is not orthogonal... It is a complete TOSCA parser
that can do a lot of what AriaTosca does, if not more, in that respect. So,
depending on what folk think about it my project, it might make since to
move development focus there. (It's also Apache licensed.)

However, it does not exactly include an orchestrator. Instead, it targets
Kubernetes, which does your orchestration for you.

If folk want an AriaTosca-style orchestrator, I don't think it would be too
hard to add one. AriaTosca's orchestration is very simple. I have some
thoughts for how to do so and can assist, though I am not personally
interested in classical orchestration. A think a better option might be to
plug it into Cloudify Community Edition, which is a serious orchestrator.
The Cloudify folk might be interested in assisting on that, since they do
want TOSCA support in their product.

I am planning on a public release on Monday, assuming I don't have to much
fun this weekend. :)

On Thu, Jun 7, 2018 at 4:20 PM Thomas Nadeau 
wrote:

> Tal’s work is orthogonal to the status of the project as we
> discussed.  Sunil’s
> ‘ask’ hasn’t been addressed, which was your guys’ action from the meeting
> we had about
> 2 weeks ago now.
>
> —Tom
>
>
> > On Jun 7, 2018, at 9:07 AM, S Shenbaga Rajan <
> s.shenbaga.ra...@ericsson.com> wrote:
> >
> > Hi Tom,
> >
> > There are some internal delays anyway. But I thought we will be having
> for some info from Tal's work and assess the same, before we can make a
> final decision.
> >
> > Thanks,
> > /Shen
> >
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> > Sent: Thursday, June 07, 2018 6:30 PM
> > To: dev@ariatosca.incubator.apache.org
> > Cc: smar...@apache.org
> > Subject: Re: Updated: Discuss The Future Of AriaTosca - Meeting Minutes
> >
> > Guys,
> >
> > Its been a week (and well past “the end of this week”). Do you have any
> updates ?
> >
> > —Tom
> >
> >
> >> On May 30, 2018, at 1:01 AM, S Shenbaga Rajan <
> s.shenbaga.ra...@ericsson.com> wrote:
> >>
> >> Hi Sunil,
> >>
> >> Give us couple of days. We are discussing around this topic.
> >> I would come back by end of this week.
> >>
> >> Thanks,
> >> /Shen
> >>
> >> -Original Message-
> >> From: Suneel Marthi [mailto:smar...@apache.org]
> >> Sent: Wednesday, May 30, 2018 5:30 AM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: Updated: Discuss The Future Of AriaTosca - Meeting
> >> Minutes
> >>
> >> @DJ - any updates - we are due to submit the incubator report , let us
> know by tomorrow as to what Ericsson's decision is.
> >>
> >>
> >>
> >> On Fri, May 25, 2018 at 6:11 PM, Suneel Marthi 
> wrote:
> >>
> >>> Thanks for the call this week.
> >>>
> >>> @DJ, please let us know by next week about Ericsson's decision.
> >>>
> >>>
> >>> On Mon, May 21, 2018 at 11:17 AM, Thomas Nadeau
> >>> 
> >>> wrote:
> >>>
> 
>  Discussing the Future of AriaTosca
> 
>  Monday, May 21, 2018 10-11AM EST
> 
> 
>  Attendees: Tal, Ido, Shen, DJ, Tom Nadeau, Sunil
> 
>  Tom: Does anyone want to proceed forward with Aria and how?
>  DJ: Ericsson has been looking into this project/area.  They started
>  buildign the missing parts of Aria and wish to contirbute them back
>  to the community.  Initially we discussed these things with Arthur
> from Cloudify
>  (with Tal) and to help with our contirbutions.   Other than that, we
> were
>  always under the assumption that the communit was moving forward and
>  we thought we could contribute a few things.
> 
>  Most recently we have built a lot of components around Aria
>  (including Tosca 1.1).  Issue is there are no active members that can
> commit our PRs.
>  We are ready to contribute but need to know what the interest of the
>  community.
> 
>  Tom: Tal, Ido? Opinions?
> 
>  Ido: Speaking on behalf of Cloudify, currently we do not have any
>  committers in the Aria project.  We are not actively working on Aria
>  at the moment - as a company we have other initiatives to work on,
>  and other engagements such as LF and ONAP community.  I don't know
>  if that is going to change.
> 
>  Tal: I'd like to suggest a few options to move forward.  Neither
>  Cloudify nor Ericsson can take leadership of the project.  You can
>  take Apache incubation projects into "The Attic". Different status.
>  Can be unfrozen in the future.  Taking it out of the attic is much
>  easier than starting a new project. Another option is to fork the
>  project and take it to github (outside of the Apache org).
> 
>  Tom: Thats just forking the code on github.
> 
>  Tal: Yes. We would tell our mentors in ASF that we are leaving the
>  project and will continue on github.
> 
>  Tom: They can fork independently and collaborate (Cloudify and
> Ericsson).
> 
>  Tal: Ericsson chose this 

Re: Updated: Discuss The Future Of AriaTosca - Meeting Minutes

[Tal Liron]

Hi everyone,

My new TOSCA parser will also be ready for public review in about 1 week. I
propose we delay the decision a bit longer so we can assess the situation.

On Wed, May 30, 2018 at 12:01 AM S Shenbaga Rajan <
s.shenbaga.ra...@ericsson.com> wrote:

> Hi Sunil,
>
> Give us couple of days. We are discussing around this topic.
> I would come back by end of this week.
>
> Thanks,
> /Shen
>
> -Original Message-
> From: Suneel Marthi [mailto:smar...@apache.org]
> Sent: Wednesday, May 30, 2018 5:30 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Updated: Discuss The Future Of AriaTosca - Meeting Minutes
>
> @DJ - any updates - we are due to submit the incubator report , let us
> know by tomorrow as to what Ericsson's decision is.
>
>
>
> On Fri, May 25, 2018 at 6:11 PM, Suneel Marthi  wrote:
>
> > Thanks for the call this week.
> >
> > @DJ, please let us know by next week about Ericsson's decision.
> >
> >
> > On Mon, May 21, 2018 at 11:17 AM, Thomas Nadeau
> > 
> > wrote:
> >
> >>
> >> Discussing the Future of AriaTosca
> >>
> >> Monday, May 21, 2018 10-11AM EST
> >>
> >>
> >> Attendees: Tal, Ido, Shen, DJ, Tom Nadeau, Sunil
> >>
> >> Tom: Does anyone want to proceed forward with Aria and how?
> >> DJ: Ericsson has been looking into this project/area.  They started
> >> buildign the missing parts of Aria and wish to contirbute them back
> >> to the community.  Initially we discussed these things with Arthur from
> Cloudify
> >> (with Tal) and to help with our contirbutions.   Other than that, we
> were
> >> always under the assumption that the communit was moving forward and
> >> we thought we could contribute a few things.
> >>
> >> Most recently we have built a lot of components around Aria
> >> (including Tosca 1.1).  Issue is there are no active members that can
> commit our PRs.
> >> We are ready to contribute but need to know what the interest of the
> >> community.
> >>
> >> Tom: Tal, Ido? Opinions?
> >>
> >> Ido: Speaking on behalf of Cloudify, currently we do not have any
> >> committers in the Aria project.  We are not actively working on Aria
> >> at the moment - as a company we have other initiatives to work on,
> >> and other engagements such as LF and ONAP community.  I don't know if
> >> that is going to change.
> >>
> >> Tal: I'd like to suggest a few options to move forward.  Neither
> >> Cloudify nor Ericsson can take leadership of the project.  You can
> >> take Apache incubation projects into "The Attic". Different status.
> >> Can be unfrozen in the future.  Taking it out of the attic is much
> >> easier than starting a new project. Another option is to fork the
> >> project and take it to github (outside of the Apache org).
> >>
> >> Tom: Thats just forking the code on github.
> >>
> >> Tal: Yes. We would tell our mentors in ASF that we are leaving the
> >> project and will continue on github.
> >>
> >> Tom: They can fork independently and collaborate (Cloudify and
> Ericsson).
> >>
> >> Tal: Ericsson chose this project because they thought there was an
> active
> >> community around an orchestrator.   One option is to look into the
> Cloudify
> >> "community edition". This does not support TOSCA proper but is an
> option.
> >>
> >> DJ: The important part of your last point was to use a pure TOSCA parser
> >> implementation.   This is why we were in favor of Aria.
> >>
> >> I would like to hear from you (Tal) about moving this to github.
> >>
> >> Can you explain why this project was started in Apache?
> >>
> >> Tal: Pros (to github): more flexibility (including management). Cons:
> >> the management complications.
> >>
> >> Right now Aria is being used by the ONAP project in LF.  The fact
> >> that the code belonged to a foundation made it attractive to that
> organization.
> >> WIth that said, Aria does not have a big place.
> >>
> >> There are many successful reasons for how projects are successful on
> >> github with healthy communities.
> >>
> >> I worked hard to get support within Apache for Aria and got mild
> >> support.  The community at large did not support this much.
> >>
> >> Sunil: This is exactly the question I asked to Arthur a year ago.
> >>
> >> Tal: This made sense because it helped us join the open-o and onap
> >> communities.  We hoped those folks would contribute back to the project.
> >> Unfortunately those folks haven't, and I am not hopeful that those
> >> folks will.
> >>
> >> I am actually working on a next-generation of Aria.  I am rewriting
> >> everything in scratch in Go to create a stateless parser (TOSCA).  I
> have a
> >> lot of faith in TOSCA but the approach needs to be a lot simpler.   That
> >> might be out there on the community to collaborate with.
> >>
> >> DJ: As you already pointed out, we are trying to understand if your
> >> new project would have the same attraction.
> >>
> >> Sunil: Attracting contributors is not necessarily related to Apache.
> >> Tensorflow is a massive project that is just on github without any
> 

Re: Conference Info for Monday, June 21, 10AM EST Session

[Tal Liron]

The BlueJeans meeting says it's at 10AM GMT.

To clarify:

You do mean May 21 10AM EST?

On Fri, May 18, 2018 at 11:15 AM Thomas D. Nadeau <tnad...@lucidvision.com>
wrote:

> Yes typo in the subject.  The BJeans is set for May 21 (see below).
>
> tom
>
>
> > On May 18, 2018, at 10:52 AM, Tal Liron <tal.li...@gmail.com> wrote:
> >
> > Don't you mean May 21?
> >
> > On Fri, May 18, 2018 at 7:11 AM Thomas Nadeau <tnad...@lucidvision.com>
> > wrote:
> >
> >>
> >>Hi,
> >>
> >>Below is the conference info for our call on Monday regarding the
> >> discussion around closing down AriaTosca.
> >>Anyone in the community is invited to participate and can use
> this
> >> conference info to connect.
> >>The invite supports as many people as I expect to show up, but if
> >> you for some reason have trouble joining,
> >>please directly email me.
> >>
> >>I will be posting the meeting minutes/notes after the meeting to
> >> the list here as a written record of what
> >>transpires in case anyone cannot attend, as well as to indicate
> to
> >> the community any decisions/actions
> >>that were agreed upon.
> >>
> >>—Tom
> >>
> >>
> >>
> >> The following meeting has been forwarded:
> >>
> >> Subject: Fwd: Discuss Closing Down AriaTosca  (DO NOT FORWARD THIS
> INVITE)
> >> Organizer: inv...@meet.bluejeans.com <mailto:inv...@meet.bluejeans.com>
> >>
> >> Location: https://bluejeans.com/7897462078/5797?src=calendarLink <
> >> https://bluejeans.com/7897462078/5797?src=calendarLink>
> >> Time: Monday, May 21, 2018, 10:00:00 AM - 11:00:00 AM GMT +00:00
> Britain,
> >> Ireland, Portugal
> >>
> >> Invitees: tnad...@redhat.com <mailto:tnad...@redhat.com>;
> >> tnad...@lucidvision.com <mailto:tnad...@lucidvision.com>
> >>
> >>
> >> *~*~*~*~*~*~*~*~*~*
> >>
> >>
> >>
> >> - Original Appointment -
> >> Subject: Fwd: Discuss Closing Down AriaTosca  (DO NOT FORWARD THIS
> INVITE)
> >> Organizer: inv...@meet.bluejeans.com <mailto:inv...@meet.bluejeans.com>
> >>
> >> Location: https://bluejeans.com/7897462078/5797?src=calendarLink <
> >> https://bluejeans.com/7897462078/5797?src=calendarLink>
> >> Time: Monday, May 21, 2018, 10:00:00 AM - 11:00:00 AM GMT +00:00
> Britain,
> >> Ireland, Portugal
> >>
> >> Invitees: tnad...@redhat.com <mailto:tnad...@redhat.com>
> >>
> >>
> >> *~*~*~*~*~*~*~*~*~*
> >>
> >>
> >>
> >>
> >> To join the meeting on a computer or mobile phone :
> >> https://bluejeans.com/7897462078/5797?src=calendarLink <
> >> https://bluejeans.com/7897462078/5797?src=calendarLink>
> >>
> >> Here are the details for the meeting you scheduled:
> >>
> >> To join from a Red Hat Deskphone or Softphone, dial: 84336.
> >> ---
> >> Connecting directly from a room system?
> >>
> >> Just want to dial in on your phone?
> >>
> >> 1.) Dial one of the following numbers:
> >> 408-915-6466 (US)
> >>
> >> See all numbers: https://www.redhat.com/en/conference-numbers <
> >> https://www.redhat.com/en/conference-numbers>
> >> 2.) Enter Meeting ID: 7897462078
> >>
> >> 3.) Enter Passcode: 5797
> >> 4.) Press #
> >>
> >> ---
> >> Want to test your video connection?
> >> https://bluejeans.com/111 <https://bluejeans.com/111>
> >>
> >>
>
>

Re: Conference Info for Monday, June 21, 10AM EST Session

[Tal Liron]

Don't you mean May 21?

On Fri, May 18, 2018 at 7:11 AM Thomas Nadeau 
wrote:

>
> Hi,
>
> Below is the conference info for our call on Monday regarding the
> discussion around closing down AriaTosca.
> Anyone in the community is invited to participate and can use this
> conference info to connect.
> The invite supports as many people as I expect to show up, but if
> you for some reason have trouble joining,
> please directly email me.
>
> I will be posting the meeting minutes/notes after the meeting to
> the list here as a written record of what
> transpires in case anyone cannot attend, as well as to indicate to
> the community any decisions/actions
> that were agreed upon.
>
> —Tom
>
>
>
> The following meeting has been forwarded:
>
> Subject: Fwd: Discuss Closing Down AriaTosca  (DO NOT FORWARD THIS INVITE)
> Organizer: inv...@meet.bluejeans.com 
>
> Location: https://bluejeans.com/7897462078/5797?src=calendarLink <
> https://bluejeans.com/7897462078/5797?src=calendarLink>
> Time: Monday, May 21, 2018, 10:00:00 AM - 11:00:00 AM GMT +00:00 Britain,
> Ireland, Portugal
>
> Invitees: tnad...@redhat.com ;
> tnad...@lucidvision.com 
>
>
> *~*~*~*~*~*~*~*~*~*
>
>
>
> - Original Appointment -
> Subject: Fwd: Discuss Closing Down AriaTosca  (DO NOT FORWARD THIS INVITE)
> Organizer: inv...@meet.bluejeans.com 
>
> Location: https://bluejeans.com/7897462078/5797?src=calendarLink <
> https://bluejeans.com/7897462078/5797?src=calendarLink>
> Time: Monday, May 21, 2018, 10:00:00 AM - 11:00:00 AM GMT +00:00 Britain,
> Ireland, Portugal
>
> Invitees: tnad...@redhat.com 
>
>
> *~*~*~*~*~*~*~*~*~*
>
>
>
>
> To join the meeting on a computer or mobile phone :
> https://bluejeans.com/7897462078/5797?src=calendarLink <
> https://bluejeans.com/7897462078/5797?src=calendarLink>
>
> Here are the details for the meeting you scheduled:
>
> To join from a Red Hat Deskphone or Softphone, dial: 84336.
> ---
> Connecting directly from a room system?
>
> Just want to dial in on your phone?
>
> 1.) Dial one of the following numbers:
> 408-915-6466 (US)
>
> See all numbers: https://www.redhat.com/en/conference-numbers <
> https://www.redhat.com/en/conference-numbers>
> 2.) Enter Meeting ID: 7897462078
>
> 3.) Enter Passcode: 5797
> 4.) Press #
>
> ---
> Want to test your video connection?
> https://bluejeans.com/111 
>
>

Re: [Discuss] Future of AriaTosca

[Tal Liron]

Hi John, they were not private meetings -- everyone was invited on the
public dev list, but the community is small enough that it likely felt
quite intimate. :)

I'm not sure what a meeting would accomplish. I have moved on from
AriaTosca, as I am no longer am paid to work on it. I can't speak for Tom,
but I imagine he would say the same.

I personally have no objections to someone else picking up the project and
taking it over.

I've contacted Cloudify, the company who provided the seed code and paid
for the majority of the work on it until now, but they have not responded.

On Wed, May 16, 2018 at 6:38 AM John D. Ament <johndam...@apache.org> wrote:

> While it may help to have meetings ultimately its a sign of the problems
> here.  All discussion, including PR questions, should be on list.  All
> github commentary is sent to a list as well.
>
> I personally had no idea DJ and Tom met privately to review.
>
> On Wed, May 16, 2018, 7:16 AM Suneel Marthi <smar...@apache.org> wrote:
>
> > DJ,
> >
> > You don't need me for this meeting and I won't be able to make it
> anyways.
> > Its best to coordinate with AriaTosca PMC and committers as to what's a
> > good time that works for all.
> >
> > I'll let Tal and others respond to that.
> >
> > Suneel
> >
> > On Wed, May 16, 2018 at 2:39 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Suneel,
> > >
> > > What is the meeting tool which is preferred. We usually use skype
> meeting
> > > calls.
> > > Also can we have the meeting scheduled tomorrow. Could you please let
> me
> > > know your comfortable time for the meeting ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Suneel Marthi [mailto:suneel.mar...@gmail.com]
> > > Sent: Wednesday, May 16, 2018 11:12 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: [Discuss] Future of AriaTosca
> > >
> > > On Wed, May 16, 2018 at 1:38 AM, D Jayachandran <
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi Suneel,
> > > >
> > > > Currently there is no pending PR's from my side. Earlier Tom and
> > > > myself used to have one to one discussion for merging a PR.
> > > > We have many contributions pending from our side which we have made
> as
> > > > PR yet as we don’t have any committer to acknowledge and merge it I
> > > > can send those contributions as PR, if we have committers to review
> > > > and merge it.
> > > >
> > >
> > > That's the problem - all of the committers and PPMC have since moved
> away
> > > from the project and there's none to steer this forward.
> > > Regardless please setup a call and let's decide on future course.
> > >
> > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > > > -Original Message-
> > > > From: Suneel Marthi [mailto:smar...@apache.org]
> > > > Sent: Wednesday, May 16, 2018 11:04 AM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: [Discuss] Future of AriaTosca
> > > >
> > > > Do u have any open PRs pending review ?  Would any of the present
> > > > PMC/committers have time to review and merge the PRs? @Tal and
> others ?
> > > >
> > > >
> > > >
> > > > On Wed, May 16, 2018 at 1:30 AM, D Jayachandran <
> > > > d.jayachand...@ericsson.com
> > > > > wrote:
> > > >
> > > > > Hi Suneel,
> > > > >
> > > > > We in Ericsson are actively working on ARIA. We want to keep the
> > > > > project on and community active.
> > > > > It is just that we couldn't make any contribution because there is
> > > > > no active committer. I already contacted you regarding the same.
> > > > > Could we setup a short call to discuss on this?
> > > > >
> > > > > Thanks,
> > > > > /DJ
> > > > >
> > > > > -Original Message-
> > > > > From: Suneel Marthi [mailto:smar...@apache.org]
> > > > > Sent: Tuesday, May 15, 2018 11:53 PM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: [Discuss] Future of AriaTosca
> > > > >
> > > > > Adding dev@ to the conversation.
> > > > >
> > > > > On Mon, May 14, 2018 at 7:42 PM, Tal Liron <tal.li...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Almost all the committers have moved on. Unless new contributors
> > > > > > want to come in and revive the efforts, the course of action
> seems
> > > > clear.
> > > > > >
> > > > > >
> > > > > > On Mon, May 14, 2018 at 6:38 PM Suneel Marthi <
> smar...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> Given that the project's not seen any activity in like 3 months
> > > > > >> and the mail lists have gone dry - reviving this discussion
> again
> > > > > >> about the future of AriaTosca and what the next course of action
> > is?
> > > > > >>
> > > > > >> Thoughts/Comments ?
> > > > > >>
> > > > > >> Suneel
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Aria support for TOSCA-simple-1.1

[Tal Liron]

I'm willing to help with this effort is someone can get it started.

What we really need is to spec this out -- can you start by documenting on
the wiki all the changes that ARIA would need to support 1.1? Once we have
that, we can turn it into JIRA tasks that individuals can handle.

On Wed, Mar 7, 2018 at 2:27 AM, Sudhakar Reddy 
wrote:

> Hi,
>
> I'm new to python and aria. So, it'll be difficult for me to
> design/implement this without getting some knowledge on how the YAML
> specification is been converted.
>
> I would like to be part of it if I can get inputs on how the approach
> should be.
>
> Thanks & Regards
> Sudhakar Reddy
> Contact No:8758383421
>
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Tuesday, March 06, 2018 12:23 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Aria support for TOSCA-simple-1.1
>
> Hi Sudhakar,
>
> Am representing ericsson here and we would also like to have the support
> for simple YAML 1.1 with ARIA at the earliest.
> It would be great if you can even contribute in making ARIA compliant to
> simple YAML 1.1 so that the support would be available soon.
> Please share your thoughts over this.
>
> Regards,
> DJ
>
> -Original Message-
> From: Sudhakar Reddy [mailto:sudhakar.re...@amdocs.com]
> Sent: Thursday, March 01, 2018 10:46 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Aria support for TOSCA-simple-1.1
>
> Hi,
>
> I want to know whether we are in the process of giving the support for
> TOSCA definition: simple_yaml_1_1?
>
> As currently ONAP uses 1.1 version yaml to create the service model, the
> same won't be validated by aria. Let me know your inputs on this.
>
> Thanks & Regards
> Sudhakar Reddy
> Contact No:8758383421
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>
>

Re: ARIA-400

[Tal Liron]

It would be wonderful if this offline meeting could result in a wiki page
explaining how the site is generated/etc... :)

On Tue, Jan 16, 2018 at 1:40 PM, Thomas Nadeau 
wrote:

> Fantastic!
>
> We will need to sit down and go over a bit of a tutorial on how the site is
> generated/etc... Lets figure out a time/date offline.
>
> --Tom
>
>
> On Tue, Jan 16, 2018 at 2:37 PM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com> wrote:
>
> > Hi,
> >
> > I'd like to help with the developer website issues in the current sprint
> > but
> > I think it'd be better if we can resolve ARIA-400 first (Make
> > http://ariatosca.incubator.apache.org/getting-started/ point at the live
> > Github).
> >
> > Tom, this is currently assigned to you. Could you please give me a hint
> > on how to get started? I'd like to help and I'm guessing this isn't about
> > updating
> > the links but doing something more advanced.
> >
> > Thanks,
> > Miguel
> >
>

Re: Apache and committer account

[Tal Liron]

No worries, DJ. The process takes some time to learn... and it doesn't hurt
to have the ICLA on file, ready for when you are voted to be committer. :)

On Tue, Jan 9, 2018 at 8:07 AM, D Jayachandran 
wrote:

> It was communicated by Ran Ziv, to submit the ICLA, so I thought I was
> necessary even to contribute.
> Now it's clear to me.
>
> -Original Message-
> From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> Sent: Tuesday, January 09, 2018 5:56 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Apache and committer account
>
> Why are you submitting the ICLA?  You only need to do that after you have
> been voted as a committer by the existing Committers.
>
> --Tom
>
>
> On Tue, Jan 9, 2018 at 2:00 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi All,
> >
> > I have already submitted the Apache ICLA and got the below response.
> > Please when will the apache account be created for me to be an committer
> ?
> >
> > =
> >
> > Dear D Jayachandran,
> >
> >
> >
> > This message acknowledges receipt of your ICLA, which has been filed
> > in the Apache Software Foundation records.
> >
> >
> >
> > With this message, the Incubator PMC and the AriaTosca podling have
> > been notified that your ICLA has been filed.
> >
> > Please contact them with any questions.
> >
> >
> >
> > Warm Regards,
> >
> >
> >
> > -- Craig L Russell
> >
> > Secretary, Apache Software Foundation
> > ===
> >
> > Regards,
> > DJ
> >
>

Re: Apache and committer account

[Tal Liron]

Hi DJ,

You do not have to submit until the ICLA until you are officially invited
to become a committer. Such an invitation would come only after the PPMC
votes to invite you. And that happens only after a member of the PPMC
nominates you. None of that has happened quite yet!

We have created a list of expectations we have for would-be committers:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer

You're basically on the right track. I think after a few more PRs you will
be nominated.







On Tue, Jan 9, 2018 at 1:00 AM, D Jayachandran 
wrote:

> Hi All,
>
> I have already submitted the Apache ICLA and got the below response.
> Please when will the apache account be created for me to be an committer ?
>
> =
>
> Dear D Jayachandran,
>
>
>
> This message acknowledges receipt of your ICLA, which has been filed in
> the Apache Software Foundation records.
>
>
>
> With this message, the Incubator PMC and the AriaTosca podling have been
> notified that your ICLA has been filed.
>
> Please contact them with any questions.
>
>
>
> Warm Regards,
>
>
>
> -- Craig L Russell
>
> Secretary, Apache Software Foundation
> ===
>
> Regards,
> DJ
>

Re: Support for the property type 'null'

[Tal Liron]

I personally never knew how to handle this bizarre type, and never
understood why it existed in TOSCA. Since it always can ever have one and
only one value, what's the point of having "required" or "default" for it?
How should those be handled?

I will leave it up to you, or another contributor to decide. :)

My only guideline would be: I believe this type exists, perhaps, to allow
for temporary deprecation/cancellation of properties without removing them
entirely. A way of "commenting out" stuff, like you do in programming
languages. With that in mind, things like "required" and "default" should
still retain some meaning. So, if a null-typed property is "required" but
does not have a "default" value: I believe that ARIA should still consider
this an error. Basically, you want the language engine to still do the
right thing even though the type is nonsensical.

On Thu, Jan 4, 2018 at 11:21 PM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried using the property type 'null' in one of the properties of a node
> type.
>
> And I didn't pass any value to the property in the respective node
> template.
>
>
> When I tried storing the template, I get the following validation issues,
>
>
> Storing service template null_test...
> Validation issues:
>   2: field "type" in 
> "aria_extension_tosca.simple_v1_0.definitions.PropertyDefinition"
> is not a valid "str": None
>  @"null.yaml":9:15
>  ValueError: not a "unicode": None
>   4: "type" refers to an unknown data type in "my_null_param": 'None'
>  @"null.yaml":9:15
> Failed to parse service template
>
> I used the following service template,
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> node_types:
>   tosca.nodes.null:
> derived_from: tosca.nodes.Root
> properties:
>   my_null_param:
> required: True
> type: null
>   my_str_param:
> required: True
> type: string
>
> topology_template:
>   node_templates:
>   test_node:
>   type: tosca.nodes.null
>   properties:
> my_null_param:
> my_str_param: hello
>
>
> I had a look at the source code and found that 'null' is regarded as a
> primitive datatype.
>
> As 'null' type also have a YAML specification that must be adhered, could
> that be handled as a separate datatype like 'timestamp' ?
>
>
> And also is this a known issue? Does a JIRA exist for this?
>
>
> Thanks,
>
> /Vaish
>

Re: [VOTE] publish ariatosca 0.2.0

[Tal Liron]

+1

On Thu, Jan 4, 2018 at 10:54 AM, Thomas Nadeau  wrote:

> I updated the script and pushed the artifacts again.  The issue is that
> test.pypi.org does not let you change artifacts once they've been pushed,
> so I cannot delete the one I pushed to replace it with the updated one.
> This should not be an issue, as you can test/verify everything else and
> when I push to the real pypi after everyone checks this out, we should be
> ok.
>
> BTW there is a bug in the asf-release script that has issues if you re-push
> onto an existing release.  The script should delete the target (or attempt
> to) before it svn adds the new artifacts. I can fix that once the smoke has
> cleared with this release.
>
> --Tom
>
>
>
> On Thu, Jan 4, 2018 at 11:38 AM, John D. Ament 
> wrote:
>
> > Can you use the one that is checked in ?
> > https://github.com/apache/incubator-ariatosca/blob/
> > master/release/asf-release.sh#L138
> >
> >
> > On Thu, Jan 4, 2018 at 11:37 AM Thomas Nadeau 
> > wrote:
> >
> > > The asf-release.sh script we are currently using names them as they
> are:
> > >
> > > function _sign_package {
> > > local ARCHIVE_NAME=$1
> > >
> > > echo "Signing archive ${ARCHIVE_NAME}..."
> > > gpg --armor --output ${ARCHIVE_NAME}.asc --detach-sig
> ${ARCHIVE_NAME}
> > > gpg --print-md MD5 ${ARCHIVE_NAME} > ${ARCHIVE_NAME}.md5
> > > gpg --print-md SHA512 ${ARCHIVE_NAME} > ${ARCHIVE_NAME}.sha
> > > }
> > >
> > >
> > > I can change that to sha512 now.
> > >
> > > --Tom
> > >
> > >
> > >
> > > On Thu, Jan 4, 2018 at 11:14 AM, John D. Ament 
> > > wrote:
> > >
> > > > Thomas,
> > > >
> > > > The files are still named "sha" instead of "sha512"
> > > >
> > > > John
> > > >
> > > > On Thu, Jan 4, 2018 at 10:59 AM Thomas Nadeau 
> > > wrote:
> > > >
> > > > > Aria Community:
> > > > >
> > > > > This is a vote to release Apache AriaTosca (Incubating) 0.2.0. If
> the
> > > > vote
> > > > > passes, another vote for approving the release will take place on
> the
> > > > > Apache Incubator's PMC. Please verify the various release artifacts
> > and
> > > > > respond to the list with your results.  Instructions for locating
> the
> > > > > artifacts can be found below.
> > > > >
> > > > > The tarball candidate for the 0.2.0 release is in ARIA's /dist/dev
> > > > folder:
> > > > > *
> > > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > 0.2.0-incubating/
> > > > > <
> > > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > 0.2.0-incubating/
> > > > > >*
> > > > >
> > > > > The testing/staging pypi version can be found here:
> > > > > https://test.pypi.org/project/apache-ariatosca/
> > > > > Instructions for installation etc. may be found in the README file
> > > inside
> > > > > the tarball.  Note there are different instructions for downloading
> > and
> > > > > installing from test.pypi, so please refer to test.pypi.org for
> > > > > instructions.   The list of resolved issues for this release are
> > simply
> > > > all
> > > > > the issues that have been resolved thus far since the last release.
> > > Those
> > > > > can be found here: https://issues.apache.org/
> jira/secure/RapidBoard.
> > > > > jspa?rapidView=150=ARIA=planning&
> > selectedIssue=ARIA-394
> > > > >  > > > rapidView=150=ARIA=planning=ARIA-394>
> > > > > Please vote to publish this tarball on ARIA's /dist/release folder
> > and
> > > > > release on pypi.  The voting for this must be open for 3 full days
> to
> > > all
> > > > > Committers within the project, and then for 3 full days on the
> Apache
> > > > PMC.
> > > > >  Voting for the release will begin now at 12PM EST, Thursday,
> January
> > > 4,
> > > > > 2018 and be completed on  12PM EST on Sunday, January 7, 2018.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --Tom
> > > > >
> > > >
> > >
> >
>

Re: Implementation of Reserved Function Keywords ( SOURCE, TARGET ) and Artifact Function

[Tal Liron]

We indeed need a new bug opened for the first issue.

The second issue is part of the JIRA for artifact management, I believe.

On Wed, Jan 3, 2018 at 6:11 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Hi,
>
>
>
> When trying the attribute,  property and artifact functions in ARIA, we
> faced the following issues,
>
>
>
> 1.   I tried using the reserved function keywords like SOURCE and
> TARGET in the property and attribute functions. The keywords were not
> working when used inside relationship template with any functions at
> service-template level and threw error “InvalidValueError : function
> "get_property" refers to "SOURCE" but it is not contained in a
> relationship”. On further analysis, I found that the container_holder
> object to the method get_source() and get_target() was always a node /node
> template object rather than a relationship object.
>
>
>
> 2.   The Artifact function get_artifact() was not working, as the
> __evaluate__() of GetArtifact had no implementation.
>
>
>
> Could you please confirm if this is an issue so that I can raise a JIRA
> ticket and contribute for the same?
>
>
>
> Regards,
>
> Vaishali.
>

Re: Database session management with model storage.

[Tal Liron]

The default storage, SQLite, has certain concurrency limitations, but if
you use a more robust server (MySQL, Postresql) there should be no issues.

Maxim, any thoughts?

On Fri, Dec 29, 2017 at 12:01 AM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi,
>
> We have built a REST Interface on top of ARIA. With the current
> implementation of ARIA, the "model storage" is seen as a singleton class,
> thereby the database session is also restricted to a single session.
> By exposing ARIA over REST, In a multithreaded scenario we are ending up
> in having the same database session over multiple threads. This will bring
> about issues during various db related actions across multiple requests.
>
> ARIA being a CLI at this moment will not have any issues with this
> approach but to be used and exposed over other interfaces it will be a
> challenge.
> Please let us know if the session management can be handled properly with
> the model storage ? Do you already have any plans to work on this item or
> kindly provide your feedback on this issue.
>
>
> Regards,
> DJ
>

Re: [VOTE] publish ariatosca 0.2.0

[Tal Liron]

+1

   - I downloaded and unpacked the release.
   - Version is correct.
   - API docs are in "docs/html".
   - All tests run with "make test".
   - Installs correctly with "make install-virtual".
   - Played around with Clearwater example.


On Tue, Dec 26, 2017 at 10:11 AM, Thomas Nadeau 
wrote:

> Aria Community:
>
> This is a vote to release Apache AriaTosca (Incubating) 0.2.0. If the vote
> passes, another vote for approving the release will take place on the
> Apache Incubator's PMC.
>
> I created a tarball candidate for the 0.2.0 release and placed it in ARIA's
>  /dist/dev folder:
> https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.2.0-candidate/
> The list of issues Resolved for this release are simply all the issues that
> have been resolved thus far since the last release. Those can be found
> here:
> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=150=ARIA=planning=ARIA-394
> Instructions for installation etc. may be found in the README file inside
> the tarball.  Please vote to publish this tarball on ARIA's /dist/release
> folder.  The voting for this as I understand it, must be open for 3 full
> days to all Committers within the project, and then for 3 full days on the
> Apache PMC.   Voting for the release will begin now at 12PM EST, Tuesday,
> December 26, 2017 and be completed on  12PM EST on Friday, December 29,
> 2017.
>
> Thanks,
>
> --Tom
>

Re: Node Template Substitution

[Tal Liron]

There is currently no clear timeline. I expect it would take several weeks,
perhaps months, unless more contributors step up to assist the effort.

On Tue, Dec 12, 2017 at 5:00 AM, D Jayachandran  wrote:

> Hi,
>
> When can we expect the support for substitution mapping to be merged to
> master branch ?
>
> Regards,
> DJ
> -Original Message-
> From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> Sent: Friday, December 08, 2017 8:26 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> I don't access to the design doc. Am I missing something?
>
> Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
> Or is it postponed to later?
>
> -Steve
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Tuesday, October 17, 2017 4:44 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> There are plans to extend substitution mappings support to TOSCA 1.2, just
> as any other change/improvement in the 1.2 profile.
>
> A CSAR with one 'main' service template and other service templates will
> be stored as one service template, and will have one unique name.
>
> The design doc:
> https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_
> TPqLpvXjzj98NXrAmcjc
>
>
> Additional v1.2 issues (a non-exhaustive list):
> https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_
> oVrZXQ3z4030U6JIXdJ84/edit
>
>
> On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Avia
> > One more question.
> >
> > Say we have a CSAR that contains multiple TOSCA YAML files e.g. a
> > top-level ST and a bunch of low-level STs.
> > I am assuming all those TOSCA service templates (all of them have a
> > full topology section) will be stored as a single “service-template”
> > in ARIA and a single unique name is needed to represent such single
> “service-template”
> > composed of multiple topologies.
> > Is this correct?
> >
> > -Steve
> >
> > -Original Message-
> > From: Steve Baillargeon
> > Sent: Wednesday, October 11, 2017 11:29 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Node Template Substitution
> >
> > Hi Avia
> > Is it possible to review the design documentation for it?
> > Do you have a doc or a few notes describing how ARIA will perform
> > "best matching" based on YAML 1.0/1.1 profile?
> >
> > The full support for NFV Profile 1.0 requires Node Template
> > Substitution defined in YAML 1.2 profile.
> > Any future plans for ARIA to extend Node Template Substitution as
> > defined in YAML 1.2 profile ?
> >
> > Regards
> > Steve B
> >
> > -Original Message-
> > From: Arthur Berezin [mailto:art...@cloudify.co]
> > Sent: Tuesday, October 10, 2017 12:20 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Node Template Substitution
> >
> > Avia, can you please post a link to the design?  thanks
> >
> > On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat  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: Loading Custom Workflows from CSAR

[Tal Liron]

This is indeed the situation right now, but we're unhappy with it and it
may be improved soon.

On Fri, Dec 8, 2017 at 12:05 AM, Vaishnavi K.R <vaishnavi@ericsson.com>
wrote:

> Hi Tal,
>
>
> The loading of the python modules with python functions for workflows
> happens when the module is in PYTHONPATH.
>
> But I could also see that, the absolute path of the resource storage with
> the service template ID is added to sys.path to make it available for
> python.
>
> This facilitates the loading of modules from CSAR, provided the modules
> are present in the root directory of the CSAR.
>
> Am I right?
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron <t...@cloudify.co>
> Sent: Thursday, December 7, 2017 8:51:49 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Loading Custom Workflows from CSAR
>
> Actually, the current implementation does not use the CSAR: it expects that
> the Python function (decorated by @workflow) would be somewhere in the
> Python path, and we are currently missing a CSAR code-loading mechanism.
>
> We do not expect the @workflow function structure to change in any way, so
> I think you can feel confident about writing custom workflows in this
> matter. What might change slightly in the near future is how to package the
> .py file.
>
>
> On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > While the investigation is on-going, I need to double check what can be
> > done today.
> > But I guess how it is done today might change as well (?)
> > Based on our analysis of the latest code base, the loading of the custom
> > workflows today is from CSAR only.
> > Please advise.
> >
> > -Steve
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, November 28, 2017 2:06 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Loading Custom Workflows from CSAR
> >
> > Thanks, Steve. We don't have a JIRA for this right now, but we do intend
> > to have a way to include "plugins" in a CSAR and have them automatically
> > installed. A "plugin" is basically a Python extension to ARIA that can be
> > loaded at runtime and contained per service.
> >
> > This is part of our current general work trying to find a good design for
> > plugins generally, and will likely result in a JIRA epic with several
> > issues. At this time, I don't think it's worth created this epic if we
> > don't have a plan.
> >
> > The design will likely be inspired by the plugin design in Cloudify, from
> > which we grabbed our seed code. However, there is room for some
> > re-imagination especially as pertains TOSCA-specific issues.
> >
> > On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi
> > > As far as I know the implementation string associated with the
> > > aria.Workflow type must call or execute a Python function (using the
> > > dot
> > > notation) that is stored in ARIA, like a plugin.
> > > When will it be possible to refer to  a .py file stored in the CSAR
> > > instead?
> > > Do you have any Jira for this enhancement?
> > >
> > > Regards
> > > Steve B
> > >
> >
>

Re: [DRAFT] Incubator PMC Board Report - December 2017

[Tal Liron]

There actually was some in-person conversation between committers about the
report. But it's a good criticism -- we should make it explicitly open and
via the mailing list.

On Mon, Dec 11, 2017 at 8:39 AM, Thomas Nadeau 
wrote:

>
>
> > On Dec 11, 2017, at 9:36 AM, John D. Ament 
> wrote:
> >
> > The typical steps a podling would take:
> >
> > - Post a report on a common ground (e.g. email, confluence, or other)
> > - Let others know where it is
> > - Discuss it and get others to contribute into it
> > - When the report comes through, post it on the incubator wiki, e.g.
> > https://wiki.apache.org/incubator/December2017 (link changes each month)
> >
> > The report generally looks fine, but I would change it so that only "[X]
> > Community building" is checked.  My current comment from the wiki still
> > holds "Activity on list is picking up over the slack conversations.  A
> > community member is planning to write a report, however it indicates a
> > corporate hierarchy issue within the project that needs to get solved."
> >
> > Basically what that second sentence means is that we shouldn't be reliant
> > on one person to do the report.
>
> Trust me, I am fully willing to share in the “fun” for the next
> report. *)
>
> —Tom
>
>
> >
> > John
> >
> > On Mon, Dec 11, 2017 at 9:05 AM Thomas Nadeau 
> wrote:
> >
> >>
> >>
> >>The AriaTosca report was submitted last Thursday (at least made
> >> available) and is available here:
> >>
> >>
> >> https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Podling+Report+2017-DEC-12
> >> <
> >> https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Podling+Report+2017-DEC-12
> >>>
> >>
> >>I was not made aware of any special process for submitting this
> >> other than letting everyone know on the
> >> mailer that it was being created and where it was in case folks wanted
> to
> >> comment. If there is anything
> >> else needed for this let me know.
> >>
> >>—Tom
> >>
> >>
> >>> On Dec 10, 2017, at 9:36 AM, John D. Ament 
> >> wrote:
> >>>
> >>> All,
> >>>
> >>> Below is the current draft of our report.  As of now, we have 5 reports
> >>> missing and 4 reports not signed off on.  I hope we can get that
> resolved
> >>> in the next few days.  I have copied those podlings impacted.
> >>>
> >>> Incubator PMC report for December 2017
> >>>
> >>> The Apache Incubator is the entry path into the ASF for projects and
> >>> codebases wishing to become part of the Foundation's efforts.
> >>>
> >>> There are currently 53 podlings incubating.  In the month of November,
> we
> >>> executed six releases, added one IPMC member and received the
> resignation
> >>> of another (which is in flight until their sole podling retires).  We
> >> added
> >>> two podlings to our roster, have a few more in the pipeline and have
> one
> >>> podling planning to graduate this month.
> >>>
> >>> * Community
> >>>
> >>> New IPMC members:
> >>>
> >>> - Michael Semb Wever
> >>>
> >>> People who left the IPMC:
> >>>
> >>> - Upayavira (not processed in LDAP yet)
> >>>
> >>> * New Podlings
> >>>
> >>> - Crail
> >>> - Service Comb
> >>>
> >>> * Podlings that failed to report, expected next month
> >>>
> >>> - Amaterasu - Activity stopped late November
> >>> - Aria Tosca
> >>> - HTrace - 0 on list activity
> >>> - Pony Mail - Low activity, suspect just missed.
> >>> - Wave - Retiring
> >>>
> >>> * Podlings Missing sign off
> >>>
> >>> - Griffin
> >>> - Myriad
> >>> - OpenWhisk
> >>> - Spot
> >>>
> >>> * Graduations
> >>>
> >>> The board has motions for the following:
> >>>
> >>> - Trafodion
> >>> - Your podling here?
> >>> - Your podling here?
> >>>
> >>> * Releases
> >>>
> >>> The following releases entered distribution during the month of
> >>> November:
> >>>
> >>> - 2017-11-01 Apache Freemarker  2.3.27
> >>> - 2017-11-08 Apache Netbeans HTML4J 1.5
> >>> - 2017-11-15 Apache Mnemonic0.10.0
> >>> - 2017-11-15 Apache MXNet   0.12.1
> >>> - 2017-11-18 Apache Netbeans HTML4J 1.5.1
> >>> - 2017-11-28 Apache Griffin 0.1.6
> >>>
> >>> * IP Clearance
> >>>
> >>>
> >>>
> >>> * Legal / Trademarks
> >>>
> >>>
> >>>
> >>> * Infrastructure
> >>>
> >>>
> >>>
> >>> * Miscellaneous
> >>>
> >>>
> >>>
> >>> * Credits
> >>>
> >>> --
> >>>  Table of Contents
> >>> Amaterasu
> >>> AriaTosca
> >>> Crail
> >>> Daffodil
> >>> Gearpump
> >>> Griffin
> >>> Hivemall
> >>> HTrace
> >>> Myriad
> >>> Omid
> >>> OpenWhisk
> >>> PageSpeed
> >>> Pony Mail
> >>> Pulsar
> >>> Quickstep
> >>> SAMOA
> >>> SDAP
> >>> SINGA
> >>> Spot
> >>> Superset
> >>> Taverna
> >>> Tephra
> >>> Trafodion
> >>> Wave
> >>>
> >>> --
> >>>
> >>> 
> >>> Amaterasu
> >>>
> >>> Apache Amaterasu is a framework providing continuous 

Re: Loading custom workflows

[Tal Liron]

We had some good discussions are are just about ready to make them public
for soliciting feedback.

I will handle it next week and let the mailing list know!

On Thu, Dec 7, 2017 at 2:31 PM, Thomas Nadeau <tnad...@apache.org> wrote:

> Do you think it is a good idea to start a document and/or wiki entry for a
> thumbnail sketch of how we want to do this?
>
> --Tom
>
> On Thu, Dec 7, 2017 at 2:04 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Our current idea is to support multiple ways of installing extensions.
> One
> > of them will, of course, be by including them in the CSAR file (which can
> > be done in various ways: Python source code, wheels, wagons, etc.). We
> want
> > to standardize all extensions with a single well-defined entry point.
> >
> > On Wed, Dec 6, 2017 at 4:58 PM, Vaishnavi K.R <
> vaishnavi@ericsson.com>
> > wrote:
> >
> > > Hi Tal,
> > >
> > >
> > > Good that this has been considered.
> > >
> > > As all the three entities are mere python modules, it is good to have a
> > > common loading mechanism.
> > >
> > > But will there be any major change in the existing way of loading
> plugins
> > > and using the same in the service template?
> > >
> > >
> > > Thanks,
> > >
> > > /Vaish
> > >
> > > 
> > > From: Tal Liron <t...@cloudify.co>
> > > Sent: Wednesday, December 6, 2017 7:27:02 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Loading custom workflows
> > >
> > > Great question, and it was asked very recently on this list ...
> > >
> > > There is a need for a unified way to dynamically load
> > > extensions/plugins/workflows from CSAR files as well as other places.
> We
> > > are trying to come with a good, forward-looking architectural design
> for
> > > this loading mechanism. I will provide an update on this in the next
> few
> > > days.
> > >
> > > On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R <
> > vaishnavi@ericsson.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > I tried using the custom workflow support provided by ARIA.
> > > >
> > > > In the current ARIA, the custom workflows are directly imported as
> > python
> > > > modules.
> > > >
> > > > It looks like it is loading the python modules that are bundled along
> > > with
> > > > the service template in CSAR.
> > > >
> > > >
> > > > Also I could see that you have plans to load it as how the plugins
> are.
> > > >
> > > > Is anyone working on this?
> > > >
> > > > Will the workflows be packaged as wagon archives and installed?
> > > >
> > > > Will they be referred in the service template with the same
> convention
> > as
> > > > plugins?
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > /Vaish
> > > >
> > >
> >
>

Re: Loading Custom Workflows from CSAR

[Tal Liron]

Actually, the current implementation does not use the CSAR: it expects that
the Python function (decorated by @workflow) would be somewhere in the
Python path, and we are currently missing a CSAR code-loading mechanism.

We do not expect the @workflow function structure to change in any way, so
I think you can feel confident about writing custom workflows in this
matter. What might change slightly in the near future is how to package the
.py file.


On Thu, Dec 7, 2017 at 2:57 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> While the investigation is on-going, I need to double check what can be
> done today.
> But I guess how it is done today might change as well (?)
> Based on our analysis of the latest code base, the loading of the custom
> workflows today is from CSAR only.
> Please advise.
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, November 28, 2017 2:06 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Loading Custom Workflows from CSAR
>
> Thanks, Steve. We don't have a JIRA for this right now, but we do intend
> to have a way to include "plugins" in a CSAR and have them automatically
> installed. A "plugin" is basically a Python extension to ARIA that can be
> loaded at runtime and contained per service.
>
> This is part of our current general work trying to find a good design for
> plugins generally, and will likely result in a JIRA epic with several
> issues. At this time, I don't think it's worth created this epic if we
> don't have a plan.
>
> The design will likely be inspired by the plugin design in Cloudify, from
> which we grabbed our seed code. However, there is room for some
> re-imagination especially as pertains TOSCA-specific issues.
>
> On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > As far as I know the implementation string associated with the
> > aria.Workflow type must call or execute a Python function (using the
> > dot
> > notation) that is stored in ARIA, like a plugin.
> > When will it be possible to refer to  a .py file stored in the CSAR
> > instead?
> > Do you have any Jira for this enhancement?
> >
> > Regards
> > Steve B
> >
>

Re: Loading custom workflows

[Tal Liron]

Our current idea is to support multiple ways of installing extensions. One
of them will, of course, be by including them in the CSAR file (which can
be done in various ways: Python source code, wheels, wagons, etc.). We want
to standardize all extensions with a single well-defined entry point.

On Wed, Dec 6, 2017 at 4:58 PM, Vaishnavi K.R <vaishnavi@ericsson.com>
wrote:

> Hi Tal,
>
>
> Good that this has been considered.
>
> As all the three entities are mere python modules, it is good to have a
> common loading mechanism.
>
> But will there be any major change in the existing way of loading plugins
> and using the same in the service template?
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron <t...@cloudify.co>
> Sent: Wednesday, December 6, 2017 7:27:02 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Loading custom workflows
>
> Great question, and it was asked very recently on this list ...
>
> There is a need for a unified way to dynamically load
> extensions/plugins/workflows from CSAR files as well as other places. We
> are trying to come with a good, forward-looking architectural design for
> this loading mechanism. I will provide an update on this in the next few
> days.
>
> On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R <vaishnavi@ericsson.com>
> wrote:
>
> > Hi,
> >
> >
> > I tried using the custom workflow support provided by ARIA.
> >
> > In the current ARIA, the custom workflows are directly imported as python
> > modules.
> >
> > It looks like it is loading the python modules that are bundled along
> with
> > the service template in CSAR.
> >
> >
> > Also I could see that you have plans to load it as how the plugins are.
> >
> > Is anyone working on this?
> >
> > Will the workflows be packaged as wagon archives and installed?
> >
> > Will they be referred in the service template with the same convention as
> > plugins?
> >
> >
> > Thanks,
> >
> > /Vaish
> >
>

Re: Loading custom workflows

[Tal Liron]

Great question, and it was asked very recently on this list ...

There is a need for a unified way to dynamically load
extensions/plugins/workflows from CSAR files as well as other places. We
are trying to come with a good, forward-looking architectural design for
this loading mechanism. I will provide an update on this in the next few
days.

On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried using the custom workflow support provided by ARIA.
>
> In the current ARIA, the custom workflows are directly imported as python
> modules.
>
> It looks like it is loading the python modules that are bundled along with
> the service template in CSAR.
>
>
> Also I could see that you have plans to load it as how the plugins are.
>
> Is anyone working on this?
>
> Will the workflows be packaged as wagon archives and installed?
>
> Will they be referred in the service template with the same convention as
> plugins?
>
>
> Thanks,
>
> /Vaish
>

Re: get_attribute function not supporting SELF as

[Tal Liron]

I imagine it is related. :)

On Wed, Dec 6, 2017 at 11:23 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> I Just wanted to cross check whether this issue is related to the commit
> "ARIA-349 get_attribute is not calculated at runtime". I will debug into
> this and get back to you for any contribution.
>
> Thank you.
>
> -----Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, December 06, 2017 2:02 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> Thank you for the additional information!
>
> I think that perhaps this bug has to do with setting/retrieving attribute
> data and might not be related to the get_attribute function.
>
> Are you a programmer? Is there any way you can help us debug this on your
> end to find out where things go wrong?
>
> If not, could you possibly share with your complete example, including the
> "sample" plugin code, so that we can debug it?
>
> On Wed, Dec 6, 2017 at 7:07 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > Hi,
> > Yes this scenario is working fine. But in my case, I am not assigning
> > default value to attribute in node type instead assigning the
> > attribute value through a plugin(sample-1.0.0 in my case) using,
> > ctx.node.attributes['config'] = "test" .
> > Then I am trying to fetch this value through get_attribute function in
> > another operation. You can find the service template used below. I
> > saved it as a file named "test.yaml"
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> > imports:
> >   - aria-1.0
> >
> > node_types:
> >   my_Node_Server:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   vmme_configuration:
> > type: string
> >
> > topology_template:
> >policies:
> >  sample:
> >type: aria.Plugin
> >properties:
> >  version: 1.0.0
> >  enabled: true
> >
> >node_templates:
> >  v_mme:
> >type: my_Node_Server
> >interfaces:
> >  Standard:
> >create:
> >  implementation: sample > sample.sample_test.call_test
> >configure:
> >  implementation: sample > sample.sample_test.call_name
> >  inputs:
> >config: {get_attribute: [ v_mme, vmme_configuration ]}
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, December 05, 2017 7:05 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: get_attribute function not supporting SELF as
> > 
> >
> > Sure, it is seen below. I saved it as a file named "v.yaml" and then
> > ran these commands to see the values of the function calls, which in
> > both cases was "hello":
> >
> > aria service-templates store v.yaml v
> > aria service-templates show v -f
> >
> > The file "v.yaml":
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > data_types:
> >
> >   Payload:
> > properties:
> >   config:
> > type: string
> >
> > node_types:
> >
> >   my_Node_Server:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   vmme_configuration:
> > type: string
> > default: hello
> > interfaces:
> >   Standard:
> > type: tosca.interfaces.node.lifecycle.Standard
> > create:
> >   implementation: sample.sample_test.call_test
> >   inputs: {}
> > configure:
> >   implementation: sample.sample_test.call_name
> >   inputs:
> > payload:
> >   type: Payload
> >
> > topology_template:
> >
> >node_templates:
> >  v_mme:
> >type: my_Node_Server
> >interfaces:
> >  Standard:
> >configure:
> >  inputs:
> >payload: {
> >  "config": {get_attribute: [ SELF, vmme_configuration ]}}
> >config: {get_attribute: [ SELF, vmme_configuration ]}
> >
> >
> >
> >
> > On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> > > I have tried the same 

Re: get_attribute function not supporting SELF as

[Tal Liron]

Thank you for the additional information!

I think that perhaps this bug has to do with setting/retrieving attribute
data and might not be related to the get_attribute function.

Are you a programmer? Is there any way you can help us debug this on your
end to find out where things go wrong?

If not, could you possibly share with your complete example, including the
"sample" plugin code, so that we can debug it?

On Wed, Dec 6, 2017 at 7:07 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Hi,
> Yes this scenario is working fine. But in my case, I am not assigning
> default value to attribute in node type instead assigning the attribute
> value through a plugin(sample-1.0.0 in my case) using,
> ctx.node.attributes['config'] = "test" .
> Then I am trying to fetch this value through get_attribute function in
> another operation. You can find the service template used below. I saved it
> as a file named "test.yaml"
>
> tosca_definitions_version: tosca_simple_yaml_1_0
> imports:
>   - aria-1.0
>
> node_types:
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
>
> topology_template:
>policies:
>  sample:
>type: aria.Plugin
>properties:
>  version: 1.0.0
>  enabled: true
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>create:
>  implementation: sample > sample.sample_test.call_test
>configure:
>  implementation: sample > sample.sample_test.call_name
>  inputs:
>config: {get_attribute: [ v_mme, vmme_configuration ]}
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 7:05 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> Sure, it is seen below. I saved it as a file named "v.yaml" and then ran
> these commands to see the values of the function calls, which in both cases
> was "hello":
>
> aria service-templates store v.yaml v
> aria service-templates show v -f
>
> The file "v.yaml":
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> data_types:
>
>   Payload:
> properties:
>   config:
> type: string
>
> node_types:
>
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
> default: hello
> interfaces:
>   Standard:
> type: tosca.interfaces.node.lifecycle.Standard
> create:
>   implementation: sample.sample_test.call_test
>   inputs: {}
> configure:
>   implementation: sample.sample_test.call_name
>   inputs:
> payload:
>   type: Payload
>
> topology_template:
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>configure:
>  inputs:
>payload: {
>  "config": {get_attribute: [ SELF, vmme_configuration ]}}
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
>
>
>
> On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > I have tried the same in the latest master version. Could you please
> > provide the service template you used ?
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, December 05, 2017 3:41 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: get_attribute function not supporting SELF as
> > 
> >
> > I tried here and it did work for me. Are you using the latest master
> > version? We had a few recent commits that have fixed various things.
> >
> > Perhaps you can provide a fully working minimal example that could
> > clearly reproduce this bug?
> >
> > On Tue, Dec 5, 2017 at 12:02 PM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> > > Thanks. I tried this workaround. Still, the get_attribute function
> > > returns the value 'none' when used in the first level of inputs. In
> > > my case, I am trying to update the attribute value in one operation
> > > using plugin and fetch the updated attribute value in another
> > > operation using the get_attribute function, for which it returns
&

Re: get_attribute function not supporting SELF as

[Tal Liron]

Sure, it is seen below. I saved it as a file named "v.yaml" and then ran
these commands to see the values of the function calls, which in both cases
was "hello":

aria service-templates store v.yaml v
aria service-templates show v -f

The file "v.yaml":

tosca_definitions_version: tosca_simple_yaml_1_0

data_types:

  Payload:
properties:
  config:
type: string

node_types:

  my_Node_Server:
derived_from: tosca.nodes.Root
attributes:
  vmme_configuration:
type: string
default: hello
interfaces:
  Standard:
type: tosca.interfaces.node.lifecycle.Standard
create:
  implementation: sample.sample_test.call_test
  inputs: {}
configure:
  implementation: sample.sample_test.call_name
  inputs:
payload:
  type: Payload

topology_template:

   node_templates:
 v_mme:
   type: my_Node_Server
   interfaces:
 Standard:
   configure:
 inputs:
   payload: {
 "config": {get_attribute: [ SELF, vmme_configuration ]}}
   config: {get_attribute: [ SELF, vmme_configuration ]}




On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> I have tried the same in the latest master version. Could you please
> provide
> the service template you used ?
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 3:41 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> I tried here and it did work for me. Are you using the latest master
> version? We had a few recent commits that have fixed various things.
>
> Perhaps you can provide a fully working minimal example that could clearly
> reproduce this bug?
>
> On Tue, Dec 5, 2017 at 12:02 PM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > Thanks. I tried this workaround. Still, the get_attribute function
> > returns the value 'none' when used in the first level of inputs. In my
> > case, I am trying to update the attribute value in one operation using
> > plugin and fetch the updated attribute value in another operation
> > using the get_attribute function, for which it returns 'none' when I
> > use SELF as modelable entity.
> > For the same scenario if I use the node name as modelable entity, it
> > works fine.
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, December 05, 2017 3:10 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: get_attribute function not supporting SELF as
> > 
> >
> > The bug, in case you want to follow its progress:
> > https://issues.apache.org/jira/browse/ARIA-424
> >
> > On Tue, Dec 5, 2017 at 11:35 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > There is a bug here, but it has nothing to do with SELF.
> > >
> > > The issue is that you are using an "ad hoc", typeless input here for
> > > the "configure" operation. Because it's typeless, ARIA sends it "as
> > > is" and thus has no idea that what's inside might be a syntactical
> > > intrinsic function.
> > >
> > > I will open a big for this, but for now the workaround is to
> > > explicitly declare the input at the type, which I think is generally
> > > a good idea. (And actually, I would rather ARIA not allow the
> > > current typeless input
> > > situation.)
> > >
> > > Here's how it would look:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > data_types:
> > >
> > >   Payload:
> > > properties:
> > >   config:
> > > type: string
> > >
> > > node_types:
> > >
> > >   my_Node_Server:
> > > derived_from: tosca.nodes.Root
> > > attributes:
> > >   vmme_configuration:
> > > type: string
> > > default: test default value
> > > interfaces:
> > >   Standard:
> > > type: tosca.interfaces.node.lifecycle.Standard
> > > create:
> > >   implementation: sample.sample_test.call_test
> > >   inputs: {}
> > > configure:
> > >   implementation: sample.sample_test.call_name
> > >   inputs:
> > > payload:
> > >   type: Payload
> > >
> > > t

Re: get_attribute function not supporting SELF as

[Tal Liron]

I tried here and it did work for me. Are you using the latest master
version? We had a few recent commits that have fixed various things.

Perhaps you can provide a fully working minimal example that could clearly
reproduce this bug?

On Tue, Dec 5, 2017 at 12:02 PM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Thanks. I tried this workaround. Still, the get_attribute function returns
> the value 'none' when used in the first level of inputs. In my case, I am
> trying to update the attribute value in one operation using plugin and
> fetch
> the updated attribute value in another operation using the get_attribute
> function, for which it returns 'none' when I use SELF as modelable entity.
> For the same scenario if I use the node name as modelable entity, it works
> fine.
>
> -----Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 3:10 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> The bug, in case you want to follow its progress:
> https://issues.apache.org/jira/browse/ARIA-424
>
> On Tue, Dec 5, 2017 at 11:35 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > There is a bug here, but it has nothing to do with SELF.
> >
> > The issue is that you are using an "ad hoc", typeless input here for
> > the "configure" operation. Because it's typeless, ARIA sends it "as
> > is" and thus has no idea that what's inside might be a syntactical
> > intrinsic function.
> >
> > I will open a big for this, but for now the workaround is to
> > explicitly declare the input at the type, which I think is generally a
> > good idea. (And actually, I would rather ARIA not allow the current
> > typeless input
> > situation.)
> >
> > Here's how it would look:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > data_types:
> >
> >   Payload:
> > properties:
> >   config:
> > type: string
> >
> > node_types:
> >
> >   my_Node_Server:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   vmme_configuration:
> > type: string
> > default: test default value
> > interfaces:
> >   Standard:
> > type: tosca.interfaces.node.lifecycle.Standard
> > create:
> >   implementation: sample.sample_test.call_test
> >   inputs: {}
> > configure:
> >   implementation: sample.sample_test.call_name
> >   inputs:
> > payload:
> >   type: Payload
> >
> > topology_template:
> >
> >node_templates:
> >  v_mme:
> >type: my_Node_Server
> >interfaces:
> >  Standard:
> >configure:
> >  inputs:
> >payload:
> >  config: {get_attribute: [ SELF, vmme_configuration ]}
> >config: {get_attribute: [ SELF, vmme_configuration ]}
> >
> >
> >
> >
> >
> >
> > On Tue, Dec 5, 2017 at 10:58 AM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> >> Here, I have used the get_attribute in the input defined in the
> >> second level, for which it returns me the dictionary object.
> >> inputs:
> >>   payload: {
> >> "config": {get_attribute: [ SELF, vmme_configuration ]}}
> >>
> >> When I use the get_attribute in inputs defined in the first level it
> >> returns me none.
> >> inputs:
> >>config: {get_attribute: [ SELF, vmme_configuration ]}
> >>
> >> Please find the service template below.
> >> node_types:
> >>   my_Node_Server:
> >> derived_from: tosca.nodes.Root
> >> attributes:
> >>   vmme_configuration:
> >> type: string
> >> interfaces:
> >>   Standard:
> >> create:
> >>   implementation: sample > sample.sample_test.call_test
> >>   inputs: {}
> >> configure:
> >>   implementation: sample > sample.sample_test.call_name
> >>   inputs: {}
> >>
> >> topology_template:
> >>
> >>node_templates:
> >>  v_mme:
> >>type: my_Node_Server
> >>interfaces:
> >>  Standard:
> >>configure:
> &g

Re: get_attribute function not supporting SELF as

[Tal Liron]

The bug, in case you want to follow its progress:
https://issues.apache.org/jira/browse/ARIA-424

On Tue, Dec 5, 2017 at 11:35 AM, Tal Liron <t...@cloudify.co> wrote:

> There is a bug here, but it has nothing to do with SELF.
>
> The issue is that you are using an "ad hoc", typeless input here for the
> "configure" operation. Because it's typeless, ARIA sends it "as is" and
> thus has no idea that what's inside might be a syntactical intrinsic
> function.
>
> I will open a big for this, but for now the workaround is to explicitly
> declare the input at the type, which I think is generally a good idea. (And
> actually, I would rather ARIA not allow the current typeless input
> situation.)
>
> Here's how it would look:
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> data_types:
>
>   Payload:
> properties:
>   config:
> type: string
>
> node_types:
>
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
> default: test default value
> interfaces:
>   Standard:
> type: tosca.interfaces.node.lifecycle.Standard
> create:
>   implementation: sample.sample_test.call_test
>   inputs: {}
> configure:
>   implementation: sample.sample_test.call_name
>   inputs:
> payload:
>   type: Payload
>
> topology_template:
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>configure:
>  inputs:
>payload:
>  config: {get_attribute: [ SELF, vmme_configuration ]}
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
>
>
>
>
>
> On Tue, Dec 5, 2017 at 10:58 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
>> Here, I have used the get_attribute in the input defined in the second
>> level, for which it returns me the dictionary object.
>> inputs:
>>   payload: {
>> "config": {get_attribute: [ SELF, vmme_configuration ]}}
>>
>> When I use the get_attribute in inputs defined in the first level it
>> returns
>> me none.
>> inputs:
>>config: {get_attribute: [ SELF, vmme_configuration ]}
>>
>> Please find the service template below.
>> node_types:
>>   my_Node_Server:
>> derived_from: tosca.nodes.Root
>> attributes:
>>   vmme_configuration:
>> type: string
>> interfaces:
>>   Standard:
>> create:
>>   implementation: sample > sample.sample_test.call_test
>>   inputs: {}
>> configure:
>>   implementation: sample > sample.sample_test.call_name
>>   inputs: {}
>>
>> topology_template:
>>
>>node_templates:
>>  v_mme:
>>type: my_Node_Server
>>interfaces:
>>  Standard:
>>configure:
>>  inputs:
>>payload: {
>>  "config": {get_attribute: [ SELF, vmme_configuration ]}}
>>config: {get_attribute: [ SELF, vmme_configuration ]}
>>
>> Regards,
>> Vaishali.
>>
>> -Original Message-
>> From: Tal Liron [mailto:t...@cloudify.co]
>> Sent: Tuesday, December 05, 2017 2:06 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: get_attribute function not supporting SELF as
>> 
>>
>> Thanks for the report. Do you possibly have a minimal TOSCA template we
>> can
>> use to reproduce the error?
>>
>> On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
>> v.krishnamurt...@globallogic.com.invalid> wrote:
>>
>> > Hi,
>> >
>> > We have observed the attribute resolution is not proper when we use
>> > SELF as  in  get_attribute function and it
>> > works fine when we use the node name as  .
>> > With SELF it takes the default value. Could you confirm if there is any
>> > fix for this issue ?
>> >
>> >
>> > Regards,
>> >
>> > Vaishali
>> >
>>
>
>

Re: get_attribute function not supporting SELF as

[Tal Liron]

There is a bug here, but it has nothing to do with SELF.

The issue is that you are using an "ad hoc", typeless input here for the
"configure" operation. Because it's typeless, ARIA sends it "as is" and
thus has no idea that what's inside might be a syntactical intrinsic
function.

I will open a big for this, but for now the workaround is to explicitly
declare the input at the type, which I think is generally a good idea. (And
actually, I would rather ARIA not allow the current typeless input
situation.)

Here's how it would look:

tosca_definitions_version: tosca_simple_yaml_1_0

data_types:

  Payload:
properties:
  config:
type: string

node_types:

  my_Node_Server:
derived_from: tosca.nodes.Root
attributes:
  vmme_configuration:
type: string
default: test default value
interfaces:
  Standard:
type: tosca.interfaces.node.lifecycle.Standard
create:
  implementation: sample.sample_test.call_test
  inputs: {}
configure:
  implementation: sample.sample_test.call_name
  inputs:
payload:
  type: Payload

topology_template:

   node_templates:
 v_mme:
   type: my_Node_Server
   interfaces:
 Standard:
   configure:
 inputs:
   payload:
 config: {get_attribute: [ SELF, vmme_configuration ]}
   config: {get_attribute: [ SELF, vmme_configuration ]}





On Tue, Dec 5, 2017 at 10:58 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Here, I have used the get_attribute in the input defined in the second
> level, for which it returns me the dictionary object.
> inputs:
>   payload: {
> "config": {get_attribute: [ SELF, vmme_configuration ]}}
>
> When I use the get_attribute in inputs defined in the first level it
> returns
> me none.
> inputs:
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
> Please find the service template below.
> node_types:
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
> interfaces:
>   Standard:
> create:
>   implementation: sample > sample.sample_test.call_test
>   inputs: {}
> configure:
>   implementation: sample > sample.sample_test.call_name
>   inputs: {}
>
> topology_template:
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>configure:
>  inputs:
>payload: {
>  "config": {get_attribute: [ SELF, vmme_configuration ]}}
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
> Regards,
> Vaishali.
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 2:06 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> Thanks for the report. Do you possibly have a minimal TOSCA template we can
> use to reproduce the error?
>
> On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > Hi,
> >
> > We have observed the attribute resolution is not proper when we use
> > SELF as  in  get_attribute function and it
> > works fine when we use the node name as  .
> > With SELF it takes the default value. Could you confirm if there is any
> > fix for this issue ?
> >
> >
> > Regards,
> >
> > Vaishali
> >
>

Re: get_attribute function not supporting SELF as

[Tal Liron]

Thanks for the report. Do you possibly have a minimal TOSCA template we can
use to reproduce the error?

On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Hi,
>
> We have observed the attribute resolution is not proper when we use SELF as
>  in  get_attribute function and it works fine when
> we use the node name as  .  With SELF it takes the
> default value. Could you confirm if there is any fix for this issue ?
>
>
> Regards,
>
> Vaishali
>

Re: ARIA-118 plugin.yaml importing

[Tal Liron]

Sorry, but I don't think we did a thorough review yet. However, feel free
to rebase on master and push it again to ensure that the CI tests pass.

On Mon, Dec 4, 2017 at 2:48 PM, Thomas Nadeau  wrote:

> BTW I noticed that the Travis CI failed for your PR earlier. Tal and I
> discussed and he thinks this might be fixed with a rebase now that ARIA-1
> has been pushed.  You can test this theory for yourself by rebasing your
> branch.
>
> --Tom
>
>
> On Mon, Dec 4, 2017 at 12:31 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Thanks Thomas, I made the PR now.
> >
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnad...@apache.org]
> > Sent: Monday, December 04, 2017 1:07 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: ARIA-118 plugin.yaml importing
> >
> > Nothing has changed for non-committers; use the canonical GitHub
> fork->push
> > patches->propose patch request method
> > on the same two GitHub repos:
> >
> > https://github.com/apache/incubator-ariatosca-website
> >
> > and
> >
> > https://github.com/apache/incubator-ariatosca
> >
> > I’ll be on slack from now too if you need additional help.
> >
> > —Tom
> >
> >
> > On Dec 4, 2017, at 8:28 AM, D Jayachandran 
> > wrote:
> >
> > Hi,
> >
> > I need to contribute for this JIRA item. Previously I had made my
> > contribution by forking from the apache-ariatosca project.
> > Is the process changed now ? What is the process which I should follow
> now
> > ?
> >
> >
> > Regards,
> > DJ
> >
>

Re: Transition to Gitbox Complete

[Tal Liron]

It's semantics, John. Recommending one mechanism but not the other means
that the other mechanism is less recommended or, in other words,
discouraged. This might be a mild discouragement, but it is so. The impact
of this mild discouragement would be that our potential devs will likely be
using https.

Anyway, if you know what you're doing, use whatever is easiest and best for
you.

On Sun, Dec 3, 2017 at 5:23 PM, John D. Ament  wrote:

> On Sun, Dec 3, 2017 at 10:11 AM Thomas Nadeau 
> wrote:
>
> > That still uses SSH, which then uses your pre-configured keys.  Github
> docs
> > discourage this use for some reason.
> >
>
> Err no, github docs "recommend" using HTTPS, they don't discourage the use
> of SSH.
>
> https://stackoverflow.com/questions/11041729/why-does-
> github-recommend-https-over-ssh
> provides
> some info about why HTTPS is the current recommendation.
>
>
> >
> > --Tom
> >
> > On Sun, Dec 3, 2017 at 4:54 PM, John D. Ament 
> > wrote:
> >
> > > Any reason you wouldn't just use the github direct URLs?
> > >
> > > g...@github.com:apache/incubator-ariatosca.git
> > > g...@github.com:apache/incubator-ariatosca-website.git
> > >
> > >
> > >
> > > On Sun, Dec 3, 2017 at 4:45 AM Thomas Nadeau 
> > > wrote:
> > >
> > > > The gitbox transition appears to have completed - thanks for setting
> > this
> > > > up Suneel.
> > > >
> > > > Committers please follow the instructions Suneel provided on Slack
> > > earlier
> > > > to synch your apache account with github so permissions work/etc...
> > > >
> > > > --Tom
> > > >
> > > >
> > > > From slack:
> > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=incubator-ariatosca.git;a=summary
> > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=incubator-ariatosca-website.git;a=
> > > summary
> > > >
> > > > Moved to both repos Gitbox.  You'll need to have your committers link
> > > their
> > > > Github IDs on id.apache.org and enable two factor authentication
> here:
> > > > https://gitbox.apache.org/setup/  This process can take up to 2
> hours
> > > for
> > > > Gitbox to see.
> > > >
> > >
> >
>

Re: Transition to Gitbox Complete

[Tal Liron]

You *could* use those -- they are ssh with ssh keys. However, GitHub
generally recommends using HTTPS.

On Sun, Dec 3, 2017 at 4:54 PM, John D. Ament  wrote:

> Any reason you wouldn't just use the github direct URLs?
>
> g...@github.com:apache/incubator-ariatosca.git
> g...@github.com:apache/incubator-ariatosca-website.git
>
>
>
> On Sun, Dec 3, 2017 at 4:45 AM Thomas Nadeau 
> wrote:
>
> > The gitbox transition appears to have completed - thanks for setting this
> > up Suneel.
> >
> > Committers please follow the instructions Suneel provided on Slack
> earlier
> > to synch your apache account with github so permissions work/etc...
> >
> > --Tom
> >
> >
> > From slack:
> >
> > https://gitbox.apache.org/repos/asf?p=incubator-ariatosca.git;a=summary
> >
> > https://gitbox.apache.org/repos/asf?p=incubator-ariatosca-website.git;a=
> summary
> >
> > Moved to both repos Gitbox.  You'll need to have your committers link
> their
> > Github IDs on id.apache.org and enable two factor authentication here:
> > https://gitbox.apache.org/setup/  This process can take up to 2 hours
> for
> > Gitbox to see.
> >
>

Re: pip executable expected as part of plugin install.

[Tal Liron]

Hi DJ,

A lot has changed since August. :) I wonder if you can take a look at the
current state of master and see if things have improved with wagon installs?

On Fri, Dec 1, 2017 at 9:22 AM, D Jayachandran 
wrote:

> Hi Ran,
>
> Sorry I had missed to answer this thread. Just to answer your question
> wagon also expects pip as a binary "/usr/bin/pip".  The above path may not
> be the same for al distros of linux and when the path varies we run into
> the issue/
> As I already told we could probably fix this issue by using pip as library
> instead of a 3PP.
> Please let me know if we can also apply the same fix with wagon as well.
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Sunday, August 20, 2017 12:40 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: pip executable expected as part of plugin install.
>
> Can you try to explain again what's the issue you're seeing with the way
> Wagon works right now?
> We could create a pull request for Wagon as well, but I'm not sure I
> understand the problem at the moment.
>
> On Wed, Aug 16, 2017 at 6:04 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Even if we fix the issue in ARIA. Wagon library still uses the same
> > logic in finding the pip path and it is wrong.
> > Am not sure how to fix this with wagon.
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > Sent: Thursday, August 03, 2017 5:00 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: pip executable expected as part of plugin install.
> >
> > Thanks Avia, I will open an issue.
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Avia Efrat [mailto:a...@cloudify.co]
> > Sent: Thursday, August 03, 2017 4:01 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: pip executable expected as part of plugin install.
> >
> > 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 <
> > d.jayachand...@ericsson.com
> > > 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
> > >
> >
>

Re: Support for extension point during service execution

[Tal Liron]

It seems we have duplicated efforts here. DeWayne has separately created a
REST layer for the ONAP project.

DeWayne, could you provide more details?

On Wed, Nov 29, 2017 at 11:59 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Tal,
>
> For our use case we have already built a REST Layer on top of ARIA for
> service-template, services and execution creation/start.
> Now for this particular use-case we were looking if we could take the
> service model object and create a service context object out of it, to be
> provided to the service level plugin.
> I was thinking if we had to do this, can this be included as part of ARIA
> (Atleast creation of service context object)
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 29, 2017 1:46 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> We half do. :) Actually, this has become a major topic of discussion
> recently on other lists. There's some room to discuss exactly what and how
> is available to the ctx proxy. Right now it's both too unrestricted and too
> narrow. The current idea is to make the exposure more explicit, and
> possibly align it with a more general REST API.
>
> On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Tal,
> >
> > I agree with your points mentioned below but I was thinking do we need
> > to have a ServiceLevel operation context, as we now have Node
> > operation context.
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Friday, November 24, 2017 10:12 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Support for extension point during service execution
> >
> > Hi DJ,
> >
> > The question here is why use ARIA's orchestrator at all? It sounds
> > like you have your own orchestration engine. This is an intended use
> > case for ARIA (and indeed was used in the OPEN-O project).
> >
> > There are a few ways to use ARIA here:
> >
> > 1) You can use the ARIA's Python API and access all the data models
> > directly. Of course this will only work if your own orchestration code
> > is in Python.
> > 2) You can use ARIA's CLI to emit the data models you need in either
> > JSON or YAML format, for easy consumption by your code: aria services
> > show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP
> service.
> > 3) You can access the database directly. ARIA uses a a normalized
> > relational (SQL) database.
> >
> > There are some challenges and limitations to each approach. If you
> > tell us what you're going to do we can help you move along in that
> direction.
> >
> >
> > On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Team,
> > >
> > > We are looking at an execution point during a service execution
> > > through a plugin. With this the execution will not go through the
> > > workflow runner
> > > (install/uninstall) defined by the orchestrator but the services
> > > instance context object will be provided to the plugin which will
> > > take care of the complete service-execution.
> > > This plugin is looked upon as a "service plugin" which will get the
> > > entire service model object and will provide the details to the
> > > external workflow engine.
> > > We need this feature to enable the execution of workflows which some
> > > of our users already have. Please let us know your thoughts on this
> > > as we have already started our technical study on this.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

Re: problem using cloudify extension with dev branch

[Tal Liron]

Ah, the dreaded multi-repo problems that I so detest, and am trying to
avoid by having it all in one repo...

The issue is that you are using a newer version of aria-extension-cloudify
than what is supported by aria on PyPI. I suggest keeping the two versions
matching to avoid problems.

On Wed, Nov 29, 2017 at 5:03 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> I worked around this by installing the cloudify extention using the
> --no-deps argument (to pip).
>
> On Wed, Nov 29, 2017 at 2:32 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > OK.  I guess I didn't provide enough context.  I installed the ARIA-1
> > branch of ARIA in order to pick up a bug fix I needed.  When attempting
> to
> > install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
> > installed, and it proceeds to remove it.  So, the cloudify extension
> > deletes ARIA, apparently because it's looking for a different version of
> > it.  The full message:
> >
> > Installing collected packages: apache-ariatosca, aria-extension-cloudify
> > Found existing installation: apache-ariatosca 0.2.0
> > Uninstalling apache-ariatosca-0.2.0:
> > Successfully uninstalled apache-ariatosca-0.2.0
> > Running setup.py develop for apache-ariatosca
> > Complete output from command /home/vagrant/venv/bin/python -c "import
> > setuptools, tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read().replace('\r\n',
> > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
> > running develop
> > Checking .pth file support in /home/vagrant/.aria/plugins/
> > aria-extension-cloudify-4.1/lib/python2.7/site-packages
> > /home/vagrant/venv/bin/python -E -c pass
> > TEST FAILED: /home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/
> lib/python2.7/site-packages
> > does NOT support .pth files
> > error: bad install directory or PYTHONPATH
> > Command "/home/vagrant/venv/bin/python -c "import setuptools,
> > tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read().replace('\r\n',
> > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> > with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
> > Could not install package: aria-extension-cloudify (Command
> > "/home/vagrant/venv/bin/python -c "import setuptools,
> > tokenize;__file__='/home/vagrant/venv/src/apache-
> > ariatosca/setup.py';f=getattr(tokenize, 'open',
> > open)(__file__);code=f.read().replace('\r\n',
> > '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> > --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> > with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)
> >
> >
> > On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> >> Sorry, hard to understand exactly what you're trying to do, what's
> >> "failing" etc.
> >>
> >> All I can gather from this is that you are installing something that
> >> requires "apache-ariatosca" but that is already installed, so it's
> >> removing
> >> it in order to upgrade. You stopped the log there.
> >>
> >> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi <dewa...@cloudify.co>
> >> wrote:
> >>
> >> > I see the following when trying to install the cloudify extension with
> >> the
> >> > ARIA-1 branch:
> >> >
> >> > Installing collected packages: apache-ariatosca,
> aria-extension-cloudify
> >> > Found existing installation: apache-ariatosca 0.2.0
> >> > Uninstalling apache-ariatosca-0.2.0:
> >> >
> >> > Then it fails.
> >> >
> >>
> >
> >
>

Re: problem using cloudify extension with dev branch

[Tal Liron]

Sorry, hard to understand exactly what you're trying to do, what's
"failing" etc.

All I can gather from this is that you are installing something that
requires "apache-ariatosca" but that is already installed, so it's removing
it in order to upgrade. You stopped the log there.

On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi  wrote:

> I see the following when trying to install the cloudify extension with the
> ARIA-1 branch:
>
> Installing collected packages: apache-ariatosca, aria-extension-cloudify
> Found existing installation: apache-ariatosca 0.2.0
> Uninstalling apache-ariatosca-0.2.0:
>
> Then it fails.
>

Re: back to the future

[Tal Liron]

Absolutely. Let's also remember that TOSCA was first developed "on paper"
at first without any implementation. There wasn't even any way to validate
the examples other than by hand.

Things are better now that ARIA exists (and a few other TOSCA parsers), so
excuses are running out...

On Tue, Nov 28, 2017 at 1:48 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Yeah, well in a big spec like TOSCA, I tend to go for the examples rather
> than reading it cover to cover, which actually makes them more important
> than the spec in a practical sense.  But maybe that's just me.  On the
> other hand, it validates the raison d'etre of ARIA: to discover such issues
> with the spec and serve as a feedback mechanism.
>
> On Tue, Nov 28, 2017 at 11:02 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > OK, baseball reference. :)
> >
> > Well, it's always easy to criticize. :) If we want TOSCA to be better, we
> > need to better participate in the process. There is an open JIRA for ARIA
> > to consolidate all our errata into a single proposal for OASIS.
> >
> > On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > bush league == amateur hour
> > >
> > > On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > Sorry, I did not understand that last comment about "bush league"!
> > > >
> > > > But yes, the spec is known to be flimsy and self-contradictory. In
> the
> > > end,
> > > > we must make a choice on how to implement things in ARIA, while
> taking
> > > into
> > > > account that other TOSCA implementations might interpret the spec
> > > > differently. (Even more ideally: provide configuration options for
> > ARIA's
> > > > parser, so that it could better work with YAML files created for
> other
> > > > TOSCA implementations. We have a few of these configuration options
> > > > already.)
> > > >
> > > > This is exactly why the current PR for ARIA-1 is important: it
> > > introduces a
> > > > broad test suite for TOSCA syntax and grammar, which obviously
> follows
> > > the
> > > > interpretations we made for ARIA. But it can be run on other TOSCA
> > > parsers,
> > > > too, at least giving us information as to where other parsers differ
> in
> > > > their interpretations of the spec.
> > > >
> > > > I will say that our rules of thumb has generally been: 1) if a strict
> > and
> > > > loose interpretation are possible, choose the stricter one, and 2)
> keep
> > > the
> > > > "spirit of the spec" in mind: object-orientation and enforcement of
> the
> > > > parent type contract.
> > > >
> > > > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > wrote:
> > > >
> > > > > Wow.  That is reeeaaally bad and bush
> > > > league.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > "Examples" in the spec routinely break the syntax of the spec...
> I
> > > > think
> > > > > > it's best not to trust them.
> > > > > >
> > > > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <
> > > dewa...@cloudify.co>
> > > > > > wrote:
> > > > > >
> > > > > > > I suppose it lets you name interfaces whatever you want, which
> is
> > > > > > confusing
> > > > > > > because of other areas of the spec.  Note that there are tons
> of
> > > > > examples
> > > > > > > in the spec without the "type" specified.
> > > > > > >
> > > > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > I mentioned this to you in the previous thread: the "type"
> > field
> > > is
> > > > > > > > required for interface definitions according to TOSCA syntax.
> > So,
> > > > > even
> > > > > > if
> > > > > > > > it's the same as what you are inheriting, you must specify
> it.
> > > > > >

Re: Loading Custom Workflows from CSAR

[Tal Liron]

Thanks, Steve. We don't have a JIRA for this right now, but we do intend to
have a way to include "plugins" in a CSAR and have them automatically
installed. A "plugin" is basically a Python extension to ARIA that can be
loaded at runtime and contained per service.

This is part of our current general work trying to find a good design for
plugins generally, and will likely result in a JIRA epic with several
issues. At this time, I don't think it's worth created this epic if we
don't have a plan.

The design will likely be inspired by the plugin design in Cloudify, from
which we grabbed our seed code. However, there is room for some
re-imagination especially as pertains TOSCA-specific issues.

On Tue, Nov 28, 2017 at 1:01 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

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

Re: back to the future

[Tal Liron]

OK, baseball reference. :)

Well, it's always easy to criticize. :) If we want TOSCA to be better, we
need to better participate in the process. There is an open JIRA for ARIA
to consolidate all our errata into a single proposal for OASIS.

On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> bush league == amateur hour
>
> On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > Sorry, I did not understand that last comment about "bush league"!
> >
> > But yes, the spec is known to be flimsy and self-contradictory. In the
> end,
> > we must make a choice on how to implement things in ARIA, while taking
> into
> > account that other TOSCA implementations might interpret the spec
> > differently. (Even more ideally: provide configuration options for ARIA's
> > parser, so that it could better work with YAML files created for other
> > TOSCA implementations. We have a few of these configuration options
> > already.)
> >
> > This is exactly why the current PR for ARIA-1 is important: it
> introduces a
> > broad test suite for TOSCA syntax and grammar, which obviously follows
> the
> > interpretations we made for ARIA. But it can be run on other TOSCA
> parsers,
> > too, at least giving us information as to where other parsers differ in
> > their interpretations of the spec.
> >
> > I will say that our rules of thumb has generally been: 1) if a strict and
> > loose interpretation are possible, choose the stricter one, and 2) keep
> the
> > "spirit of the spec" in mind: object-orientation and enforcement of the
> > parent type contract.
> >
> > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Wow.  That is reeeaaally bad and bush
> > league.
> > >
> > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > "Examples" in the spec routinely break the syntax of the spec... I
> > think
> > > > it's best not to trust them.
> > > >
> > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > wrote:
> > > >
> > > > > I suppose it lets you name interfaces whatever you want, which is
> > > > confusing
> > > > > because of other areas of the spec.  Note that there are tons of
> > > examples
> > > > > in the spec without the "type" specified.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > I mentioned this to you in the previous thread: the "type" field
> is
> > > > > > required for interface definitions according to TOSCA syntax. So,
> > > even
> > > > if
> > > > > > it's the same as what you are inheriting, you must specify it.
> > > > > >
> > > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > > dewa...@cloudify.co>
> > > > > > wrote:
> > > > > >
> > > > > > > Now that the 'subclassing' problem has been resolved,
> overriding
> > > > > > interface
> > > > > > > methods is breaking.  Simple example:
> > > > > > >
> > > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > >
> > > > > > > imports:
> > > > > > >
> > > > > > >   - aria-1.0
> > > > > > >
> > > > > > > node_types:
> > > > > > >
> > > > > > >   T1:
> > > > > > > derived_from: tosca.nodes.Root
> > > > > > > interfaces:
> > > > > > >   Standard:
> > > > > > > create:
> > > > > > >   implementation:
> > > > > > > primary: i1.sh
> > > > > > > delete:
> > > > > > >   implementation:
> > > > > > > primary: i1.sh
> > > > > > >
> > > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > > >
> > > > > > > Validation issues:
> > > > > > >   2: required field "type" in
> > > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> > InterfaceDefinition"
> > > > > does
> > > > > > > not
> > > > > > > have a value
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: back to the future

[Tal Liron]

Sorry, I did not understand that last comment about "bush league"!

But yes, the spec is known to be flimsy and self-contradictory. In the end,
we must make a choice on how to implement things in ARIA, while taking into
account that other TOSCA implementations might interpret the spec
differently. (Even more ideally: provide configuration options for ARIA's
parser, so that it could better work with YAML files created for other
TOSCA implementations. We have a few of these configuration options
already.)

This is exactly why the current PR for ARIA-1 is important: it introduces a
broad test suite for TOSCA syntax and grammar, which obviously follows the
interpretations we made for ARIA. But it can be run on other TOSCA parsers,
too, at least giving us information as to where other parsers differ in
their interpretations of the spec.

I will say that our rules of thumb has generally been: 1) if a strict and
loose interpretation are possible, choose the stricter one, and 2) keep the
"spirit of the spec" in mind: object-orientation and enforcement of the
parent type contract.

On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <dewa...@cloudify.co>
wrote:

> Wow.  That is reeeaaally bad and bush league.
>
> On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > "Examples" in the spec routinely break the syntax of the spec... I think
> > it's best not to trust them.
> >
> > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > I suppose it lets you name interfaces whatever you want, which is
> > confusing
> > > because of other areas of the spec.  Note that there are tons of
> examples
> > > in the spec without the "type" specified.
> > >
> > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > I mentioned this to you in the previous thread: the "type" field is
> > > > required for interface definitions according to TOSCA syntax. So,
> even
> > if
> > > > it's the same as what you are inheriting, you must specify it.
> > > >
> > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > wrote:
> > > >
> > > > > Now that the 'subclassing' problem has been resolved,  overriding
> > > > interface
> > > > > methods is breaking.  Simple example:
> > > > >
> > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > >
> > > > > imports:
> > > > >
> > > > >   - aria-1.0
> > > > >
> > > > > node_types:
> > > > >
> > > > >   T1:
> > > > > derived_from: tosca.nodes.Root
> > > > > interfaces:
> > > > >   Standard:
> > > > > create:
> > > > >   implementation:
> > > > > primary: i1.sh
> > > > > delete:
> > > > >   implementation:
> > > > > primary: i1.sh
> > > > >
> > > > > The error, using Aria in the ARIA-1 branch:
> > > > >
> > > > > Validation issues:
> > > > >   2: required field "type" in
> > > > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> > > does
> > > > > not
> > > > > have a value
> > > > >
> > > >
> > >
> >
>

Re: back to the future

[Tal Liron]

"Examples" in the spec routinely break the syntax of the spec... I think
it's best not to trust them.

On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <dewa...@cloudify.co>
wrote:

> I suppose it lets you name interfaces whatever you want, which is confusing
> because of other areas of the spec.  Note that there are tons of examples
> in the spec without the "type" specified.
>
> On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > I mentioned this to you in the previous thread: the "type" field is
> > required for interface definitions according to TOSCA syntax. So, even if
> > it's the same as what you are inheriting, you must specify it.
> >
> > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Now that the 'subclassing' problem has been resolved,  overriding
> > interface
> > > methods is breaking.  Simple example:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > imports:
> > >
> > >   - aria-1.0
> > >
> > > node_types:
> > >
> > >   T1:
> > > derived_from: tosca.nodes.Root
> > > interfaces:
> > >   Standard:
> > > create:
> > >   implementation:
> > > primary: i1.sh
> > > delete:
> > >   implementation:
> > > primary: i1.sh
> > >
> > > The error, using Aria in the ARIA-1 branch:
> > >
> > > Validation issues:
> > >   2: required field "type" in
> > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> does
> > > not
> > > have a value
> > >
> >
>

Re: back to the future

[Tal Liron]

I agree that ideally it could be inherited from the parent node type if not
specified. That would indeed be my opinion.

Small quibble: the fact that it's called "Standard" is arbitrary. The
interface name does *not* have to conform to the interface type, it's just
what they decided for the normative Root node type. The name does *not*
contain type information. For example, in your own node type you can
override the interface named "Standard" to be of a different interface
type, which does not have "Standard" in its name. (ARIA will insist that
your overriding type inherits from the Standard node type -- see our other
discussion about type inheritance.)

On Tue, Nov 28, 2017 at 12:32 PM, DeWayne Filppi <dewa...@cloudify.co>
wrote:

> Seems rather ugly.  Do you have an opinion?  If I specify that I'm using
> the Standard interface, what point is there in the "type" field?
>
> On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > I mentioned this to you in the previous thread: the "type" field is
> > required for interface definitions according to TOSCA syntax. So, even if
> > it's the same as what you are inheriting, you must specify it.
> >
> > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Now that the 'subclassing' problem has been resolved,  overriding
> > interface
> > > methods is breaking.  Simple example:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > imports:
> > >
> > >   - aria-1.0
> > >
> > > node_types:
> > >
> > >   T1:
> > > derived_from: tosca.nodes.Root
> > > interfaces:
> > >   Standard:
> > > create:
> > >   implementation:
> > > primary: i1.sh
> > > delete:
> > >   implementation:
> > > primary: i1.sh
> > >
> > > The error, using Aria in the ARIA-1 branch:
> > >
> > > Validation issues:
> > >   2: required field "type" in
> > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> does
> > > not
> > > have a value
> > >
> >
>

Re: back to the future

[Tal Liron]

I mentioned this to you in the previous thread: the "type" field is
required for interface definitions according to TOSCA syntax. So, even if
it's the same as what you are inheriting, you must specify it.

On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi 
wrote:

> Now that the 'subclassing' problem has been resolved,  overriding interface
> methods is breaking.  Simple example:
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
>
>   - aria-1.0
>
> node_types:
>
>   T1:
> derived_from: tosca.nodes.Root
> interfaces:
>   Standard:
> create:
>   implementation:
> primary: i1.sh
> delete:
>   implementation:
> primary: i1.sh
>
> The error, using Aria in the ARIA-1 branch:
>
> Validation issues:
>   2: required field "type" in
> "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does
> not
> have a value
>

Re: TOSCA type inheritance question

[Tal Liron]

This is a big that is fixed in the ARIA-1 commit, which is waiting to be
merged.

If you don't mind helping to test, could you try with this branch?
https://github.com/apache/incubator-ariatosca/tree/ARIA-1-parser-test-suite

On Tue, Nov 28, 2017 at 11:13 AM, DeWayne Filppi <dewa...@cloudify.co>
wrote:

> I made a simple example that fails.  Maybe my example is a
> misinterpretation of what you said:
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
>
>   - aria-1.0
>
> data_types:
>
>   d1:
> properties:
>   p1:
> type: string
>
>   d2:
> derived_from: d1
> properties:
>   p2:
> type: string
>
> node_types:
>
>   T1:
> derived_from: tosca.nodes.Root
> properties:
>   n1:
> type: d1
>
>
>   T2:
> derived_from: T1
> properties:
>   n1:
> type: d2
>
>
> This produces the error:
>
>   4: override changes type from "d1" to "d2" for property "n1" in "T2
>
> On Tue, Nov 28, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > You are correct that it's not entirely clear from the spec. However, I
> > always interpret the spirit of the spec to be object-oriented. That means
> > that in ARIA: yes, you can override a property, AS LONG AS the property
> > type is of compatible with (equal or derived from) the one in the parent.
> > ARIA will check for this and issue a validation error if you break the
> > parent's contract.
> >
> > On Tue, Nov 28, 2017 at 10:56 AM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > If there is a node type that inherits from another node type, can a
> > > property in the parent be overridden by the subtype?  I'm having
> trouble
> > > getting a straight answer to that basic question from the spec.
> > >
> > > DeWayne
> > >
> >
>

Re: TOSCA type inheritance question

[Tal Liron]

You are correct that it's not entirely clear from the spec. However, I
always interpret the spirit of the spec to be object-oriented. That means
that in ARIA: yes, you can override a property, AS LONG AS the property
type is of compatible with (equal or derived from) the one in the parent.
ARIA will check for this and issue a validation error if you break the
parent's contract.

On Tue, Nov 28, 2017 at 10:56 AM, DeWayne Filppi 
wrote:

> If there is a node type that inherits from another node type, can a
> property in the parent be overridden by the subtype?  I'm having trouble
> getting a straight answer to that basic question from the spec.
>
> DeWayne
>

Re: ARIA-354 Verified

[Tal Liron]

In your case, I would replace the "pip install" line with this one:

make install-virtual

This will install your checked-out git repo in development mode into the
virtual environment, meaning that any code changes you make will
immediately be reflected. This is how we pro devs work. :)

On Mon, Nov 27, 2017 at 8:06 PM, Miguel Angel Jimenez Achinte <
mig...@rigiresearch.com> wrote:

> I'm sorry if that was confusing. I checked out the 0.1.1 tag because the
> working blueprint is there.
> To install ARIA, I used pip.
>
> Just to make sure everything is clear, these are the steps I executed:
>
> sudo pip install virtualenv
> virtualenv tosca-environment
> source tosca-environment/bin/activate
> pip install apache-ariatosca[ssh]
> git clone https://github.com/apache/incubator-ariatosca.git
> cd incubator-ariatosca
> git checkout tags/0.1.1
> aria service-templates store examples/hello-world/helloworld.yaml
> my-service-template
> aria services create my-service -t my-service-template
> aria executions start install -s my-service
> curl http://localhost:9090
>
> 
> 
> ARIA Hello World
> 
> 
> Hello, World!
> 
> blueprint_id = my-service-template3
> deployment_id = my-service2
> node_id = web_app_1
> 
> 
> 
> 
>
> --
> 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 27, 2017 at 5:53 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > I'm confused, Miguel. You checked out the git repository, but then
> > installed ARIA from the PyPI (using pip). I would recommend not mixing
> the
> > two methods, because indeed if the git repo is at master's tip, then it
> > would not much what was last released to PyPI. You found a workaround
> here,
> > using tags, but I wouldn't recommend this generally.
> >
> > If you use the git repo, just running "make install" should do what you
> > need.
> >
> > On Mon, Nov 27, 2017 at 7:48 PM, Miguel Angel Jimenez Achinte <
> > mig...@rigiresearch.com> wrote:
> >
> > > Okay, it's working now.
> > > I needed to check out the tag 0.1.1. The complete list of commands is:
> > >
> > > sudo pip install --upgrade setuptools
> > > sudo pip install apache-ariatosca[ssh]
> > > ...
> > > aria --version
> > > v0.1.1
> > > ...
> > > git clone https://github.com/apache/incubator-ariatosca; cd
> > > incubator-ariatosca
> > > git checkout tags/0.1.1
> > > aria service-templates store examples/hello-world/helloworld.yaml
> > > my-service-template
> > >
> > > Notice that in tag 0.1.1, the blueprint's name is helloworld.yaml,
> > without
> > > the hyphen.
> > >
> > >
> > > --
> > > 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 27, 2017 at 3:28 PM, Vishwanath Jayaraman <
> > > vishwana...@hotmail.com> wrote:
> > >
> > > > Ok, got it.
> > > >
> > > >
> > > > Vish
> > > >
> > > >
> > > > 
> > > > From: Tal Liron <t...@cloudify.co>
> > > > Sent: Monday, November 27, 2017 5:19 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: ARIA-354 Verified
> > > >
> > > > Vish, I'm pretty sure the version suffix is not required, because
> 0.1.1
> > > is
> > > > the highest version.
> > > >
> > > > On Mon, Nov 27, 2017 at 5:08 PM, Vishwanath Jayaraman <
> > > > vishwana...@hotmail.com> wrote:
> > > >
> > > > >
> > > > > You need to execute
> > > > >
> > > > > pip install apache-ariatosca[ssh]==0.1.1
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > On Nov 27, 2017, at 4:49 PM, Miguel Angel Jimenez Achinte <
> > > > > mig...@rigiresearch.com<mailto:mig...@rigiresearch.com>> wrote:
> > > > >
> > > > > I executed: pip install apache-ariatosca[ssh]
> > > > > Should I use "pip install apache-ariatosca[ssh]==0.1.1 --no-binary
> > > > > apache-

Re: ARIA-354 Verified

[Tal Liron]

I'm confused, Miguel. You checked out the git repository, but then
installed ARIA from the PyPI (using pip). I would recommend not mixing the
two methods, because indeed if the git repo is at master's tip, then it
would not much what was last released to PyPI. You found a workaround here,
using tags, but I wouldn't recommend this generally.

If you use the git repo, just running "make install" should do what you
need.

On Mon, Nov 27, 2017 at 7:48 PM, Miguel Angel Jimenez Achinte <
mig...@rigiresearch.com> wrote:

> Okay, it's working now.
> I needed to check out the tag 0.1.1. The complete list of commands is:
>
> sudo pip install --upgrade setuptools
> sudo pip install apache-ariatosca[ssh]
> ...
> aria --version
> v0.1.1
> ...
> git clone https://github.com/apache/incubator-ariatosca; cd
> incubator-ariatosca
> git checkout tags/0.1.1
> aria service-templates store examples/hello-world/helloworld.yaml
> my-service-template
>
> Notice that in tag 0.1.1, the blueprint's name is helloworld.yaml, without
> the hyphen.
>
>
> --
> 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 27, 2017 at 3:28 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > Ok, got it.
> >
> >
> > Vish
> >
> >
> > 
> > From: Tal Liron <t...@cloudify.co>
> > Sent: Monday, November 27, 2017 5:19 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: ARIA-354 Verified
> >
> > Vish, I'm pretty sure the version suffix is not required, because 0.1.1
> is
> > the highest version.
> >
> > On Mon, Nov 27, 2017 at 5:08 PM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> > >
> > > You need to execute
> > >
> > > pip install apache-ariatosca[ssh]==0.1.1
> > >
> > > Sent from my iPhone
> > >
> > > On Nov 27, 2017, at 4:49 PM, Miguel Angel Jimenez Achinte <
> > > mig...@rigiresearch.com<mailto:mig...@rigiresearch.com>> wrote:
> > >
> > > I executed: pip install apache-ariatosca[ssh]
> > > Should I use "pip install apache-ariatosca[ssh]==0.1.1 --no-binary
> > > apache-ariatosca" instead?
> > >
> > >
> > > --
> > > 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 27, 2017 at 2:47 PM, Tal Liron <t...@cloudify.co tal@
> > > cloudify.co>> wrote:
> > >
> > > Miguel, how did you install ARIA?
> > >
> > > On Mon, Nov 27, 2017 at 4:44 PM, Miguel Angel Jimenez Achinte <
> > > mig...@rigiresearch.com<mailto:mig...@rigiresearch.com>> wrote:
> > >
> > > I just installed ARIA on Centos 7 and I get the same error:
> > >
> > > Storing service template my-service-template...
> > >
> > > *AttributeError*: 'NoneType' object has no attribute '_get_properties'
> > >
> > >  File "/usr/lib/python2.7/site-packages/aria/parser/
> > > consumption/consumer.py",
> > > line 70, in consume
> > >
> > >consumer.consume()
> > >
> > >  File "
> > > /usr/lib/python2.7/site-packages/aria/parser/
> consumption/validation.py",
> > > line 30, in consume
> > >
> > >self.context.presentation.presenter._validate(self.context)
> > >
> > >  File "
> > > /usr/lib/python2.7/site-packages/aria_extension_tosca/
> > > simple_v1_0/presenter.py",
> > > line 65, in _validate
> > >
> > >self.service_template._validate(context)
> > >
> > >  File "
> > > /usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/presentation.py",
> > > line 193, in _validate
> > >
> > >validate_known_fields(context, self)
> > >
> > >  File "/usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/utils.py",
> > > line 110, in validate_known_fields
> > >
> > >field.validate(presentation, context)
> > >
> > >  File "/usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/fields.py",
> > > line 409, in validate
> > >
>

Re: simple validation error

[Tal Liron]

It is a bug. I created this issue:
https://issues.apache.org/jira/browse/ARIA-411

For now, the workaround is to add a "primary" key under "implementation".

Also note that you must supply the "type" field for the interface
definition. So:

  T1:
derived_from: tosca.nodes.Root
interfaces:
  Standard:
type: tosca.interfaces.node.lifecycle.Standard
create:
  implementation:
primary: i1.sh

On Mon, Nov 27, 2017 at 5:28 PM, DeWayne Filppi  wrote:

> This should validate, no?
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
>
>   - aria-1.0
>
>
> node_types:
>
>   T1:
> derived_from: tosca.nodes.Root
> interfaces:
>   Standard:
> create:
>   implementation: i1.sh
>
>   T2:
> derived_from: T1
> interfaces:
>   Standard:
> create:
>   implementation: i1.sh
>
>
> The content of 'i1.sh' doesn't matter.  The error is (Aria 0.1.1):
>
> AttributeError: 'LocatableString' object has no attribute 'iteritems'
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/consumption/consumer.py",
> line 70, in consume
> consumer.consume()
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/consumption/validation.py",
> line 30, in consume
> self.context.presentation.presenter._validate(self.context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/presenter.py",
> line 65, in _validate
> self.service_template._validate(context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/
> presentation.py",
> line 193, in _validate
> validate_known_fields(context, self)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/utils.py",
> line 110, in validate_known_fields
> field.validate(presentation, context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/fields.py",
> line 409, in validate
> self.default_validate(presentation, context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/fields.py",
> line 524, in default_validate
> self.validate_value(value, context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/fields.py",
> line 540, in validate_value
> inner_value._validate(context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/types.py",
> line 655, in _validate
> self._get_interfaces(context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/utils/caching.py",
> line 84, in __call__
> return_value = self.func(*args, **kwargs)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/types.py",
> line 643, in _get_interfaces
> return FrozenDict(get_inherited_interface_definitions(context, self,
> 'node type'))
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 127, in get_inherited_interface_definitions
> for_presentation=for_presentation)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 435, in merge_interface_definitions
> 'definition')
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 425, in merge_interface_definition
> presentation, type_name)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 392, in merge_raw_operation_definitions
> presentation, type_name)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 364, in merge_raw_operation_definition
> deepcopy_with_locators(our_operation._raw['implementation']))
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> utils/collections.py",
> line 232, in merge
> for key, value_b in dict_b.iteritems():
> Validation issues:
>   0: 'LocatableString' object has no attribute 'iteritems'
>  AttributeError: 'LocatableString' object has no attribute 'iteritems'
>

Re: ARIA-354 Verified

[Tal Liron]

Vish, I'm pretty sure the version suffix is not required, because 0.1.1 is
the highest version.

On Mon, Nov 27, 2017 at 5:08 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

>
> You need to execute
>
> pip install apache-ariatosca[ssh]==0.1.1
>
> Sent from my iPhone
>
> On Nov 27, 2017, at 4:49 PM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com<mailto:mig...@rigiresearch.com>> wrote:
>
> I executed: pip install apache-ariatosca[ssh]
> Should I use "pip install apache-ariatosca[ssh]==0.1.1 --no-binary
> apache-ariatosca" instead?
>
>
> --
> 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 27, 2017 at 2:47 PM, Tal Liron <t...@cloudify.co<mailto:tal@
> cloudify.co>> wrote:
>
> Miguel, how did you install ARIA?
>
> On Mon, Nov 27, 2017 at 4:44 PM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com<mailto:mig...@rigiresearch.com>> wrote:
>
> I just installed ARIA on Centos 7 and I get the same error:
>
> Storing service template my-service-template...
>
> *AttributeError*: 'NoneType' object has no attribute '_get_properties'
>
>  File "/usr/lib/python2.7/site-packages/aria/parser/
> consumption/consumer.py",
> line 70, in consume
>
>consumer.consume()
>
>  File "
> /usr/lib/python2.7/site-packages/aria/parser/consumption/validation.py",
> line 30, in consume
>
>self.context.presentation.presenter._validate(self.context)
>
>  File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/presenter.py",
> line 65, in _validate
>
>self.service_template._validate(context)
>
>  File "
> /usr/lib/python2.7/site-packages/aria/parser/
> presentation/presentation.py",
> line 193, in _validate
>
>validate_known_fields(context, self)
>
>  File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/utils.py",
> line 110, in validate_known_fields
>
>field.validate(presentation, context)
>
>  File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/fields.py",
> line 409, in validate
>
>self.default_validate(presentation, context)
>
>  File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/fields.py",
> line 524, in default_validate
>
>self.validate_value(value, context)
>
>  File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/fields.py",
> line 540, in validate_value
>
>inner_value._validate(context)
>
>  File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/types.py",
> line 654, in _validate
>
>self._get_capabilities(context)
>
>  File "/usr/lib/python2.7/site-packages/aria/utils/caching.py", line
> 84,
> in __call__
>
>return_value = self.func(*args, **kwargs)
>
>  File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/types.py",
> line 639, in _get_capabilities
>
>return FrozenDict(get_inherited_capability_definitions(context,
> self))
>
>  File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/modeling/capabilities.py",
> line 90, in get_inherited_capability_definitions
>
>merge_capability_definition_from_type(context, presentation,
> capability_definition)
>
>  File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/modeling/capabilities.py",
> line 170, in merge_capability_definition_from_type
>
>type_property_defintions = the_type._get_properties(context)
>
> *Validation issues:*
>
>  0: 'NoneType' object has no attribute '_get_properties'
>
> *AttributeError*: 'NoneType' object has no attribute
> '_get_properties'
>
>  4: unknown parent type "tosca:Root" in "WebServer"
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":6:19
>
>  4: "type" refers to an unknown capability type in "host":
> 'tosca:Container'
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":9:15
>
>  4: unknown parent type "tosca:WebApplication" in "WebApp"
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":12:19
>
> Failed to parse service template
>
> Also, the gettingstarted.md file in the website repository is using the
> wrong name for the hello-world bluepr

Re: ARIA-354 Verified

[Tal Liron]

Tom, the errors he is getting are not related to permissions. He has gone
beyond the install phase and is having errors when trying to parse a TOSCA
file.

On Mon, Nov 27, 2017 at 4:53 PM, Thomas Nadeau <tnadeaua...@gmail.com>
wrote:

> You need to do this as:
>
> % sudo -H pip install …
>
> Its a permissions problem.  I literally started to modify the Installation
> Instructions earlier when I was reminded of this myself.  Can’t get a good
> answer as to how to fix it either.  Experienced it on CenOS, Fedora and
> Ubuntu.
>
> —Tom
>
>
> > On Nov 27, 2017, at 5:49 PM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com> wrote:
> >
> > I executed: pip install apache-ariatosca[ssh]
> > Should I use "pip install apache-ariatosca[ssh]==0.1.1 --no-binary
> > apache-ariatosca" instead?
> >
> >
> > --
> > 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 27, 2017 at 2:47 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> >> Miguel, how did you install ARIA?
> >>
> >> On Mon, Nov 27, 2017 at 4:44 PM, Miguel Angel Jimenez Achinte <
> >> mig...@rigiresearch.com> wrote:
> >>
> >>> I just installed ARIA on Centos 7 and I get the same error:
> >>>
> >>> Storing service template my-service-template...
> >>>
> >>> *AttributeError*: 'NoneType' object has no attribute '_get_properties'
> >>>
> >>>  File "/usr/lib/python2.7/site-packages/aria/parser/
> >>> consumption/consumer.py",
> >>> line 70, in consume
> >>>
> >>>consumer.consume()
> >>>
> >>>  File "
> >>> /usr/lib/python2.7/site-packages/aria/parser/
> consumption/validation.py",
> >>> line 30, in consume
> >>>
> >>>self.context.presentation.presenter._validate(self.context)
> >>>
> >>>  File "
> >>> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> >>> simple_v1_0/presenter.py",
> >>> line 65, in _validate
> >>>
> >>>self.service_template._validate(context)
> >>>
> >>>  File "
> >>> /usr/lib/python2.7/site-packages/aria/parser/
> >>> presentation/presentation.py",
> >>> line 193, in _validate
> >>>
> >>>validate_known_fields(context, self)
> >>>
> >>>  File "/usr/lib/python2.7/site-packages/aria/parser/
> >>> presentation/utils.py",
> >>> line 110, in validate_known_fields
> >>>
> >>>field.validate(presentation, context)
> >>>
> >>>  File "/usr/lib/python2.7/site-packages/aria/parser/
> >>> presentation/fields.py",
> >>> line 409, in validate
> >>>
> >>>self.default_validate(presentation, context)
> >>>
> >>>  File "/usr/lib/python2.7/site-packages/aria/parser/
> >>> presentation/fields.py",
> >>> line 524, in default_validate
> >>>
> >>>self.validate_value(value, context)
> >>>
> >>>  File "/usr/lib/python2.7/site-packages/aria/parser/
> >>> presentation/fields.py",
> >>> line 540, in validate_value
> >>>
> >>>inner_value._validate(context)
> >>>
> >>>  File "
> >>> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> >>> simple_v1_0/types.py",
> >>> line 654, in _validate
> >>>
> >>>self._get_capabilities(context)
> >>>
> >>>  File "/usr/lib/python2.7/site-packages/aria/utils/caching.py", line
> >> 84,
> >>> in __call__
> >>>
> >>>return_value = self.func(*args, **kwargs)
> >>>
> >>>  File "
> >>> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> >>> simple_v1_0/types.py",
> >>> line 639, in _get_capabilities
> >>>
> >>>return FrozenDict(get_inherited_capability_definitions(context,
> >> self))
> >>>
> >>>  File "
> >>> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> >>> simple_v1_0/modeling/capabilities.py",
> >>> line 90, in get_inherited_capability_d

Re: ARIA-354 Verified

[Tal Liron]

The error you are seeing now is unrelated to the error that required the
"--no-binary" workaround.

It seems somehow your install is not seeing the extensions, and thus is not
finding the TOSCA parser.

Are you using a virtualenv? Or are you using "sudo -H" to install to your
operating system?

On Mon, Nov 27, 2017 at 4:49 PM, Miguel Angel Jimenez Achinte <
mig...@rigiresearch.com> wrote:

> I executed: pip install apache-ariatosca[ssh]
> Should I use "pip install apache-ariatosca[ssh]==0.1.1 --no-binary
> apache-ariatosca" instead?
>
>
> --
> 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 27, 2017 at 2:47 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Miguel, how did you install ARIA?
> >
> > On Mon, Nov 27, 2017 at 4:44 PM, Miguel Angel Jimenez Achinte <
> > mig...@rigiresearch.com> wrote:
> >
> > > I just installed ARIA on Centos 7 and I get the same error:
> > >
> > > Storing service template my-service-template...
> > >
> > > *AttributeError*: 'NoneType' object has no attribute '_get_properties'
> > >
> > >   File "/usr/lib/python2.7/site-packages/aria/parser/
> > > consumption/consumer.py",
> > > line 70, in consume
> > >
> > > consumer.consume()
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria/parser/
> consumption/validation.py",
> > > line 30, in consume
> > >
> > > self.context.presentation.presenter._validate(self.context)
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria_extension_tosca/
> > > simple_v1_0/presenter.py",
> > > line 65, in _validate
> > >
> > > self.service_template._validate(context)
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/presentation.py",
> > > line 193, in _validate
> > >
> > > validate_known_fields(context, self)
> > >
> > >   File "/usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/utils.py",
> > > line 110, in validate_known_fields
> > >
> > > field.validate(presentation, context)
> > >
> > >   File "/usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/fields.py",
> > > line 409, in validate
> > >
> > > self.default_validate(presentation, context)
> > >
> > >   File "/usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/fields.py",
> > > line 524, in default_validate
> > >
> > > self.validate_value(value, context)
> > >
> > >   File "/usr/lib/python2.7/site-packages/aria/parser/
> > > presentation/fields.py",
> > > line 540, in validate_value
> > >
> > > inner_value._validate(context)
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria_extension_tosca/
> > > simple_v1_0/types.py",
> > > line 654, in _validate
> > >
> > > self._get_capabilities(context)
> > >
> > >   File "/usr/lib/python2.7/site-packages/aria/utils/caching.py", line
> > 84,
> > > in __call__
> > >
> > > return_value = self.func(*args, **kwargs)
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria_extension_tosca/
> > > simple_v1_0/types.py",
> > > line 639, in _get_capabilities
> > >
> > > return FrozenDict(get_inherited_capability_definitions(context,
> > self))
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria_extension_tosca/
> > > simple_v1_0/modeling/capabilities.py",
> > > line 90, in get_inherited_capability_definitions
> > >
> > > merge_capability_definition_from_type(context, presentation,
> > > capability_definition)
> > >
> > >   File "
> > > /usr/lib/python2.7/site-packages/aria_extension_tosca/
> > > simple_v1_0/modeling/capabilities.py",
> > > line 170, in merge_capability_definition_from_type
> > >
> > > type_property_defintions = the_type._get_properties(context)
> > >
> > > *Validation issues:*
> > >
> > >   0: 'NoneType' object has no attribute '_get

Re: ARIA-354 Verified

[Tal Liron]

Miguel, how did you install ARIA?

On Mon, Nov 27, 2017 at 4:44 PM, Miguel Angel Jimenez Achinte <
mig...@rigiresearch.com> wrote:

> I just installed ARIA on Centos 7 and I get the same error:
>
> Storing service template my-service-template...
>
> *AttributeError*: 'NoneType' object has no attribute '_get_properties'
>
>   File "/usr/lib/python2.7/site-packages/aria/parser/
> consumption/consumer.py",
> line 70, in consume
>
> consumer.consume()
>
>   File "
> /usr/lib/python2.7/site-packages/aria/parser/consumption/validation.py",
> line 30, in consume
>
> self.context.presentation.presenter._validate(self.context)
>
>   File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/presenter.py",
> line 65, in _validate
>
> self.service_template._validate(context)
>
>   File "
> /usr/lib/python2.7/site-packages/aria/parser/
> presentation/presentation.py",
> line 193, in _validate
>
> validate_known_fields(context, self)
>
>   File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/utils.py",
> line 110, in validate_known_fields
>
> field.validate(presentation, context)
>
>   File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/fields.py",
> line 409, in validate
>
> self.default_validate(presentation, context)
>
>   File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/fields.py",
> line 524, in default_validate
>
> self.validate_value(value, context)
>
>   File "/usr/lib/python2.7/site-packages/aria/parser/
> presentation/fields.py",
> line 540, in validate_value
>
> inner_value._validate(context)
>
>   File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/types.py",
> line 654, in _validate
>
> self._get_capabilities(context)
>
>   File "/usr/lib/python2.7/site-packages/aria/utils/caching.py", line 84,
> in __call__
>
> return_value = self.func(*args, **kwargs)
>
>   File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/types.py",
> line 639, in _get_capabilities
>
> return FrozenDict(get_inherited_capability_definitions(context, self))
>
>   File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/modeling/capabilities.py",
> line 90, in get_inherited_capability_definitions
>
> merge_capability_definition_from_type(context, presentation,
> capability_definition)
>
>   File "
> /usr/lib/python2.7/site-packages/aria_extension_tosca/
> simple_v1_0/modeling/capabilities.py",
> line 170, in merge_capability_definition_from_type
>
> type_property_defintions = the_type._get_properties(context)
>
> *Validation issues:*
>
>   0: 'NoneType' object has no attribute '_get_properties'
>
>  *AttributeError*: 'NoneType' object has no attribute '_get_properties'
>
>   4: unknown parent type "tosca:Root" in "WebServer"
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":6:19
>
>   4: "type" refers to an unknown capability type in "host":
> 'tosca:Container'
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":9:15
>
>   4: unknown parent type "tosca:WebApplication" in "WebApp"
>
>
> @"/home/centos/incubator-ariatosca/examples/hello-
> world/hello-world.yaml":12:19
>
> Failed to parse service template
>
> Also, the gettingstarted.md file in the website repository is using the
> wrong name for the hello-world blueprint.
> It's missing the hyphen. I'll add the issue tonight.
>
> I clone the master branch to try the hello-world example.
> To install ARIA, I executed: pip install apache-ariatosca[ssh]
>
> --
> 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 27, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Tom, the specific problems we had were not with installation, but rather
> in
> > running workflows. Have you tried to install the Hello World example?
> >
> > On Mon, Nov 27, 2017 at 2:54 PM, Thomas Nadeau <tnadeaua...@gmail.com>
> > wrote:
> >
> > >
> > > I took an action during the grooming to verify the installation
> > of
> > > the latest PIP artifacts.
> > > I was able to install successfully on Ubuntu 16.04 LTS just now.
> > >
> > > —Tom
> > >
> > >
> > >
> >
>

Re: ARIA-354 Verified

[Tal Liron]

Tom, the specific problems we had were not with installation, but rather in
running workflows. Have you tried to install the Hello World example?

On Mon, Nov 27, 2017 at 2:54 PM, Thomas Nadeau 
wrote:

>
> I took an action during the grooming to verify the installation of
> the latest PIP artifacts.
> I was able to install successfully on Ubuntu 16.04 LTS just now.
>
> —Tom
>
>
>

Re: ASF Slack Access and Write Permissions to the Wiki

[Tal Liron]

I see no harm in giving them that permission.

On Mon, Nov 27, 2017 at 12:44 PM, John D. Ament 
wrote:

> I think I see the issue.  In the JIRA permission scheme, contributors can
> resolve and close issues, but not transition them.  Are we in agreement
> that contributors should be able to transition issues?
>
> On Mon, Nov 27, 2017 at 1:41 PM Thomas Nadeau 
> wrote:
>
> > which issue?
> >
> > > On Nov 27, 2017, at 1:33 PM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> > >
> > > Thanks John.
> > > Is there a reason why I am not able to edit the state of a Jira item
> > assigned to me?
> > >
> > >
> > > Sent from my iPhone
> > >
> > > On Nov 27, 2017, at 12:25 PM, John D. Ament  > > wrote:
> > >
> > > I've given you both access to confluence.  I added MIguel as a
> > contributor
> > > in JIRA, Vish you were already listed as a contributor.
> > >
> > > On Mon, Nov 27, 2017 at 1:19 PM Vishwanath Jayaraman <
> > > vishwana...@hotmail.com> wrote:
> > >
> > > John,
> > >
> > > My username is vishwanathj and associated email address is
> > > vishwana...@hotmail.com.
> > >
> > > I need edit access to confuence/wiki and permissions in JIRA to be able
> > to
> > > change issue states from Open->Progress->resolved, etc.
> > >
> > > Thanks in advance for all your help.
> > >
> > > Vish
> > >
> > >
> > > 
> > > From: John D. Ament  > >>
> > > Sent: Monday, November 27, 2017 12:13 PM
> > > To: dev@ariatosca.incubator.apache.org > dev@ariatosca.incubator.apache.org>
> > > Subject: Re: ASF Slack Access and Write Permissions to the Wiki
> > >
> > > Miguel,
> > >
> > > To get you set up on JIRA and Confluence, we'll need to know your
> > username.
> > >
> > > John
> > >
> > > On Mon, Nov 27, 2017 at 12:23 PM Thomas Nadeau  > >
> > > wrote:
> > >
> > >
> > >   Sorry by “apache ID” I meant “jira login” below.  I think Miguel
> > > looking for wiki and Slack access
> > > only.  Vish ran into the same issue earlier with wiki access, but in
> his
> > > case permissions
> > > vanished after he did have write access to the wiki.
> > >
> > >   —Tom
> > >
> > >
> > > On Nov 27, 2017, at 12:21 PM, John D. Ament  > >
> > > wrote:
> > >
> > > Hi,
> > >
> > > I saw your email to general@incubator.  I'm not sure what your goal
> > > is.  Do
> > > you want access to the AriaTosca wiki/JIRA?  Or the incubator wide
> > > wiki/JIRA?
> > >
> > > Note that apache.org emails are only given to
> > committers.
> > >
> > > John
> > >
> > > On Mon, Nov 27, 2017 at 12:07 PM Miguel Angel Jimenez Achinte <
> > > mig...@rigiresearch.com> wrote:
> > >
> > > Thank you Tom. I was reading about the Apache email account and
> > > wasn't sure if I should contact the infrastructure team. I'll send the
> > > email.
> > >
> > > 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 27, 2017 at 9:04 AM, Thomas Nadeau  > 
> > >
> > > wrote:
> > >
> > >
> > >  Miguel asked about getting access to ASF Slack at the
> > > grooming call this morning, so I thought I’d send this to the entire
> > > list.
> > >
> > >  In order to gain access, please send email to
> > > gene...@incubator.apache.org
> > > asking for write permissions on your Apache ID for the wiki/jira
> > > as well as access to the Slack channel.
> > >
> > >  —Tom
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>

Re: Support for extension point during service execution

[Tal Liron]

Hi DJ,

The question here is why use ARIA's orchestrator at all? It sounds like you
have your own orchestration engine. This is an intended use case for ARIA
(and indeed was used in the OPEN-O project).

There are a few ways to use ARIA here:

1) You can use the ARIA's Python API and access all the data models
directly. Of course this will only work if your own orchestration code is
in Python.
2) You can use ARIA's CLI to emit the data models you need in either JSON
or YAML format, for easy consumption by your code: aria services show
myservice --json. Note that you can also wrap ARIA's CLI in an HTTP service.
3) You can access the database directly. ARIA uses a a normalized
relational (SQL) database.

There are some challenges and limitations to each approach. If you tell us
what you're going to do we can help you move along in that direction.


On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran  wrote:

> Hi Team,
>
> We are looking at an execution point during a service execution through a
> plugin. With this the execution will not go through the workflow runner
> (install/uninstall) defined by the orchestrator but the services instance
> context object will be provided to the plugin which will take care of the
> complete service-execution.
> This plugin is looked upon as a "service plugin" which will get the entire
> service model object and will provide the details to the external workflow
> engine.
> We need this feature to enable the execution of workflows which some of
> our users already have. Please let us know your thoughts on this as we have
> already started our technical study on this.
>
>
> Regards,
> DJ
>

Re: What does it take to become an AriaTosca committer?

[Tal Liron]

It means you have commitment to the project. :)

Being a committer is not just about rights to push code, but also provides
other admin rights on resources as well as voting rights (you need to be a
committer to join the PMC, or Project Management Committee) for releases
and for accepting other committers.

For more information: https://www.apache.org/dev/pmc.html

On Wed, Nov 22, 2017 at 5:59 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Yes, but the topic was being a committer.  If you aren't producing code or
> docs, what exactly are you "committing"?
>
> On Wed, Nov 22, 2017 at 12:33 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Remember than anybody can be contributor. Becoming a committer,
> > specifically, means having privileges to move the project forward
> according
> > to the agreed-upon roadmap. I personally think there's a lot more to that
> > than just being a Python coder, which is why I personally don't
> necessarily
> > value code contributions over others. AriaTosca has implications
> regarding
> > standards bodies and industry reach of TOSCA that go beyond the project's
> > mere technical value. I'm in favor of keeping the various aspects of the
> > list equally important.
> >
> > In the end the list is just a set of guidelines. Current committers get
> to
> > vote for accepting new committers, and there can be discussion (on the
> > private@ mailing list) regarding individual candidates.
> >
> > On Wed, Nov 22, 2017 at 1:23 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Looks good.  I'd only say that it's item 1 and/or item 2, plus bonus
> > points
> > > for things in the rest of the list.  If all you provide is amazing code
> > > contributions, that should be sufficient.  Also, if it's an election
> that
> > > should be mentioned.
> > >
> > > On Wed, Nov 22, 2017 at 8:45 AM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > I've written up a list of requirements:
> > > >
> > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > Becoming+a+Committer
> > > >
> > > > It's up to the committers to define this list, but would be happy to
> > get
> > > > feedback from non-committers, too!
> > > >
> > >
> >
>

Re: What does it take to become an AriaTosca committer?

[Tal Liron]

Remember than anybody can be contributor. Becoming a committer,
specifically, means having privileges to move the project forward according
to the agreed-upon roadmap. I personally think there's a lot more to that
than just being a Python coder, which is why I personally don't necessarily
value code contributions over others. AriaTosca has implications regarding
standards bodies and industry reach of TOSCA that go beyond the project's
mere technical value. I'm in favor of keeping the various aspects of the
list equally important.

In the end the list is just a set of guidelines. Current committers get to
vote for accepting new committers, and there can be discussion (on the
private@ mailing list) regarding individual candidates.

On Wed, Nov 22, 2017 at 1:23 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Looks good.  I'd only say that it's item 1 and/or item 2, plus bonus points
> for things in the rest of the list.  If all you provide is amazing code
> contributions, that should be sufficient.  Also, if it's an election that
> should be mentioned.
>
> On Wed, Nov 22, 2017 at 8:45 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > I've written up a list of requirements:
> >
> > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Becoming+a+Committer
> >
> > It's up to the committers to define this list, but would be happy to get
> > feedback from non-committers, too!
> >
>

What does it take to become an AriaTosca committer?

[Tal Liron]

I've written up a list of requirements:

https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer

It's up to the committers to define this list, but would be happy to get
feedback from non-committers, too!

Re: operation dependencies

[Tal Liron]

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  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: Error installing my-service (hello-world example)

[Tal Liron]

I'm 100% sure this has nothing to do with the version of Linux in this
case...

We do have an open bug being worked on right now having to do with that
pesky ctx installation. It's expected to be fixed in time for the next
release of ARIA:

https://issues.apache.org/jira/browse/ARIA-354

On Fri, Nov 17, 2017 at 6:11 AM, Thomas Nadeau 
wrote:

>
> Glad you got it working. In general, I recommend using the LTS
> releases of Ubuntu as
> the leading releases are often too cutting edge/unstable in the most
> unexpected places. 8)
>
> —Tom
>
>
> > On Nov 16, 2017, at 7:06 PM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com> wrote:
> >
> > Vish,
> > It's working well now on Ubuntu 16.04. It was probably because I already
> > had installed ARIA, so when I executed that command it
> > didn't cause any effect.
> > Thank you,
> > 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 Thu, Nov 16, 2017 at 3:43 PM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> >> Can you confirm that below is the commas you used to install aria?
> >>
> >>
> >> pip install apache-ariatosca[ssh]==0.1.1 --no-binary apache-ariatosca
> >>
> >> I would recommend using 16.04 as I have verified it on 16.04
> >>
> >> Thanks
> >> -Vish
> >> Sent from my iPhone
> >>
> >> On Nov 16, 2017, at 5:23 PM, Miguel Angel Jimenez Achinte <
> >> mig...@rigiresearch.com> wrote:
> >>
> >> Hi Vish,
> >> I'm installing ARIA on Ubuntu 17.04.
> >> I followed the instructions you mentioned but the output is the same.
> >> Should I use Ubuntu 16.04?
> >> 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 Thu, Nov 16, 2017 at 2:07 PM, Vishwanath Jayaraman <
> >> vishwana...@hotmail.com> wrote:
> >>
> >> Miguel,
> >>
> >> Trying following the instructions at https://github.com/apache/
> >> incubator-ariatosca-website/tree/master/samples/Ubuntu and see if that
> >> works for you on ubuntu 16.04.
> >>
> >> On which OS are you installing ARIA?
> >>
> >> -Vish
> >>
> >> [https://avatars3.githubusercontent.com/u/47359?s=400=4]<
> >> https://github.com/apache/incubator-ariatosca-website/
> tree/master/samples/
> >> Ubuntu>
> >>
> >> apache/incubator-ariatosca-website >> apache/incubator-ariatosca-website/tree/master/samples/Ubuntu>
> >> github.com
> >> incubator-ariatosca-website - Mirror of Apache ariatosca (Incubating)
> >>
> >>
> >>
> >>
> >> Vish
> >>
> >>
> >> 
> >> From: Miguel Angel Jimenez Achinte > mig...@rigiresearch.com>>
> >> Sent: Thursday, November 16, 2017 3:53 PM
> >> To: dev@ariatosca.incubator.apache.org >> ariatosca.incubator.apache.org>
> >> Subject: Error installing my-service (hello-world example)
> >>
> >> Hi,
> >>
> >> My name is Miguel, I'm a PhD. student at the University of Victoria,
> >> Canada. I'm currently doing research on Software Deployment and I'm very
> >> interested in contributing to the ARIA project.
> >>
> >> So far, I've been reading the existing documentation but I encountered a
> >> problem with the hello-world example. I installed ARIA v0.1.1 and
> followed
> >> the hello-world example from the README (I made sure to use the 0.1.1
> >> version of the blueprint). When I execute the last part of the example
> >> (aria executions start install -s my-service) this is what I get:
> >>
> >> Starting 'install' workflow execution
> >> web_app_1 Standard.configure started...
> >> Executing: /tmp/tmp67bMy9-configure.sh
> >> Execution done (exit_code=127): /tmp/tmp67bMy9-configure.sh
> >> web_app_1 Standard.configure failed
> >> ...
> >> repeat
> >> ...
> >>
> >> I assume the issue here is the command 'ctx' in the script. Should I do
> >> something extra to make it work?
> >>
> >> If this is not the right place to post this issue, please let me know.
> >> Thank you,
> >> Miguel
> >>
> >>
>
>

Re: Attribute and Property Reflection

[Tal Liron]

Yes, we're on the same page, I just used the opportunity to clarify how
ARIA implements this variance.

On Thu, Nov 16, 2017 at 6:30 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> I meant attribute values differ.  Property values don't differ between
> instances.  When I mean allow functions to be values, I mean the return
> value only from the TOSCA perspective.
>
> On Thu, Nov 16, 2017 at 3:21 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > Well, you can argue that attributes *vary* per node instance, while
> > properties *do not vary* per node instance.
> >
> > Our discussion about function values is important: if a property value
> is a
> > function, the actual evaluated value might indeed be different per node
> > instance.
> >
> > ARIA actually does keep copies of everything (both properties and
> > attributes) for every node instance in the models. We made this blanket
> > decision to allow for full flexibility in implementing plugins and
> > supporting future versions of TOSCA. While in TOSCA properties are
> strictly
> > read-only at the parser level, it may be possible for plugins to change
> > property values. Imagine, for example, a plugin that takes existing
> Compute
> > nodes and upgrades them: many of their properties may change.
> >
> > It's fine and good for TOSCA to be strict, but we wanted ARIA to
> underneath
> > be as flexible as needed.
> >
> > On Thu, Nov 16, 2017 at 5:12 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Properties and attributes have no relationship.  I always assumed the
> > > reflection was a convenience.  Attributes are per instance, not per
> node.
> > >
> > > On Thu, Nov 16, 2017 at 2:54 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > The reason I think this is a bad feature is that TOSCA makes such a
> > clear
> > > > effort to separate properties from attributes, but then this
> reflection
> > > > features means that basically it's enough to only have properties...
> > > >
> > > > My proposal for TOSCA 2.0 would be to have *just* properties and to
> > allow
> > > > some properties to have "mutable: true" if you want then to behave
> like
> > > an
> > > > attribute.
> > > >
> > > > On Thu, Nov 16, 2017 at 3:01 PM, Steve Baillargeon <
> > > > steve.baillarg...@ericsson.com> wrote:
> > > >
> > > > > Hi Tal
> > > > > I found the magic statement in 3.5.8.1.1
> > > > > Yes the reflected attribute name must be the same as the property
> > name
> > > > for
> > > > > the reflection feature.
> > > > > Now I understand your second point. Thanks for your patience.
> > > > >
> > > > > Why do you think it is a bad feature?
> > > > > Property is the desired value while reflected attribute is the
> actual
> > > > > value.
> > > > > It seems logical to show actual value.
> > > > > Or are you saying the actual value will always be the same as the
> > > desired
> > > > > value and the reflected attribute is useless?
> > > > >
> > > > > -Steve
> > > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Tal Liron [mailto:t...@cloudify.co]
> > > > > Sent: Thursday, November 16, 2017 3:49 PM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: Attribute and Property Reflection
> > > > >
> > > > > The reflection feature is mentioned very, very briefly in just that
> > one
> > > > > sentence in the spec. They is no mention of changing names, so I am
> > > > > expecting that the attribute names would be identical to the
> property
> > > > > names. In that case, there would be a conflict if an attribute has
> > the
> > > > same
> > > > > name as a property -- otherwise how would the property be
> reflected?
> > > > That's
> > > > > why I'm assuming that for this to work we should not allow an
> > attribute
> > > > > name to override a property name.
> > > > >
> > > > > My preferred solution is not to add any custom prefixes in ARIA,
> > > because
> > > > > they would not be portable
> > > > >
> > >

Re: Attribute and Property Reflection

[Tal Liron]

Well, you can argue that attributes *vary* per node instance, while
properties *do not vary* per node instance.

Our discussion about function values is important: if a property value is a
function, the actual evaluated value might indeed be different per node
instance.

ARIA actually does keep copies of everything (both properties and
attributes) for every node instance in the models. We made this blanket
decision to allow for full flexibility in implementing plugins and
supporting future versions of TOSCA. While in TOSCA properties are strictly
read-only at the parser level, it may be possible for plugins to change
property values. Imagine, for example, a plugin that takes existing Compute
nodes and upgrades them: many of their properties may change.

It's fine and good for TOSCA to be strict, but we wanted ARIA to underneath
be as flexible as needed.

On Thu, Nov 16, 2017 at 5:12 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Properties and attributes have no relationship.  I always assumed the
> reflection was a convenience.  Attributes are per instance, not per node.
>
> On Thu, Nov 16, 2017 at 2:54 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > The reason I think this is a bad feature is that TOSCA makes such a clear
> > effort to separate properties from attributes, but then this reflection
> > features means that basically it's enough to only have properties...
> >
> > My proposal for TOSCA 2.0 would be to have *just* properties and to allow
> > some properties to have "mutable: true" if you want then to behave like
> an
> > attribute.
> >
> > On Thu, Nov 16, 2017 at 3:01 PM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi Tal
> > > I found the magic statement in 3.5.8.1.1
> > > Yes the reflected attribute name must be the same as the property name
> > for
> > > the reflection feature.
> > > Now I understand your second point. Thanks for your patience.
> > >
> > > Why do you think it is a bad feature?
> > > Property is the desired value while reflected attribute is the actual
> > > value.
> > > It seems logical to show actual value.
> > > Or are you saying the actual value will always be the same as the
> desired
> > > value and the reflected attribute is useless?
> > >
> > > -Steve
> > >
> > >
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Thursday, November 16, 2017 3:49 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Attribute and Property Reflection
> > >
> > > The reflection feature is mentioned very, very briefly in just that one
> > > sentence in the spec. They is no mention of changing names, so I am
> > > expecting that the attribute names would be identical to the property
> > > names. In that case, there would be a conflict if an attribute has the
> > same
> > > name as a property -- otherwise how would the property be reflected?
> > That's
> > > why I'm assuming that for this to work we should not allow an attribute
> > > name to override a property name.
> > >
> > > My preferred solution is not to add any custom prefixes in ARIA,
> because
> > > they would not be portable
> > >
> > > The TOSCA spec has many authors, and it would be hard to track down the
> > > particular one who wrote this sentence... Personally, I think this is
> an
> > > awful and unclear feature.
> > >
> > > On Thu, Nov 16, 2017 at 2:43 PM, Steve Baillargeon <
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Back 1 step please.
> > > > Are you saying that attribute names and property names within a Type
> > > > MUST be different?
> > > > As far as I know they can be the same e.g.   =
> > > > 
> > > >
> > > > attributes:
> > > >   :
> > > > type:string
> > > > properties:
> > > >   :
> > > >   type:string
> > > >
> > > >
> > > > Back to reflection.
> > > > I am proposing  = actual_ But I think
> > > > it is best if I ask further clarification from YAML Profile authors.
> > > > What do you think?
> > > > What is your preferred solution?
> > > >
> > > > -Steve
> > > >
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Tal Liron [mailto:t...@cloudify.co]
>

Re: Attribute and Property Reflection

[Tal Liron]

The reason I think this is a bad feature is that TOSCA makes such a clear
effort to separate properties from attributes, but then this reflection
features means that basically it's enough to only have properties...

My proposal for TOSCA 2.0 would be to have *just* properties and to allow
some properties to have "mutable: true" if you want then to behave like an
attribute.

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

> Hi Tal
> I found the magic statement in 3.5.8.1.1
> Yes the reflected attribute name must be the same as the property name for
> the reflection feature.
> Now I understand your second point. Thanks for your patience.
>
> Why do you think it is a bad feature?
> Property is the desired value while reflected attribute is the actual
> value.
> It seems logical to show actual value.
> Or are you saying the actual value will always be the same as the desired
> value and the reflected attribute is useless?
>
> -Steve
>
>
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 16, 2017 3:49 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Attribute and Property Reflection
>
> The reflection feature is mentioned very, very briefly in just that one
> sentence in the spec. They is no mention of changing names, so I am
> expecting that the attribute names would be identical to the property
> names. In that case, there would be a conflict if an attribute has the same
> name as a property -- otherwise how would the property be reflected? That's
> why I'm assuming that for this to work we should not allow an attribute
> name to override a property name.
>
> My preferred solution is not to add any custom prefixes in ARIA, because
> they would not be portable
>
> The TOSCA spec has many authors, and it would be hard to track down the
> particular one who wrote this sentence... Personally, I think this is an
> awful and unclear feature.
>
> On Thu, Nov 16, 2017 at 2:43 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Back 1 step please.
> > Are you saying that attribute names and property names within a Type
> > MUST be different?
> > As far as I know they can be the same e.g.   =
> > 
> >
> > attributes:
> >   :
> > type:string
> > properties:
> >   :
> >   type:string
> >
> >
> > Back to reflection.
> > I am proposing  = actual_ But I think
> > it is best if I ask further clarification from YAML Profile authors.
> > What do you think?
> > What is your preferred solution?
> >
> > -Steve
> >
> >
> >
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Thursday, November 16, 2017 3:15 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Attribute and Property Reflection
> >
> > Steve, we cannot change the TOSCA spec, and the spec does not say
> > anything about naming conventions here.
> >
> > I think, though, that an obvious part of this JIRA will be to emit an
> > error if an attribute name is the same as a property name, because
> > obviously this would break this feature.
> >
> > On Thu, Nov 16, 2017 at 2:12 PM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > I see the following text in the JIRA:
> > > According to the TOSCA 1.0 spec, property value should be 'exposed',
> > > with the same name, as attributes.
> > >
> > > Does the spec really say to use the same name? As far as I know it
> > > does not.
> > > What about using a better reflected attribute naming convention like
> > > “actual_”?
> > > Can I add this to the JIRA?
> > >
> > > -Steve B
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Thursday, November 16, 2017 2:48 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Attribute and Property Reflection
> > >
> > > Not right now, but there is an open JIRA to support it.
> > >
> > > On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon <
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Hi
> > > > Does ARIA support "attribute and property reflection" defined in
> > > 3.5.10.1?
> > > >
> > > > Regards
> > > > Steve B
> > > >
> > > >
> > >
> >
>

Re: Attribute and Property Reflection

[Tal Liron]

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

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

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

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

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

Re: attributes

[Tal Liron]

Well, this is *kinda* supported in ARIA right now.

It *is* supported via the Python API: you can create an instance of any
function class (such as GetProperty) and it will be serialized the storage
and evaluated upon retrieval.

But it is *not* supported via ctx in Bash. If we want to support this, we
would also need to find a syntax for doing so (ctx right now would have no
idea if you mean to use a plain string or mean to instantiate a function).

If you feel this is a useful feature, feel free to open a JIRA for it.
Please describe it in as much detail as possible and perhaps add some
practical use cases for the feature.

(By the way, I don't see this as an issue of programming languages moving
from structs to accessors, but an issue of functional programming.
Functional programming languages treat functions as "first-class citizens",
so that they can be passed around by value. The TOSCA spec has nothing to
say about this, but it is something we can support quite easily because we
built ARIA in Python, which does have this functional aspect.)

On Thu, Nov 16, 2017 at 2:21 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Yes.  Permit a function to be an attribute value.  This would apply to both
> context and intrinsic evaluation.
>
> On Thu, Nov 16, 2017 at 12:18 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > I'm not entirely sure what you are saying here. My guess is that you mean
> > something like this:
> >
> > When setting an attribute value via ctx, you want ARIA to be able to set
> > function values. For example, this is just a regular value:
> >
> > ctx set my_attribute "plain string value"
> >
> > You are saying that we should also support this:
> >
> > ctx set my_attribute "{ get_property: [ SELF, property_name ] }"
> >
> > In which case you expect ARIA to actually evaluate the function when you
> > retrieve the value of my_attribute. Am I understanding you correctly?
> >
> >
> > On Thu, Nov 16, 2017 at 1:55 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > What I'm talking about has nothing to do with TOSCA.  It only has to do
> > > with the orchestrator.  Accessing an attribute has nothing to do with
> > > operations.
> > >
> > > On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > DeWayne, what you asking for might be achievable via the
> > > > "get_operation_output" function. This function is not very well
> defined
> > > in
> > > > TOSCA, but it seems that the expectation is that every operation can
> > > return
> > > > an untyped key-value dict. This has nothing to do with attributes per
> > se,
> > > > but behind the scenes works quite similarly.
> > > >
> > > > But, if you really you want something more dynamic ("call to the
> cloud"
> > > as
> > > > you say), that doesn't exist in TOSCA right now. It could be possible
> > to
> > > > add such a feature to ARIA, but it would not be portable.
> > > >
> > > > Steve, seems that you understand it correctly.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Nov 16, 2017 at 1:25 PM, Steve Baillargeon <
> > > > steve.baillarg...@ericsson.com> wrote:
> > > >
> > > > > Hi
> > > > > A follow-up question.
> > > > > I am trying to understand the meaning of "function" here.
> > > > >
> > > > > Is the solution as simple as defining an attribute (say of type
> > > string),
> > > > > skip the attribute assignment in the template and let the plugin
> > > decides
> > > > > the "value" for the attribute which can be a calculated value or
> any
> > > > > function implemented by the plugin? Yes I agree this is not
> portable.
> > > > > Did I miss something?
> > > > >
> > > > > -Steve
> > > > >
> > > > > -Original Message-
> > > > > From: Tal Liron [mailto:t...@cloudify.co]
> > > > > Sent: Wednesday, November 15, 2017 4:24 PM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: attributes
> > > > >
> > > > > Well, this is a bit complex.
> > > > >
> > > > > Attributes are ostensibly filled during runtime by other systems,
> for
> > > > > example during the install workflow an ip_addre

Re: attributes

[Tal Liron]

I'm not entirely sure what you are saying here. My guess is that you mean
something like this:

When setting an attribute value via ctx, you want ARIA to be able to set
function values. For example, this is just a regular value:

ctx set my_attribute "plain string value"

You are saying that we should also support this:

ctx set my_attribute "{ get_property: [ SELF, property_name ] }"

In which case you expect ARIA to actually evaluate the function when you
retrieve the value of my_attribute. Am I understanding you correctly?


On Thu, Nov 16, 2017 at 1:55 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> What I'm talking about has nothing to do with TOSCA.  It only has to do
> with the orchestrator.  Accessing an attribute has nothing to do with
> operations.
>
> On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > DeWayne, what you asking for might be achievable via the
> > "get_operation_output" function. This function is not very well defined
> in
> > TOSCA, but it seems that the expectation is that every operation can
> return
> > an untyped key-value dict. This has nothing to do with attributes per se,
> > but behind the scenes works quite similarly.
> >
> > But, if you really you want something more dynamic ("call to the cloud"
> as
> > you say), that doesn't exist in TOSCA right now. It could be possible to
> > add such a feature to ARIA, but it would not be portable.
> >
> > Steve, seems that you understand it correctly.
> >
> >
> >
> >
> >
> > On Thu, Nov 16, 2017 at 1:25 PM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi
> > > A follow-up question.
> > > I am trying to understand the meaning of "function" here.
> > >
> > > Is the solution as simple as defining an attribute (say of type
> string),
> > > skip the attribute assignment in the template and let the plugin
> decides
> > > the "value" for the attribute which can be a calculated value or any
> > > function implemented by the plugin? Yes I agree this is not portable.
> > > Did I miss something?
> > >
> > > -Steve
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Wednesday, November 15, 2017 4:24 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: attributes
> > >
> > > Well, this is a bit complex.
> > >
> > > Attributes are ostensibly filled during runtime by other systems, for
> > > example during the install workflow an ip_address would get its real
> > value.
> > > It's not really clear how another system would be able to insert a
> > > function here, but it's not impossible. In ARIA's case, functions are
> > > implemented as pickled Python classes, so it would be possible to do
> > this,
> > > however obviously it would not be portable.
> > >
> > > But, you can also give attributes default values. For default values,
> > > obviously you can use functions.
> > >
> > > On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > General TOSCA question.  Is there anything in the spec that requires
> > > > attributes to be values rather than functions?  IOW, is there
> anything
> > > > in there that prevents an orchestrator from representing an attribute
> > > > read as more of a "getter", rather than a database fetch?  I ask
> > > > because I've run across a case where I'd prefer an attribute
> reference
> > > > to return a calculated value.  Seems more flexible if allowed, and if
> > > > not allowed, it should be allowed.
> > > >
> > > > DeWayne
> > > >
> > >
> >
>

Re: Attribute and Property Reflection

[Tal Liron]

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

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

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

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

Re: Attribute and Property Reflection

[Tal Liron]

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

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

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

Re: attributes

[Tal Liron]

DeWayne, what you asking for might be achievable via the
"get_operation_output" function. This function is not very well defined in
TOSCA, but it seems that the expectation is that every operation can return
an untyped key-value dict. This has nothing to do with attributes per se,
but behind the scenes works quite similarly.

But, if you really you want something more dynamic ("call to the cloud" as
you say), that doesn't exist in TOSCA right now. It could be possible to
add such a feature to ARIA, but it would not be portable.

Steve, seems that you understand it correctly.





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

> Hi
> A follow-up question.
> I am trying to understand the meaning of "function" here.
>
> Is the solution as simple as defining an attribute (say of type string),
> skip the attribute assignment in the template and let the plugin decides
> the "value" for the attribute which can be a calculated value or any
> function implemented by the plugin? Yes I agree this is not portable.
> Did I miss something?
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 15, 2017 4:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: attributes
>
> Well, this is a bit complex.
>
> Attributes are ostensibly filled during runtime by other systems, for
> example during the install workflow an ip_address would get its real value.
> It's not really clear how another system would be able to insert a
> function here, but it's not impossible. In ARIA's case, functions are
> implemented as pickled Python classes, so it would be possible to do this,
> however obviously it would not be portable.
>
> But, you can also give attributes default values. For default values,
> obviously you can use functions.
>
> On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > General TOSCA question.  Is there anything in the spec that requires
> > attributes to be values rather than functions?  IOW, is there anything
> > in there that prevents an orchestrator from representing an attribute
> > read as more of a "getter", rather than a database fetch?  I ask
> > because I've run across a case where I'd prefer an attribute reference
> > to return a calculated value.  Seems more flexible if allowed, and if
> > not allowed, it should be allowed.
> >
> > DeWayne
> >
>

Re: attributes

[Tal Liron]

Well, this is a bit complex.

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

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

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

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

Re: Attributes

[Tal Liron]

No. Because TOSCA doesn't: attributes must be declared at the type.

But, you can always declare an "open" type (map of strings) to allow for
arbitrary attributes.

On Tue, Nov 14, 2017 at 6:55 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Does Aria permit adhoc attributes created in plugins?
>
> DeWayne
>
> On Nov 14, 2017 3:04 PM, "Tal Liron" <t...@cloudify.co> wrote:
>
> Thanks, Steve. It seems that you are looking at the table at 5.8.2.2. The
> "required" column here seems poorly named: what they seem to mean is that
> when required is "yes" the orchestrator *must* fill in a value. Indeed all
> the attributes I mentioned earlier, that ARIA fills in, are marked as
> "required"=true.
>
> On Tue, Nov 14, 2017 at 4:58 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > The required column  for attributes is below.
> >
> > Required = yes à Mandatory to fill in ?
> >
> > Required = no à Optional to fill in ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>

Re: Attributes

[Tal Liron]

Thanks, Steve. It seems that you are looking at the table at 5.8.2.2. The
"required" column here seems poorly named: what they seem to mean is that
when required is "yes" the orchestrator *must* fill in a value. Indeed all
the attributes I mentioned earlier, that ARIA fills in, are marked as
"required"=true.

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

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

Re: Attributes

[Tal Liron]

Why are you calling this attribute "optional"?

ARIA always exposes it, and also *should* fill in its value. This might
depend on the actual plugin doing the provisioning work... we would need to
verify this on a case by case basis. As to which value, again it depends on
the plugin.

Which IP address should it use? TOSCA doesn't say. I think everyone agrees
that networking in TOSCA is very poorly designed.

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

> As an example, does ARIA always expose the "optional" private_address for
> a Compute node instance?
> If so, what method is used by ARIA to select the primary OAM IP address
> when multiple IPs are associated with the Compute node instance?
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, November 14, 2017 5:27 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Attributes
>
> ARIA exposes all defined attributes, even if they have no default value
> (in which case they will be null).
>
> Note that three attributes (tosca_id, tosca_name, state) are automatically
> filled by ARIA, if they are available. Any node type inheriting from
> tosca.nodes.Root will have them.
>
> I'm not sure what you mean by "optional" or "mandatory": there is no way
> to define attributes that way. See section 3.5.10.2 in the spec.
>
> On Tue, Nov 14, 2017 at 4:05 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > The YAML spec is confusing about when the service or node instance
> > actually exposes the value of an attribute.
> > Does ARIA always implement and expose the values of all attribute
> > definitions (optional and mandatory) defined in normative types?
> >
> > Related observation: it is very strange that the YAML spec does not
> > support a REQUIRED keyname for the attribute definition. Then how do
> > we go about declaring an optional vs mandatory attribute definition in
> > custom type definitions? For now, I am almost ready to conclude that
> > all attributes SHOULD be exposed by the TOSCA orchestrator regardless
> > if it is required or not.
> >
> > -Steve
> >
>

Re: Attributes

[Tal Liron]

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

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

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

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

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

Re: native plugins

[Tal Liron]

There is no spec for native plugins yet, but it's something that I'm
working on. More info to come.

On Mon, Nov 13, 2017 at 12:54 PM, DeWayne Filppi 
wrote:

> As opposed to using Cloudify plugins, is there an example of a native
> plugin?  Or should new plugins just be written for Cloudify and adapted.
> I'm talking user role plugins, not internal like execution.
>
> DeWayne
>

Re: Implementation for get_operation_output

[Tal Liron]

No, it has not yet been implemented.

On Mon, Nov 13, 2017 at 2:03 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> Will the below work at this moment ?
>
> ctx return my_value = this is the value
> And then you could use get_operation_output on "my_value".
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 09, 2017 10:14 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey <
> barry.dow...@ericsson.com>
> Subject: Re: Implementation for get_operation_output
>
> This function has not yet been implemented, so it's stored nowhere. But of
> course it will likely have to be stored per particular execution.
>
> The "ctx" tool is just a way to remotely access the context object, so
> yes, with plugins it's identical.
>
> On Thu, Nov 9, 2017 at 1:14 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > To understand a bit more, so where are these return values stored ?
> > Would they updated to services as we do with TOSCA attributes or do
> > they live only for a particular execution ?
> > Also when it comes to plugin, can I do the same with the context
> > object being passed rather than using the "ctx" tool ?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Wednesday, November 08, 2017 8:06 PM
> > To: dev@ariatosca.incubator.apache.org
> > Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey <
> > barry.dow...@ericsson.com>
> > Subject: Re: Implementation for get_operation_output
> >
> > ARIA currently uses a special tool, called "ctx", to communicate with
> > implementation scripts. I imagine we will use the same tool to set
> > return values.
> >
> > My understanding is also that these return values are quite arbitrary,
> > and thus un-typed. They will likely be stored as strings. So, for
> > example, from within a bash script you would do something like this:
> >
> > ctx return my_value = this is the value
> >
> > And then you could use get_operation_output on "my_value".
> >
> >
> > On Tue, Nov 7, 2017 at 5:55 AM, D Jayachandran <
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > We currently don't have an implementation for the intrinsic function
> > > "get_operation_output".
> > >
> > > As per the TOSCA Simple YAML 1.0, specification it indicates this
> > > function must be used to retrieve the values of variables exposed /
> > > exported from an interface operation.
> > > The variable which is referenced here seems to be an environmental
> > > variable exposed by the interface operation script/plugin. (2.14.3
> > Example:
> > > setting output variables to an attribute, 2.14.4 Example: passing
> > > output variables between operations )
> > >
> > > We would like if you have the same understanding on the variable
> > > which is referenced in "get_operation_output".
> > >
> > > FROM TOSCA SPEC
> > >
> > >  - The required name of the variable that is
> > > exposed / exported by the operation.
> > >
> > > Here it is just stated as a variable. In the example it is mentioned
> > > as "environmental" variable exposed. Do you see a difference here ?
> > > Are we considering as an environmental variable or as an attribute
> > variable ?.
> > >
> > > Please let us know your comments on this so that we can plan the
> > > implementation of this.
> > >
> > > Regards,
> > > DJ
> > >
> >
>

Re: decoupling type definitions from CSAR

[Tal Liron]

I'll just add that you can either use a repository or just a complete URL
in the "file" section of "imports" (or short-form, which is just the URL).

Also, obviously there is a risk in using external imports: external changes
could break existing imports. But considering the complexities of cloud
deployments, I imagine there are a lot of dependencies on external factors,
anyway...

On Fri, Nov 10, 2017 at 10:12 AM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi Vaish
> I agree.
>
> We should also consider the same idea for NFV and ONAP types (as opposed
> to make them built-in).
> I suspect those types may get updated without the need to update the ARIA
> orchestrator version.
>
> Is it just a matter of allowing the admin user to load/delete type
> definitions files  into the ARIA local host and specifying the repository
> option in the import definition?
> Similar to plugins?
>
> For instance:
>
> For individually managed plugins:
> -file : plugin.yaml
>   repository: plugins
>
> For individually managed type definitions files:
> -file : typedefintion.yaml
>   repository: definitions
>
>
> Regards
> Steve B
>
>
>
>
> -Original Message-
> From: Vaishnavi K.R [mailto:vaishnavi@ericsson.com]
> Sent: Friday, November 10, 2017 6:30 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: decoupling type definitions from CSAR
>
> Hi,
>
>
> With the current ARIA, in order to use the type definitions that are user
> defined, it must be imported in the Service Template. The definitions files
> are imported by specifying the relative paths in the 'imports' section.
> These type definition files can rather reside in the localhost running ARIA
> or can be made available by bundling along with the service templates in a
> CSAR. For remote executions, the latter holds good.
>
>
> However if the type definitions are so common and can be used across
> Service Templates, it becomes mandatory to include the same file in
> different CSARs.
>
>
> In order to reuse the type definitions that are common across service
> templates, it would be better to maintain the user defined type definitions
> separately and every service template can use it irrespective of their
> CSARs.
>
>
> This makes the user defined type definitions to be loaded once and the
> service templates could import it.
>
>
> I would like to know your view on this.
>
>
> Thanks,
>
> /Vaish
>

Re: operation dependencies

[Tal Liron]

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" concept, since
> it does not seem to solved in v1.2.
>
> In addition, I agree that this does not solve the problem of your proposed
> inputs/meta inputs (inputs/configurations) distinction. Just a thought, we
> could decide that an input with a special name such as "cfg" could be a map
> containing "configurations", while other inputs are treated as regular
> inputs. This could part of the ARIA profile.
>
> [side note:
> You said:
> And indeed this is exactly what we see example 2.14.2, too, where we see
> property assignments. But this example snippet doesn't prove much of
> anything, because we don't see the node type defined, just used here.
> The "wp_db_port" input could/should be declared there.
> But in fact this type is defined in [8.3
> <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725259>],
> The section for non-normative types used for examples throughout the spec.
> This section also exist in 

Re: Support for namespace prefix

[Tal Liron]

I like that you called it a "bad idea". :)

Currently ARIA does not have complete namespace support, so the prefix will
not work.

On Wed, Nov 8, 2017 at 7:12 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> Say I have a topology template using the following node templates:
>
>
>   *   Node A from type tosca.nodes.Compute --> This is the TOSCA standard
> Compute node type. The tosca namespace prefix is not explicitly used here.
>   *   Node B from type abc: tosca.nodes.Compute --> This is an imported
> custom Compute node type with the same type URI as the standard Compute
> (bad idea) but different namespace prefix
>
> Will ARIA distinguish these 2 node types?
>
> Regards
> Steve B
>
>

Re: Implementation for get_operation_output

[Tal Liron]

This function has not yet been implemented, so it's stored nowhere. But of
course it will likely have to be stored per particular execution.

The "ctx" tool is just a way to remotely access the context object, so yes,
with plugins it's identical.

On Thu, Nov 9, 2017 at 1:14 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tal,
>
> To understand a bit more, so where are these return values stored ? Would
> they updated to services as we do with TOSCA attributes or do they live
> only for a particular execution ?
> Also when it comes to plugin, can I do the same with the context object
> being passed rather than using the "ctx" tool ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 08, 2017 8:06 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey <
> barry.dow...@ericsson.com>
> Subject: Re: Implementation for get_operation_output
>
> ARIA currently uses a special tool, called "ctx", to communicate with
> implementation scripts. I imagine we will use the same tool to set return
> values.
>
> My understanding is also that these return values are quite arbitrary, and
> thus un-typed. They will likely be stored as strings. So, for example, from
> within a bash script you would do something like this:
>
> ctx return my_value = this is the value
>
> And then you could use get_operation_output on "my_value".
>
>
> On Tue, Nov 7, 2017 at 5:55 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi All,
> >
> > We currently don't have an implementation for the intrinsic function
> > "get_operation_output".
> >
> > As per the TOSCA Simple YAML 1.0, specification it indicates this
> > function must be used to retrieve the values of variables exposed /
> > exported from an interface operation.
> > The variable which is referenced here seems to be an environmental
> > variable exposed by the interface operation script/plugin. (2.14.3
> Example:
> > setting output variables to an attribute, 2.14.4 Example: passing
> > output variables between operations )
> >
> > We would like if you have the same understanding on the variable which
> > is referenced in "get_operation_output".
> >
> > FROM TOSCA SPEC
> >
> >  - The required name of the variable that is
> > exposed / exported by the operation.
> >
> > Here it is just stated as a variable. In the example it is mentioned
> > as "environmental" variable exposed. Do you see a difference here ?
> > Are we considering as an environmental variable or as an attribute
> variable ?.
> >
> > Please let us know your comments on this so that we can plan the
> > implementation of this.
> >
> > Regards,
> > DJ
> >
>

Re: Official Project Vote: Moving to Gitbox

[Tal Liron]

+1

On Wed, Nov 8, 2017 at 10:19 AM, Thomas Nadeau 
wrote:

>
> We need to take a formal vote on whether or not to move forward
> with gitbox.  Can the project committers please post their
> votes.
>
> I will tally the votes and post the conclusion by the close of
> business
> today.
>
> Thanks,
>
> —Tom
>
>
>

Re: Implementation Artifact Override

[Tal Liron]

Yes.

My understanding is that artifacts are not an important part of the
object-oriented contract, but are instead "attachments" to nodes.
Supporting this is that the same definition format appears in both node
templates and node types. In a way, putting the artifact definition in the
node type is thus just setting a default value for it.

So ARIA, for now, let's you override them freely.

On Tue, Nov 7, 2017 at 3:35 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> Does ARIA support the ability to override an implementation artifact that
> is already been specified in the node type?
> For instance:
>
> node_types:
>   aria.openstack.nodes.Server:
> derived_from: tosca.nodes.Compute
> ...
> interfaces:
>   Standard:
> create:
>   implementation: cloudify-openstack-plugin >
> nova_plugin.server.create
>
>
> topology_template:
>   node_templates:
> fortigate_vnf:
>   type: aria.openstack.nodes.Server
>   interfaces:
> Standard:
>   create:
> implementation: my_script.py
>
>
>
> Regards
> Steve Baillargeon
>
>

Re: Implementation for get_operation_output

[Tal Liron]

ARIA currently uses a special tool, called "ctx", to communicate with
implementation scripts. I imagine we will use the same tool to set return
values.

My understanding is also that these return values are quite arbitrary, and
thus un-typed. They will likely be stored as strings. So, for example, from
within a bash script you would do something like this:

ctx return my_value = this is the value

And then you could use get_operation_output on "my_value".


On Tue, Nov 7, 2017 at 5:55 AM, D Jayachandran 
wrote:

> Hi All,
>
> We currently don't have an implementation for the intrinsic function
> "get_operation_output".
>
> As per the TOSCA Simple YAML 1.0, specification it indicates this function
> must be used to retrieve the values of variables exposed / exported from an
> interface operation.
> The variable which is referenced here seems to be an environmental
> variable exposed by the interface operation script/plugin. (2.14.3 Example:
> setting output variables to an attribute, 2.14.4 Example: passing output
> variables between operations )
>
> We would like if you have the same understanding on the variable which is
> referenced in "get_operation_output".
>
> FROM TOSCA SPEC
>
>  - The required name of the variable that is exposed
> / exported by the operation.
>
> Here it is just stated as a variable. In the example it is mentioned as
> "environmental" variable exposed. Do you see a difference here ? Are we
> considering as an environmental variable or as an attribute variable ?.
>
> Please let us know your comments on this so that we can plan the
> implementation of this.
>
> Regards,
> DJ
>

Meeting Minutes, Nov 6

[Tal Liron]

Attendees: Tom Nadeau, Vish Jayaraman, Tal Liron, Arthur Berezin, Avia Efrat

Decisions:

   - The process to release 0.2 will begin as soon as we merge ARIA-1,
   ARIA-392, and ARIA-393. So: later this week.
   - The big ARIA-350 epic (service composition) will be delayed for now
   due to lack of resources. We will follow up ASAP with a plan to address
   this.
   - ARIA-344 (improve topology module) will move to this sprint

Also discussed:

   - Improving the Docker image
   - Improving the development/user experience of ARIA (to be followed up
   with another meeting)

Re: helloworld oddity

[Tal Liron]

This is fixed for the upcoming 0.2 release.

On Fri, Nov 3, 2017 at 11:26 AM, Thomas Nadeau 
wrote:

>
> Yea that is one of the things on the list of “getting started”
> things to straighten out.
> The PR Vish is about to push starts those fixes.
>
> --Tom
>
> > On Nov 3, 2017, at 12:14 PM, DeWayne Filppi  wrote:
> >
> > Perfect.  Thanks.
> >
> > On Fri, Nov 3, 2017 at 8:52 AM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> >> I ran into this issue earlier.
> >>
> >> The example you are referrring to is in the master branch of the
> >> hello_world.yaml https://github.com/apache/incubator-ariatosca/blob/
> >> master/examples/hello-world/hello-world.yaml
> >>
> >>
> >> You will need to use the example from 0.1.1 tagged branch at
> >> https://github.com/apache/incubator-ariatosca/blob/0.1.
> >> 1/examples/hello-world/helloworld.yaml to work with the 0.1.1
> >> installation of aria
> >>
> >> [https://avatars3.githubusercontent.com/u/47359?s=400=4]<
> >> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/examples/hello-
> >> world/helloworld.yaml>
> >>
> >> apache/incubator-ariatosca >> incubator-ariatosca/blob/0.1.1/examples/hello-world/helloworld.yaml>
> >> github.com
> >> incubator-ariatosca - Mirror of Apache incubator
> >>
> >>
> >> [https://avatars3.githubusercontent.com/u/47359?s=400=4]<
> >> https://github.com/apache/incubator-ariatosca/blob/
> master/examples/hello-
> >> world/hello-world.yaml>
> >>
> >> apache/incubator-ariatosca >> incubator-ariatosca/blob/master/examples/hello-world/hello-world.yaml>
> >> github.com
> >> incubator-ariatosca - Mirror of Apache incubator
> >>
> >>
> >>
> >>
> >> Vish
> >>
> >>
> >> 
> >> From: DeWayne Filppi 
> >> Sent: Friday, November 3, 2017 10:17 AM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: helloworld oddity
> >>
> >> In the helloworld.yaml example template there is a node derived from
> >> tosca:Root.
> >>
> >>   WebServer:
> >>   derived_from: tosca:Root
> >>
> >> This fails validation in 0.1.1.   Am I missing something?
> >>
> >> DeWayne
> >>
>
>

Re: Seeing message "Both curl, wget were not found in path" when running on CentOS7

[Tal Liron]

The Linux images contributed to the Docker repository tend to be much more
bare than full installs, so indeed tools like this end up missing. I
imagine an Ubuntu Docker image, Fedora, etc., might have the same problems.

But it's correct this this curl/wget is a dependency and that we should
mention it. Please keep collecting these and we will update our guides.

On Tue, Oct 31, 2017 at 7:10 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> I see the below error message (highlighted in RED) when I run the
> instructions from http://ariatosca.incubator.apache.org/getting-started/
> on CentOS 7 container.
>
>
> nuc5cpyh@ubuntu5cpyh:~$ docker-compose logs aria
> Attaching to nuc5cpyh_aria_1
> aria_1  | Storing service template my-service-template...
> aria_1  | Service template my-service-template stored
> aria_1  | Creating new service from service template my-service-template...
> aria_1  | Service created. The service's name is my-service
> aria_1  | Starting execution. Press Ctrl+C cancel
> aria_1  | Starting 'install' workflow execution
> aria_1  | web_app_1 Standard.configure started...
> aria_1  | Executing: /tmp/tmpEZxG1f-configure.sh
> aria_1  | Creating HTTP server root directory at /tmp/python-simple-http-
> webserver
> aria_1  | Downloading blueprint resources...
> aria_1  | Execution done (exit_code=0): /tmp/tmpEZxG1f-configure.sh
> aria_1  | web_app_1 Standard.configure successful
> aria_1  | web_app_1 Standard.start started...
> aria_1  | Executing: /tmp/tmpPNcm4A-start.sh
> aria_1  | Starting HTTP server from /tmp/python-simple-http-webserver
> aria_1  | Starting SimpleHTTPServer
> aria_1  | Waiting for server to launch on port 9090
> aria_1  | Both curl, wget were not found in path
> aria_1  | Execution done (exit_code=1): /tmp/tmpPNcm4A-start.sh
> aria_1  | web_app_1 Standard.start failed
>
>
>
> The dependencies section of ubuntu/centos in the getting started page
> needs to be updated to instruct that curl and wget needs to be installed.
>
>
> However, I notice that the above messages in RED still show up even after
> installing curl and wget.
>
>
> Any comments?
>
> Getting Started with ARIA TOSCA • Apache ARIA TOSCA incubator.apache.org/getting-started/>
> ariatosca.incubator.apache.org
> The source package comes along with relevant examples, documentation,
> requirements.txt (for installing specifically the frozen dependencies’
> versions with which ...
>
>
>
>
> Vish
>

Python 2.6 support is over

[Tal Liron]

After getting some feedback from the AriaTosca community, as well as the
Cloudify user community (which has been using a similar product for years)
we have decided to stop supporting Python 2.6 in ARIA. ARIA now requires
Python 2.7.

Python 2.7 was released in 2010.

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

[Tal Liron]

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

> imports:
>   - file: 
> repository: 
> namespace_uri: 
> namespace_prefix: 
>

This is in TOSCA 1.0, too. Repositories are supported. Namespaces aren't,
but we have an open JIRA.

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

Ignored for now.


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

The convention is the dot notation, just like in the Simple Profile, e.g.
"tosca.capabilities.Container". First segment is the domain, second is the
type of the type (node, capability, data, etc.), and third is the short
name of the type in camel case.

E.g.: "ericsson.nodes.VirtualRouter"


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

Hard for me to say! I think it could make sense in certain uses.


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

There are discussions afoot for redoing a lot of things with plugins... for
now I would say keep an eye on developments and voice your opinion as it
moves. We will make sure to get feedback from the community.


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

There's just a general mess between the import and the use of policies for
plugins. We would want to unify the two and make it more transparent.

Re: Defining a Metadata keyname as a list?

[Tal Liron]

No, you cannot. The spec clearly defines metadata as a list of strings, and
ARIA conforms.

However, it's not hard to work around this. You can put the list of items
you want as a string with some kind of delimiter (comma?) Or, you can do a
numbering trick. You will have to parse it yourself. Examples:

my_key: 'value1, value2, value3'

Or:

my_key.1: value1
my_key.2: value2
my_key.3: value3


On Mon, Oct 30, 2017 at 1:18 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> The metadata section is defined as a map where each entry has a keyname
> and value.
> Example:
> : 
> ...
> : 
>
> Can I further define a metadata keyname as a list of values ?
> Example:
> : 
> : [, ,...]
>
> Regards
> Steve B
>
>

Re: Deprecating formal support for Windows Platform

[Tal Liron]

My opinion is that we should keep Windows support.

Beyond the fact that Azure is a popular cloud platform, testing on Windows
keeps us honest for our Python work, making sure that we're writing
platform-neutral code.

The AppVeyor tests are broken for now, but I'm confident we will eventually
fix them.

On Thu, Oct 26, 2017 at 1:57 PM, Thomas Nadeau 
wrote:

>
> Aria-Tosca Community:
>
> I wanted to take a formal poll of the community in terms of
> our official support for the Windows platform.  While the project should
> continue running as the project is a python package, this is more around
> the logistics/efforts/resources we as a project have to invest in
> maintaining support for that platform; specifically, our CI and testing
> as well as documentation around installation, etc...
>
> What prompted me to think about this is that over the past week or
> so, we
> have encountered a number of strange CI failures that have required
> considerable time
> spent on trying to get things working.  As some of you might have gathered
> from
> slack/email, Tal spent a ton of time trying to fixing the latest issues and
> was still not able to completely resolve them which is why the current
> plan is that committers have to do manual tests, which have their own
> associated costs.  As a team we have limited resources to work on the
> project,
> so I wanted to make sure we are focusing them all on moving towards release
> 1.0.
>
> As a result earlier this week I asked people in/around the project
> informally
> and found no one using or developing on that platform, so I wanted to
> ask here formally if anyone is interested in our continued support
> of the platform or not.  If you are, please indicate in as much detail
> as you can as to why/how.  I would also like to here if you are not
> explicitly,
> but if I don’t, I will assume that people aren’t.
>
> Also, if you do not feel like you can post that to the public
> list, please contact me offline and I will keep your responses anonymous.
> I would like to gather this input over the course of the next week so that
> we can make a decision on this by about Friday, November
>
>
> Cheers,
>
> —Tom
>
>

Re: Definition names

[Tal Liron]

1) Yes, the two capability names are in the same node type, the name
distinguishes them. (This is a YAML issue.)
2) Yes, the two are unrelated and can be the same or different.

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

> Let me use a concrete example by modifying the compute node type a little.
> See below.
> Assume this is for a single node type
>
> 
> requirements:
>   - :
>   capability: tosca.capabilities.Attachment
>   node: tosca.nodes.BlockStorage
>   relationship: tosca.relationships.AttachesTo
>   occurrences: [0, UNBOUNDED]
> capabilities:
>:
> type: tosca.capabilities.Container
> valid_source_types: [tosca.nodes.SoftwareComponent]
>   :
> type: tosca.capabilities.Endpoint.Admin
>
>
> 1)  I am assuming capability definition name 1 and capability definition
> name 2 must be different. Do you agree?
>
> 2) I am assuming requirement definition name 1 and capability definition
> name 1 can be the same. Do you agree?
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, October 26, 2017 2:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Definition names
>
> I'm not entirely sure what you mean... here's a reply according to what I
> understand.
>
> In most cases there is no ambiguity because the language is YAML-based. A
> dict in YAML has unique keys, so it follows that definitions would be
> unique. (We discussed the issue of importing in a previous thread, and
> opened a JIRA for it.)
>
> There is one curious exception: sequenced lists. In node templates, you
> define requirements as a sequenced list, meaning that you are allowed to
> specify the same requirement name multiple times. This makes perfect sense,
> and matches the "occurrences" field in the the node type.
>
> However ... at the node type the requirement definition is *also* a
> sequenced list. There is no technical reason for this: I believe TOSCA
> defined it this to make it match the node template style, though in my
> personal opinion this was a wrong choice because by definition the
> requirement is unique per node type. ARIA treats the requirements sequenced
> list in the node type the same way the YAML parser treats keys in a dict:
> if there is a key of the same name, it will overwrite a previous key of
> that name.
>
> On Thu, Oct 26, 2017 at 1:04 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > The TOSCA YAML Profile is not 100% clear about duplicate definitions
> names.
> > What are the guidelines for ARIA?
> >
> > Should all definitions names be unique across definitions "classes"
> > (attributes, properties, requirements, capabilities,...) within a
> > given node type definition?
> > Or is it OK to only have unique definitions names within a given
> > definition "class"?
> >
> > Regards
> > Steve B
> >
> >
>

Re: moving from Python 2.6 -> 2.7.x

[Tal Liron]

Just to clarify: we currently support *both* Python 2.6 and Python 2.7. The
poll is to see if we should continue supporting 2.6.

You might ask why we supported 2.6 in the first place: this came from our
long experience working on Cloudify. Many cloud environments are still
quite old, and many companies still run very old versions of CentOS or
Debian, which do not come with Python 2.7 out of the box. However, with our
hand on the pulse it seems that these old OSes are fading away. Since ARIA
is forward-looking, it may make sense to remove this requirement.

On Thu, Oct 26, 2017 at 1:43 PM, Thomas Nadeau 
wrote:

>
> We’ve been considering moving from 2.6 onto the latest 2.7 for
> some time now,
> and it looks like its time to seriously consider cutting over.   Tal has
> pointed out
> numerous times that because of the 2.6 support, we have a lot of extra
> testing
> and staging that could be eliminated, plus some other benefits that he
> might
> want to elaborate on here.
>
> With this in mind, I wanted to take a poll of the community above
> making this
> move. I would like to hear from both users and devs as to whether or not
> this is cool.
> I’d like to also ask that regardless of your position, that you please
> indicate a time frame
> for moving towards 2.7.x because even if you don’t want the project to
> move, it is
> going to eventually move on but if there are any gating issues requiring
> us to
> take a slower than immediate move here, we need to know and plan for this.
>
> Thanks!
>
> —Tom
>
>

Re: Definition names

[Tal Liron]

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

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

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

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

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

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

Re: Docker Container Release Artifacts

[Tal Liron]

I'm all for Docker releases as long as they don't replace the official
Python install. I guess we need to check with our mentors about how ASF
would relate to such "external" releases. For example, if we're allowed to
link to them from the project page.

On Wed, Oct 25, 2017 at 1:55 PM, DeWayne Filppi  wrote:

> It would be good to have one that doesn't include the REST API.  Something
> more official.
>
> On Wed, Oct 25, 2017 at 1:46 PM, Thomas Nadeau 
> wrote:
>
> >
> > I cannot find any docker container artifacts as part of the
> > official releases that
> > we are doing. Is there any interest in pushing a container officially as
> > part of
> > each release (or do they exist somewhere I haven’t found)?
> >
> > Currently there are a few unofficial ones including the one that
> > DeWayne just pushed here:
> >
> > https://hub.docker.com/r/cloudifyco/aria/  > cloudifyco/aria/>
> >
> > —Tom
> >
> >
>