Re: [RESULT] [VOTE] Retire AriaTosca Podling

2018-06-28 Thread 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,

Re: [RESULT] [VOTE] Retire AriaTosca Podling

2018-06-28 Thread 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

Re: [RESULT] [VOTE] Retire AriaTosca Podling

2018-06-28 Thread 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,

Re: [VOTE] Retire AriaTosca Podling

2018-06-28 Thread 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

Re: [VOTE] Retire AriaTosca Podling

2018-06-25 Thread 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

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

2018-06-25 Thread Tal Liron
e 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: > > > >>

Introducing Puccini, a possible alternative to AriaTosca

2018-06-11 Thread 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

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

2018-06-07 Thread 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

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

2018-05-29 Thread 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.

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

2018-05-18 Thread 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, 2

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

2018-05-18 Thread 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

Re: [Discuss] Future of AriaTosca

2018-05-16 Thread Tal Liron
yachand...@ericsson.com > > > > > wrote: > > > > > > > > > Hi Suneel, > > > > > > > > > > We in Ericsson are actively working on ARIA. We want to keep the > > > > > project on and community active. > > > &g

Re: Aria support for TOSCA-simple-1.1

2018-03-07 Thread 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

Re: ARIA-400

2018-01-16 Thread 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 >

Re: Apache and committer account

2018-01-09 Thread 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

Re: Apache and committer account

2018-01-08 Thread 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

Re: Support for the property type 'null'

2018-01-04 Thread 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

Re: [VOTE] publish ariatosca 0.2.0

2018-01-04 Thread 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

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

2018-01-03 Thread 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

Re: Database session management with model storage.

2017-12-28 Thread 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

Re: [VOTE] publish ariatosca 0.2.0

2017-12-27 Thread 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

Re: Node Template Substitution

2017-12-12 Thread 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

Re: Loading Custom Workflows from CSAR

2017-12-12 Thread Tal Liron
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 > Subjec

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

2017-12-11 Thread 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.

Re: Loading custom workflows

2017-12-07 Thread Tal Liron
d/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 cour

Re: Loading Custom Workflows from CSAR

2017-12-07 Thread Tal Liron
oing, 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 M

Re: Loading custom workflows

2017-12-07 Thread Tal Liron
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@ariatosc

Re: Loading custom workflows

2017-12-06 Thread 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

Re: get_attribute function not supporting SELF as

2017-12-06 Thread Tal Liron
me". 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

Re: get_attribute function not supporting SELF as

2017-12-06 Thread Tal Liron
type: my_Node_Server >interfaces: > Standard: >create: > implementation: sample > sample.sample_test.call_test >configure: > implementation: sample > sample.sample_test.call_name > input

Re: get_attribute function not supporting SELF as

2017-12-05 Thread Tal Liron
F, 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 Me

Re: get_attribute function not supporting SELF as

2017-12-05 Thread Tal Liron
etch > 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

Re: get_attribute function not supporting SELF as

2017-12-05 Thread 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&q

Re: get_attribute function not supporting SELF as

2017-12-05 Thread Tal Liron
Standard: >configure: > inputs: >payload: { > "config": {get_attribute: [ SELF, vmme_configuration ]}} >config: {get_attribute: [ SELF, vmme_configuration ]} > > Regards, > Vaishali. >

Re: get_attribute function not supporting SELF as

2017-12-05 Thread 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

Re: ARIA-118 plugin.yaml importing

2017-12-04 Thread 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

Re: Transition to Gitbox Complete

2017-12-03 Thread 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

Re: Transition to Gitbox Complete

2017-12-03 Thread 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 >

Re: pip executable expected as part of plugin install.

2017-12-03 Thread 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

Re: Support for extension point during service execution

2017-11-29 Thread Tal Liron
> 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

Re: problem using cloudify extension with dev branch

2017-11-29 Thread Tal Liron
osca/ > > 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

Re: problem using cloudify extension with dev branch

2017-11-29 Thread 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,

Re: back to the future

2017-11-28 Thread Tal Liron
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. :) > > &g

Re: Loading Custom Workflows from CSAR

2017-11-28 Thread 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

Re: back to the future

2017-11-28 Thread Tal Liron
ewa...@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 an

Re: back to the future

2017-11-28 Thread Tal Liron
udify.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 th

Re: back to the future

2017-11-28 Thread Tal Liron
ther 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 &g

Re: back to the future

2017-11-28 Thread Tal Liron
t 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

Re: back to the future

2017-11-28 Thread 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

Re: TOSCA type inheritance question

2017-11-28 Thread Tal Liron
rom: 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> wr

Re: TOSCA type inheritance question

2017-11-28 Thread 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

Re: ARIA-354 Verified

2017-11-27 Thread Tal Liron
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

Re: ARIA-354 Verified

2017-11-27 Thread Tal Liron
ersity 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 >

Re: simple validation error

2017-11-27 Thread 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:

Re: ARIA-354 Verified

2017-11-27 Thread Tal Liron
che-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...@

Re: ARIA-354 Verified

2017-11-27 Thread Tal Liron
> > > > > -- > > 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:

Re: ARIA-354 Verified

2017-11-27 Thread Tal Liron
gt; > -- > 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: > > > Mi

Re: ARIA-354 Verified

2017-11-27 Thread Tal Liron
d/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 gettings

Re: ARIA-354 Verified

2017-11-27 Thread 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

Re: ASF Slack Access and Write Permissions to the Wiki

2017-11-27 Thread 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

Re: Support for extension point during service execution

2017-11-24 Thread 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

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

2017-11-22 Thread Tal Liron
; 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 thi

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

2017-11-22 Thread Tal Liron
us 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: > > >

What does it take to become an AriaTosca committer?

2017-11-22 Thread 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

2017-11-22 Thread 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

Re: Error installing my-service (hello-world example)

2017-11-17 Thread 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,

Re: Attribute and Property Reflection

2017-11-16 Thread Tal Liron
ow 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 n

Re: Attribute and Property Reflection

2017-11-16 Thread Tal Liron
, 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:

Re: Attribute and Property Reflection

2017-11-16 Thread Tal Liron
al 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 &g

Re: Attribute and Property Reflection

2017-11-16 Thread Tal Liron
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

Re: attributes

2017-11-16 Thread Tal Liron
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: > > >

Re: attributes

2017-11-16 Thread Tal Liron
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>

Re: Attribute and Property Reflection

2017-11-16 Thread Tal Liron
ame? 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, 20

Re: Attribute and Property Reflection

2017-11-16 Thread 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

2017-11-16 Thread Tal Liron
g), > 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 > > ---

Re: attributes

2017-11-15 Thread 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,

Re: Attributes

2017-11-14 Thread Tal Liron
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 tha

Re: Attributes

2017-11-14 Thread 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

Re: Attributes

2017-11-14 Thread Tal Liron
_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]

Re: Attributes

2017-11-14 Thread 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

Re: native plugins

2017-11-13 Thread 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

Re: Implementation for get_operation_output

2017-11-13 Thread Tal Liron
quot;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

Re: decoupling type definitions from CSAR

2017-11-10 Thread 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

Re: operation dependencies

2017-11-09 Thread Tal Liron
-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 v1.2, with no changes to the aforementioned node > type] > > On Mon, Sep 11, 2017 at 8:01 PM

Re: Support for namespace prefix

2017-11-09 Thread 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: >

Re: Implementation for get_operation_output

2017-11-09 Thread Tal Liron
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

Re: Official Project Vote: Moving to Gitbox

2017-11-08 Thread 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

Re: Implementation Artifact Override

2017-11-08 Thread 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

Re: Implementation for get_operation_output

2017-11-08 Thread 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,

Meeting Minutes, Nov 6

2017-11-06 Thread 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

Re: helloworld oddity

2017-11-03 Thread 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

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

2017-11-01 Thread 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

Python 2.6 support is over

2017-10-31 Thread 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

2017-10-31 Thread 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

Re: Defining a Metadata keyname as a list?

2017-10-30 Thread 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.

Re: Deprecating formal support for Windows Platform

2017-10-30 Thread 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

Re: Definition names

2017-10-26 Thread Tal Liron
on 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...@clo

Re: moving from Python 2.6 -> 2.7.x

2017-10-26 Thread 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

Re: Definition names

2017-10-26 Thread 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,

Re: Docker Container Release Artifacts

2017-10-25 Thread 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

  1   2   3   4   >