Re: install_aria_extensions called twice

[Maxim Orlov]

Ok, so basically the issue is we pickle objects passed to an operation,
when they are unpickled. effectively we call the "install_aria_extensions"
(and later we call it again). What i meant by "flattening the data types"
is turning any "get_input/get_attribute/get_property" to the actual value,
as opposed to a model based reference to that value (before passing it to
an operation).

On Wed, Jan 10, 2018 at 1:58 PM Vaishali Krishnamurthy
<v.krishnamurt...@globallogic.com.invalid> wrote:

> Hi Maxim,
>
> For this https://issues.apache.org/jira/browse/ARIA-432  issue,  I need
> some
> more clarification on the part where it is mentioned "flatten those
> non-primitive types " . Could you please explain?
>
> Regards,
> Vaishali
>
>
> -Original Message-
> From: Srinidhi Srivatsan [mailto:
> srinidhi.srivat...@globallogic.com.INVALID]
> Sent: Friday, December 08, 2017 11:32 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: install_aria_extensions called twice
>
> Hi,
>
> Thanks for the information. Will this item be prioritized and fixed?
>
> Regards,
> Srinidhi.
>
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Wednesday, December 06, 2017 5:59 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: install_aria_extensions called twice
>
> The removal on the call to install_aria_extensions does solve the problem
> in
> your case, however this might raise other issue. For example: writing a
> process executor extension would have no effect if you'd remove the
> `install_aria_extensions` function call.
>
> The actual problem is caused because you try to pass a complex data_type,
> which get pickled. in the unpicking process the extension gets loaded
> automatically, and then it get loaded again via the
> `install_aria_extensions`. Indeed this is a bug we need to address (I've
> opened a JIRA ticket here <https://issues.apache.org/jira/browse/ARIA-432
> >).
>
> On Wed, Dec 6, 2017 at 8:59 AM Srinidhi Srivatsan
> <srinidhi.srivat...@globallogic.com.invalid> wrote:
>
> > Hi,
> >
> >
> >
> > We have observed runtime error “Re-definition of YAML 1.1” error while
> > executing the following service template. This happens when we define
> > a complex type as input into an operation but the first entry must be
> > an intrinsic function even if the type has been defined as string. We
> > think it maybe because of the install_aria_extensions being called
> > twice. When commenting out the “install_aria_extensions” in
> > process.py(executor), execution succeeds.
> >
> >
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> >
> >
> > data_types:
> >
> >   my.datatypes.operation.inputs.Template:
> >
> > derived_from: tosca.datatypes.Root
> >
> > properties:
> >
> >   path:
> >
> > type: string
> >
> >   output:
> >
> > type: my.datatypes.operation.inputs.Template.Output
> >
> > required: false
> >
> >
> >
> >   my.datatypes.operation.inputs.Template.Output:
> >
> > derived_from: tosca.datatypes.Root
> >
> > properties:
> >
> >   runtime_property:
> >
> > type: string
> >
> > required: false
> >
> >   remote_file:
> >
> > type: my.datatypes.operation.inputs.Template.Output.RemoteFile
> >
> > required: false
> >
> >
> >
> >   my.datatypes.operation.inputs.Template.Output.RemoteFile:
> >
> > derived_from: tosca.datatypes.Root
> >
> > properties:
> >
> >   hostname:
> >
> > type: string
> >
> > required: false
> >
> >   username:
> >
> > type: string
> >
> > required: false
> >
> >   password:
> >
> > type: string
> >
> > required: false
> >
> >   path:
> >
> > type: string
> >
> > required: false
> >
> >
> >
> > node_types:
> >
> >   my.nodes.BGW:
> >
> > derived_from: tosca.nodes.Root
> >
> > properties:
> >
> >   host:
> >
> > type: string
> >
> > description: bgw host address
> >
> > interfaces:
> >
> >   Standard:
> >
> > type: tosca.interfaces.node.lifecycle.Standard
> >
> >

Re: [VOTE] publish ariatosca 0.2.0

[Maxim Orlov]

   1. Validated signature & checksums
   2. Validated LICENSE, NOTICE, DISCLAIMER, "-incubating" in file name
   3. Ran RAT check
   4. Made a clean install using "pip install ."
   5. Ran tests using "make test"

+1

On Thu, Jan 4, 2018 at 5:59 PM 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=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: Database session management with model storage.

[Maxim Orlov]

Well, the question is can we achieve the same functionality via the
initiator to the model storage. Although it is initiated only once, using
the sessionfactory with the initiator might help.
If not, it could be a great contribution to the project.

On Wed, Jan 3, 2018 at 7:50 AM D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi All,
>
> Currently ARIA functions as a single threaded application particularly
> with the session management. The sql_mapi does not get the session and
> engine on a thread local basis.
> We feel it is necessary to make changes in session management to
> effectively support multithreading  scenarios.
> If all agree we can contribute on this.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran
> Sent: Friday, December 29, 2017 12:01 PM
> To: dev@ariatosca.incubator.apache.org; Maxim Orlov <ma...@cloudify.co>
> Subject: RE: Database session management with model storage.
>
> Hi Tal,
>
> More than the database used, I was referring on how the model storage is
> being initialized and exposed.
> The sqlalchemy has by its own a sessionfactory and a scopesession to have
> sessions being exposed as thread local.
> But With ARIA I feel this is not properly utilized as it is initialized
> the ModelStorage only once.
>
> Please find the below code snippet from env.py where the model storage is
> initialized.
> @property
> def model_storage(self):
> if not self._model_storage:
> self._model_storage = self._init_sqlite_model_storage()
> return self._model_storage
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Friday, December 29, 2017 11:41 AM
> To: dev@ariatosca.incubator.apache.org; Maxim Orlov <ma...@cloudify.co>
> Subject: Re: Database session management with model storage.
>
> 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: install_aria_extensions called twice

[Maxim Orlov]

The removal on the call to install_aria_extensions does solve the problem
in your case, however this might raise other issue. For example: writing a
process executor extension would have no effect if you'd remove the
`install_aria_extensions` function call.

The actual problem is caused because you try to pass a complex data_type,
which get pickled. in the unpicking process the extension gets loaded
automatically, and then it get loaded again via the
`install_aria_extensions`. Indeed this is a bug we need to address (I've
opened a JIRA ticket here ).

On Wed, Dec 6, 2017 at 8:59 AM Srinidhi Srivatsan
 wrote:

> Hi,
>
>
>
> We have observed runtime error “Re-definition of YAML 1.1” error while
> executing the following service template. This happens when we define a
> complex type as input into an operation but the first entry must be an
> intrinsic function even if the type has been defined as string. We think it
> maybe because of the install_aria_extensions being called twice. When
> commenting out the “install_aria_extensions” in process.py(executor),
> execution succeeds.
>
>
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
>
>
> data_types:
>
>   my.datatypes.operation.inputs.Template:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   path:
>
> type: string
>
>   output:
>
> type: my.datatypes.operation.inputs.Template.Output
>
> required: false
>
>
>
>   my.datatypes.operation.inputs.Template.Output:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   runtime_property:
>
> type: string
>
> required: false
>
>   remote_file:
>
> type: my.datatypes.operation.inputs.Template.Output.RemoteFile
>
> required: false
>
>
>
>   my.datatypes.operation.inputs.Template.Output.RemoteFile:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   hostname:
>
> type: string
>
> required: false
>
>   username:
>
> type: string
>
> required: false
>
>   password:
>
> type: string
>
> required: false
>
>   path:
>
> type: string
>
> required: false
>
>
>
> node_types:
>
>   my.nodes.BGW:
>
> derived_from: tosca.nodes.Root
>
> properties:
>
>   host:
>
> type: string
>
> description: bgw host address
>
> interfaces:
>
>   Standard:
>
> type: tosca.interfaces.node.lifecycle.Standard
>
> configure:
>
>   implementation: scripts/test.py
>
>   inputs:
>
> templates:
>
>   type: list
>
>   entry_schema:
>
> type: my.datatypes.operation.inputs.Template
>
> description: "BGW configuration templates"
>
>
>
> topology_template:
>
>
>
> node_templates:
>
>   bgw:
>
> type: my.nodes.BGW
>
> properties:
>
>   host: "{get_input: BGW_HOST }"
>
> interfaces:
>
>   Standard:
>
> configure:
>
>   inputs:
>
> templates:
>
> - path: "configuration-templates/bgw_epg_add"
>
>   output:
>
>   runtime_property: "bgw_epg_add_configuration"
>
>   remote_file:
>
>   hostname: "host" # replace the string with a
> function and you no longer get the error i.e. { get_property: [SELF, host]
> }
>
>   username: "Name"
>
>   password: "Pwd"
>
>   path:  "the path "
>
> - path: "configuration-templates/bgw_mme_add"
>
>
>
> Regards,
>
> Srinidhi.
>
>
>
> *From:* Srinidhi Srivatsan [mailto:srinidhi.srivat...@globallogic.com]
> *Sent:* Wednesday, December 06, 2017 11:41 AM
> *To:* 'dev@ariatosca.incubator.apache.org'
> *Subject:* install_aria_extensions called twice
>
>
>
> Hi,
>
>
>
>We have observed that install_aria_extensions is called twice – once in
> process.py(executor) and once in main.py. Could you please confirm as to
> why it is called again in process.py?
>
>
>
> Regards,
>
> Srinidhi.
>

Making the usage of ARIA more generic

[Maxim Orlov]

I've been working on making the usage of ARIA more generic, and opened up a
few PRS:

   - https://github.com/apache/incubator-ariatosca/pull/209 - making the
   update of tasks triggered by events more generic.
   - https://github.com/apache/incubator-ariatosca/pull/211 - the current
   json encoding mechanism is too strict to the current implementation of ARIA
   - this PR makes it more generic.

In addition, the current logging handler context manager just adds handlers
instead of replacing it. This PR fixes it:
https://github.com/apache/incubator-ariatosca/pull/210.

These PRs are fairly short and simple, it'd be great if we could push those
to 0.2.0.

Re: problem using cloudify extension with dev branch

[Maxim Orlov]

The extension repo was built based on Aria 0.1.1 base code. The dependency
is strictly set to 0.1.1 , which kinda make sense since 0.2.0 wasn't (and
still isn't) released. It probably uninstalls the 0.2.0 one and installs
0.1.1 instead, which sound to me as a wanted behavior.

On Thu, Nov 30, 2017, 01:06 Tal Liron  wrote:

> 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 
> 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 
> > 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  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 
> > >> 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: Official Project Vote: Moving to Gitbox

[Maxim Orlov]

+1

On Wed, Nov 8, 2017 at 7:41 PM Vishwanath Jayaraman 
wrote:

> +1
>
> Sent from my iPhone
>
> On Nov 8, 2017, at 10:25 AM, Suneel Marthi  > wrote:
>
> +1
>
> Sent from my iPhone
>
> On Nov 8, 2017, at 9:52 PM, Tal Liron > wrote:
>
> +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: TOSCA spec compliance on finding target node

[Maxim Orlov]

The support for satisfying a requirement according to a capability type was
just added as part of
https://github.com/apache/incubator-ariatosca/commit/df2b916e624719e5f77e29c1e893c55f88e15862

On Mon, Aug 7, 2017 at 6:30 PM, Tal Liron  wrote:

> I think you are talking about requirements? Some of the combinations you
> mention are for requirement declarations (at the node type) and some for
> requirement assignments (at the node template).
>
> Generally speaking, ARIA intends to support 100% of the TOSCA spec, so feel
> free to contribute. If a combination does not work, it is a bug.
>
> There is a known bug about requiring a capability without a template that
> is being worked on.
>
> On Mon, Aug 7, 2017 at 12:01 AM, Vaishnavi K.R  >
> wrote:
>
> > Hi,
> >
> >
> > I tried the following combinations in my service template,
> >
> >   1.  Type definition with capability type alone but node template having
> > any of the following,
> >  *   capability type alone
> >  *   capability name alone
> >  *   node type alone
> >  *   node name alone
> >  *   capability name and node name
> >  *   capability name and node type
> >  *   capability type and node type
> >  *   capability type and node type
> >   2.  Type definition with capability type and node type
> >  *   capability type alone
> >  *   capability name alone
> >  *   node type alone
> >  *   node name alone
> >  *   capability name and node name
> >  *   capability name and node type
> >  *   capability type and node type
> >  *   capability type and node type
> >
> > As per the TOSCA specification, the above are valid combinations.
> >
> > Will ARIA support all the above ?? If so, we wish to contribute.
> >
> > Looking forward to your comment.
> >
> >
> >
> > Thanks,
> >
> > /Vaish
> >
> > 
> > From: Tal Liron 
> > Sent: Tuesday, July 25, 2017 10:03:18 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: TOSCA spec compliance on finding target node
> >
> > It indeed should *not* be required. I just verified that it you are
> > correct, and a match is not made if only the capability is specified
> > without a node type/template.
> >
> > This is a regression, because it used to work correctly.
> >
> > There is currently work in progress to refactor that mechanism, so I will
> > add a test case to make sure the regression is fixed.
> >
> > See my test case and follow progress here:
> > https://issues.apache.org/jira/browse/ARIA-174
> >
> > On Tue, Jul 25, 2017 at 3:28 AM, Vaishnavi K.R <
> vaishnavi@ericsson.com
> > >
> > wrote:
> >
> > > Hi ARIA folks,
> > >
> > >
> > > I had a look at the source code of ARIA on how the target node is
> > > identified based on the requirement and capability information
> furnished
> > in
> > > the node template and its corresponding node type. But I find that only
> > few
> > > of the combinations are supported i.e., as per the TOSCA spec, in the
> > > requirement section of a node template, the 'node' option is not
> > mandatory,
> > > but ARIA expects that to be present.
> > >
> > >
> > > In my use-case, my node template has a requirement on a node which has
> a
> > > particular capability. So I just specify the capability type in my node
> > > template under the requirement section. As ARIA expects the 'node'
> option
> > > to be present, this use-case fails.
> > >
> > >
> > > So I wish to get clarified is there any specific reason for mandating
> the
> > > 'node' option or if TOSCA spec compliance on this target identification
> > > based on the capability name or type will be supported in the future
> > > versions?
> > >
> > >
> > > Thanks,
> > >
> > > /Vaish
> > >
> >
>

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

You're right, attributes and properties are similar in their nature. You do
not need to worry yourself with the model behind them.
On the other hand relationship, capabilities etc... are more complex data
structures, and thus they remain structured as a model.

On Wed, Aug 2, 2017 at 9:56 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Max,
>
> Thanks for the info.  So with this decorator we get only the attributes
> and properties wrapped as dictionary.
> All other node objects like relationships, capabilities and interfaces are
> as wrapped mapped collections.
>
> Regards,
> DJ
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Tuesday, August 01, 2017 4:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell scripts
>
> Sorry for the broken email, it seems my markup translator has some funky
> behavior. The code block is:
>
> from aria import operation
>
> @operation
> def samplemethod(ctx=None, **inputs):
>   print "ctx -->",ctx
>   print "inputs -->",inputs
>   ctx.node.attributes['test'] = "abc"
>
>
> On Tue, Aug 1, 2017 at 1:48 PM Maxim Orlov <ma...@cloudify.co> wrote:
>
> > Oh, i see. For each method which represents an operation, you should
> > use the @operation decorator. Thus samplemethod would look like this:
> >
> > from aria import operation
> > @operation
> >
> > def samplemethod(ctx=None, **inputs):
> > print "ctx -->",ctx
> > print "inputs -->",inputs
> > ctx.node.attributes['test'] = "abc"
> >
> > It is actually this decorator which wraps the attribute model for you.
> >
> > p.s.
> > the ctx comes with its own logger, thus using ctx.logger.info("ctx -->
> > {0}".format(ctx)) instead of print "ctx -->", ctx. This will persist
> > your logs, and in case of remote execution, print your logs to the
> > local terminal.
> > ​
> >
> > On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran <
> > d.jayachand...@ericsson.com> wrote:
> >
> >> Hi Max,
> >>
> >> I have a service template with just node templates web_app and
> >> database with a depends on Relationship. Both use the same custom
> >> node type derived from "tosca:Root".
> >> I just have the create operation defined where the implementation
> >> points to a plugin module. Am trying to set the attribute value in the
> plugin.
> >> Please find below service template and node types
> >>
> >> SERVICE TEMPLATE
> >>
> >> tosca_definitions_version: tosca_simple_yaml_1_0
> >>
> >> imports:
> >>   - types/kubernetes_type.yaml
> >>   - aria-1.0
> >>
> >> topology_template:
> >>
> >> inputs:
> >> web_app_name:
> >> type: string
> >> value: tosca-webapp
> >>
> >> web_app_image:
> >> type: string
> >> value: kuber-master:5000/webwithdbinput
> >>
> >> web_app_port:
> >> type: integer
> >> value: 80
> >>
> >> db_name:
> >> type: string
> >> value: tosca-database
> >>
> >> db_image:
> >> type: string
> >> value: kuber-master:5000/dbforweb
> >>
> >> db_port:
> >> type: integer
> >> value: 3306
> >>
> >>
> >> policies:
> >>   testplugin:
> >> type: aria.Plugin
> >> description: policy_description
> >> properties:
> >> version: 1.2.0
> >> enabled: true
> >>
> >> node_templates:
> >> web_app:
> >> type: nodes.Container.Application.Kubernetes
> >> properties:
> >> name: { get_input: web_app_name }
> >> image: { get_input: web_app_image }
> >> port: { get_input: web_app_port }
> >> attributes:
> >> test: abc
> >> requirements:
> >> - dependency:
> >>   node: database
> >>   relationship:
> >>   type: tosca.relationships.DependsOn
> >>   

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Sorry for the broken email, it seems my markup translator has some funky
behavior. The code block is:

from aria import operation

@operation
def samplemethod(ctx=None, **inputs):
  print "ctx -->",ctx
  print "inputs -->",inputs
  ctx.node.attributes['test'] = "abc"


On Tue, Aug 1, 2017 at 1:48 PM Maxim Orlov <ma...@cloudify.co> wrote:

> Oh, i see. For each method which represents an operation, you should use
> the @operation decorator. Thus samplemethod would look like this:
>
> from aria import operation
> @operation
>
> def samplemethod(ctx=None, **inputs):
> print "ctx -->",ctx
> print "inputs -->",inputs
> ctx.node.attributes['test'] = "abc"
>
> It is actually this decorator which wraps the attribute model for you.
>
> p.s.
> the ctx comes with its own logger, thus using ctx.logger.info("ctx -->
> {0}".format(ctx)) instead of print "ctx -->", ctx. This will persist your
> logs, and in case of remote execution, print your logs to the local
> terminal.
> ​
>
> On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Max,
>>
>> I have a service template with just node templates web_app and database
>> with a depends on Relationship. Both use the same custom node type derived
>> from "tosca:Root".
>> I just have the create operation defined where the implementation points
>> to a plugin module. Am trying to set the attribute value in the plugin.
>> Please find below service template and node types
>>
>> SERVICE TEMPLATE
>>
>> tosca_definitions_version: tosca_simple_yaml_1_0
>>
>> imports:
>>   - types/kubernetes_type.yaml
>>   - aria-1.0
>>
>> topology_template:
>>
>> inputs:
>> web_app_name:
>> type: string
>> value: tosca-webapp
>>
>> web_app_image:
>> type: string
>> value: kuber-master:5000/webwithdbinput
>>
>> web_app_port:
>> type: integer
>> value: 80
>>
>> db_name:
>> type: string
>> value: tosca-database
>>
>> db_image:
>> type: string
>> value: kuber-master:5000/dbforweb
>>
>> db_port:
>> type: integer
>> value: 3306
>>
>>
>> policies:
>>   testplugin:
>> type: aria.Plugin
>> description: policy_description
>> properties:
>> version: 1.2.0
>> enabled: true
>>
>> node_templates:
>> web_app:
>> type: nodes.Container.Application.Kubernetes
>> properties:
>> name: { get_input: web_app_name }
>> image: { get_input: web_app_image }
>> port: { get_input: web_app_port }
>> attributes:
>> test: abc
>> requirements:
>> - dependency:
>>   node: database
>>   relationship:
>>   type: tosca.relationships.DependsOn
>> interfaces:
>> Standard:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app, port] }
>> target_host: { get_property: [ database, name] }
>> target_port: { get_property: [ database, port] }
>> isService: true
>> create:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app,
>> port] }
>> target_host: { get_property: [ database,
>> name] }
>> #target_port: { get_property: [ database,
>> port] }
>> target_port: 
>> isService: false
>>
>> database:
>> type: nodes.Container.Application.Kubernetes
>> properties:
>> name: { get_input: db_name }
>> image: { get_input: db_image }
>

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

ved_from: tosca.nodes.Root
> #derived_from: tosca:Root
> properties:
> name:
>   type: string
>   required: true
> image:
>   type: string
>   required: true
> port:
>   type: integer
>   required: false
> attributes:
> test:
>   type: string
> interfaces:
> Standard:
> type: tosca.interfaces.node.lifecycle.Standard
> inputs:
> name:
> type: string
> required: true
> image:
> type: string
> required: true
> exposed_port:
> type: integer
> required: false
> target_port:
> type: integer
> required: false
> default: 8080
> target_host:
> type: string
> required: false
> default: None
> labels:
> type: string
> required: false
> default: test
> isService:
>     type: boolean
> required: false
> create:
> implementation:
> primary: testplugin > sample.samplemethod
>
>
> PLUGIN
>
> def main():
> """Entry point for the application script"""
> print("Call your main application code here")
>
> def samplemethod(ctx=None, **inputs):
> print "ctx -->",ctx
> print "inputs -->",inputs
> ctx.node.attributes['test'] = "abc"
>
>
>
> Regards,
> DJ
>
>
>
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Monday, July 31, 2017 10:22 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell scripts
>
> Interesting, can you describe exactly the scenario? including the service
> template and the operation you are trying to run
>
> On Mon, Jul 31, 2017 at 6:12 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > I got the below error when I tried assigning values as like a dict.
> > It seems to fail when it tries to remove the existing value and
> > triggering a change event.
> >
> > ObjectDereferencedError: Can't emit change event for attribute
> > 'Node.attributes' - parent object of type  has been garbage
> > collected
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@cloudify.co]
> > Sent: Monday, July 31, 2017 6:08 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Inputs and Node object context for python and shell
> > scripts
> >
> > From within any operation or workflow you don't need to use the ".value"
> > notation. In order to access the attribute use
> > ctx.node.attributes['test'], and in order to assign the attribute just
> > use ctx.node.attributes['test'] = "abc". Using this (hopefully
> > simplified) notation does all the model related operations for you.
> >
> > On Mon, Jul 31, 2017, 15:02 D Jayachandran
> > <d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi Max,
> > >
> > > Adding to this , I can access the attributes in my plugin only as
> > > below. ( I have defined the attribute test in my node type )
> > >
> > > ctx.node.attributes['test'].value
> > >
> > > And to update the value
> > >
> > > ctx.node.attributes['test'].value = "abc"
> > >
> > > But this does not update the db. Am I missing something here
> > > in-terms of the context usage ?
> > >
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Maxim Orlov [mailto:ma...@cloudify.co]
> > > Sent: Sunday, July 30, 2017 7:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Inputs and Node object context for python and shell
> > > scripts
> > >
> > > Sorry it took me so long to check it out, things have been kind of
> > hectic.
> > > Anyw

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Interesting, can you describe exactly the scenario? including the service
template and the operation you are trying to run

On Mon, Jul 31, 2017 at 6:12 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> I got the below error when I tried assigning values as like a dict.  It
> seems to fail when it tries to remove the existing value and triggering a
> change event.
>
> ObjectDereferencedError: Can't emit change event for attribute
> 'Node.attributes' - parent object of type  has been garbage collected
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Monday, July 31, 2017 6:08 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell scripts
>
> From within any operation or workflow you don't need to use the ".value"
> notation. In order to access the attribute use
> ctx.node.attributes['test'], and in order to assign the attribute just use
> ctx.node.attributes['test'] = "abc". Using this (hopefully simplified)
> notation does all the model related operations for you.
>
> On Mon, Jul 31, 2017, 15:02 D Jayachandran <d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Max,
> >
> > Adding to this , I can access the attributes in my plugin only as
> > below. ( I have defined the attribute test in my node type )
> >
> > ctx.node.attributes['test'].value
> >
> > And to update the value
> >
> > ctx.node.attributes['test'].value = "abc"
> >
> > But this does not update the db. Am I missing something here in-terms
> > of the context usage ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@cloudify.co]
> > Sent: Sunday, July 30, 2017 7:37 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Inputs and Node object context for python and shell
> > scripts
> >
> > Sorry it took me so long to check it out, things have been kind of
> hectic.
> > Anyway, there is a JIRA issue opened just for that:
> > https://issues.apache.org/jira/browse/ARIA-263.
> >
> > On Tue, Jul 25, 2017 at 9:23 PM, Maxim Orlov <ma...@cloudify.co> wrote:
> >
> > > Not entirely sure about that actually, let me double check that.
> > >
> > > On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > >> It should be impossible in TOSCA to create an attribute that was
> > >> not declared at the type. Are we allowing users to create any ad
> > >> hoc attribute?
> > >>
> > >> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co>
> wrote:
> > >>
> > >> > Indeed runtime_properties became attributes in ARIA . As for the
> > >> behavior,
> > >> > attributes behave just as a dict would (behind the scenes
> > >> > attributes translate to a proper Attribute TOSCA model).
> > >> > No need to define the attributes on the node-type level, if an
> > >> > attribute with that name exists in on the model, the value of
> > >> > that attribute
> > >> would be
> > >> > overridden, if you are creating a whole new attribute, a proper
> > >> Attribute
> > >> > model would be created for you.
> > >> >
> > >> > as for:
> > >> >
> > >> > ctx.node.attributes['map']['key'] = 'value'
> > >> >
> > >> > “map” is a name of an attribute which holds a dict, “key” is a
> > >> > key in
> > >> that
> > >> > dict.
> > >> > ​
> > >> >
> > >> > On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran <
> > >> > d.jayachand...@ericsson.com
> > >> > > wrote:
> > >> >
> > >> > > Hi Max,
> > >> > >
> > >> > > I see the runtime_properties have been replaced with "attributes"
> > >> > > and there has been multiple changes with respect to attribute
> > handling.
> > >> > >
> > >> > > What do you refer by "map" in your below example, Is that a
> > >> > > keyword
> > ?
> > >> > > "ctx.node.attributes['map']['key'] = value"
> > >> > >
> > >> > > Also with runtime_properties plugins were able to update the
> > >> > > database
> > >> > wi

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

>From within any operation or workflow you don't need to use the ".value"
notation. In order to access the attribute use ctx.node.attributes['test'],
and in order to assign the attribute just use ctx.node.attributes['test'] =
"abc". Using this (hopefully simplified) notation does all the model
related operations for you.

On Mon, Jul 31, 2017, 15:02 D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Max,
>
> Adding to this , I can access the attributes in my plugin only as below. (
> I have defined the attribute test in my node type )
>
> ctx.node.attributes['test'].value
>
> And to update the value
>
> ctx.node.attributes['test'].value = "abc"
>
> But this does not update the db. Am I missing something here in-terms of
> the context usage ?
>
>
> Regards,
> DJ
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Sunday, July 30, 2017 7:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell scripts
>
> Sorry it took me so long to check it out, things have been kind of hectic.
> Anyway, there is a JIRA issue opened just for that:
> https://issues.apache.org/jira/browse/ARIA-263.
>
> On Tue, Jul 25, 2017 at 9:23 PM, Maxim Orlov <ma...@cloudify.co> wrote:
>
> > Not entirely sure about that actually, let me double check that.
> >
> > On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> >> It should be impossible in TOSCA to create an attribute that was not
> >> declared at the type. Are we allowing users to create any ad hoc
> >> attribute?
> >>
> >> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co> wrote:
> >>
> >> > Indeed runtime_properties became attributes in ARIA . As for the
> >> behavior,
> >> > attributes behave just as a dict would (behind the scenes
> >> > attributes translate to a proper Attribute TOSCA model).
> >> > No need to define the attributes on the node-type level, if an
> >> > attribute with that name exists in on the model, the value of that
> >> > attribute
> >> would be
> >> > overridden, if you are creating a whole new attribute, a proper
> >> Attribute
> >> > model would be created for you.
> >> >
> >> > as for:
> >> >
> >> > ctx.node.attributes['map']['key'] = 'value'
> >> >
> >> > “map” is a name of an attribute which holds a dict, “key” is a key
> >> > in
> >> that
> >> > dict.
> >> > ​
> >> >
> >> > On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran <
> >> > d.jayachand...@ericsson.com
> >> > > wrote:
> >> >
> >> > > Hi Max,
> >> > >
> >> > > I see the runtime_properties have been replaced with "attributes"
> >> > > and there has been multiple changes with respect to attribute
> handling.
> >> > >
> >> > > What do you refer by "map" in your below example, Is that a keyword
> ?
> >> > > "ctx.node.attributes['map']['key'] = value"
> >> > >
> >> > > Also with runtime_properties plugins were able to update the
> >> > > database
> >> > with
> >> > > new key=value. Can we achieve the same with attributes ?
> >> > > Do we need to define the attributes in the node-types to be able
> >> > > to
> >> > update
> >> > > them by the plugins ?
> >> > >
> >> > > Regards,
> >> > > DJ
> >> > >
> >> > > -Original Message-
> >> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> >> > > Sent: Tuesday, July 25, 2017 11:23 AM
> >> > > To: dev@ariatosca.incubator.apache.org
> >> > > Subject: RE: Inputs and Node object context for python and shell
> >> scripts
> >> > >
> >> > > Hi Max,
> >> > >
> >> > > Yes I can access the context ctx with a python plugin and shell
> >> script as
> >> > > you have mentioned.
> >> > > But with python script .py files under implementation, am not
> >> > > sure if
> >> the
> >> > > ctx and inputs are passed as "globals". I will re-confirm this.
> >> > > The inputs which I was referring here were the lifecycle
> >

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Sorry it took me so long to check it out, things have been kind of hectic.
Anyway, there is a JIRA issue opened just for that:
https://issues.apache.org/jira/browse/ARIA-263.

On Tue, Jul 25, 2017 at 9:23 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> Not entirely sure about that actually, let me double check that.
>
> On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> It should be impossible in TOSCA to create an attribute that was not
>> declared at the type. Are we allowing users to create any ad hoc
>> attribute?
>>
>> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co> wrote:
>>
>> > Indeed runtime_properties became attributes in ARIA . As for the
>> behavior,
>> > attributes behave just as a dict would (behind the scenes attributes
>> > translate to a proper Attribute TOSCA model).
>> > No need to define the attributes on the node-type level, if an attribute
>> > with that name exists in on the model, the value of that attribute
>> would be
>> > overridden, if you are creating a whole new attribute, a proper
>> Attribute
>> > model would be created for you.
>> >
>> > as for:
>> >
>> > ctx.node.attributes['map']['key'] = 'value'
>> >
>> > “map” is a name of an attribute which holds a dict, “key” is a key in
>> that
>> > dict.
>> > ​
>> >
>> > On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran <
>> > d.jayachand...@ericsson.com
>> > > wrote:
>> >
>> > > Hi Max,
>> > >
>> > > I see the runtime_properties have been replaced with "attributes" and
>> > > there has been multiple changes with respect to attribute handling.
>> > >
>> > > What do you refer by "map" in your below example, Is that a keyword ?
>> > > "ctx.node.attributes['map']['key'] = value"
>> > >
>> > > Also with runtime_properties plugins were able to update the database
>> > with
>> > > new key=value. Can we achieve the same with attributes ?
>> > > Do we need to define the attributes in the node-types to be able to
>> > update
>> > > them by the plugins ?
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > > -Original Message-
>> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
>> > > Sent: Tuesday, July 25, 2017 11:23 AM
>> > > To: dev@ariatosca.incubator.apache.org
>> > > Subject: RE: Inputs and Node object context for python and shell
>> scripts
>> > >
>> > > Hi Max,
>> > >
>> > > Yes I can access the context ctx with a python plugin and shell
>> script as
>> > > you have mentioned.
>> > > But with python script .py files under implementation, am not sure if
>> the
>> > > ctx and inputs are passed as "globals". I will re-confirm this.
>> > > The inputs which I was referring here were the lifecycle operation
>> > inputs.
>> > >
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > > -Original Message-
>> > > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
>> > > Sent: Tuesday, July 25, 2017 12:14 AM
>> > > To: dev@ariatosca.incubator.apache.org
>> > > Subject: Re: Inputs and Node object context for python and shell
>> scripts
>> > >
>> > > I'm not entirely sure to which inputs you are referring to, but any
>> ctx
>> > > attribute or method accessible from a python script is accessible form
>> > any
>> > > shell script. For example:
>> > >
>> > >- "ctx.node.attributes['map']['key']" (in python) is "ctx node
>> > >attributes map.key" (under bash)
>> > >- "ctx.node.attributes['map']['key'] = value" (in python) is "ctx
>> > node
>> > >attributes map.key value" (under bash)
>> > >- "ctx.logger.info('some message')" (in python) is "ctx logger
>> info
>> > >'some message'" (under bash)
>> > >
>> > >
>> > > On Mon, Jul 24, 2017 at 8:47 PM, Tal Liron <t...@gigaspaces.com>
>> wrote:
>> > >
>> > > > I'm pretty sure you can access the inputs via the ctx call. Can
>> anyone
>> > > > confirm how to do this?
>> > > >
>> > > > We really need to document ctx usage...
>> > > >
>> > > > On Mon, Jul 24, 2017 at 5:57 AM, D Jayachandran <
>> > > > d.jayachand...@ericsson.com
>> > > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > With current ARIA implementation, the python and shell scripts are
>> > > > > being executed by the "execution plugin".
>> > > > >
>> > > > > The context object and inputs are not passed to passed to python
>> > > scripts.
>> > > > > We would like this to be passed to the python scripts.
>> > > > > For shell scripts atleast the inputs needs to be passed. The
>> context
>> > > > > object can be accessed via client.py with the SOCKET URL.
>> > > > > Kindly let us know if this can be added as a JIRA issue ?
>> > > > >
>> > > > >
>> > > > > Regards,
>> > > > > DJ
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: Openstack plugin

[Maxim Orlov]

you got most of it right :). You would need to follow these steps:
1. Install the adapter
2. Using ARIA, Install the wagon of the plugin.
3. Utilize the corresponding plugin.yaml found in the repo in your
templates.

The reason the adapter does not come with ARIA is it's an adapter for
Cloudify based plugins, and hence it cannot be a part of the ARIA code
base.
In the future ARIA would have its own plugins, and will not need the
adapter for Cloudify plugins.

On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

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

Re: Unique identification of an instance element across services

[Maxim Orlov]

Technically we have no issue with implementing this via uuid or a
threadsafe solution for the current index implementation.

Getting node data via the cli feels more intuitive using the index based
ID, rather than the uuid based ID in my opionion.

On Jul 25, 2017 9:49 PM, "Tal Liron" <t...@cloudify.co> wrote:

Our code for determining the next index is not concurrently safe (no atomic
transaction) so I can see it breaking in concurrent use cases (running two
ARIA commands at the same time).

What is to gain here in terms of human readability? In my opinion it adds
confusion because it gives a false sense of predictability.

In my opinion the best compromise is to use base57-encoded UUIDs. These are
true UUIDs, but use a mix of upper and lowercase alphanumerics ensuring no
visually ambiguous characters. We have the code for this in utils/uuid.py.

See also: https://github.com/wyattisimo/base57-ruby

On Tue, Jul 25, 2017 at 1:28 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> Actually the refactoring was made so the id would be more user readable.
> The index is determined according to the used indices (it's not just a
> running number). If indeed this poses an issue (or if indeed a uuid is
> easier to recognize, or even use in a query), let's discuss it further...
>
> On Tue, Jul 25, 2017 at 7:35 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > We used to use UUIDs but at some point this was refactored. I tend to
> agree
> > with you.
> >
> > Actually, I would prefer it to be configurable. We have code in place
for
> > ID generation of various types: UUIDs, short UUIDs, and sequentials. All
> of
> > them would seem useful to me for various scenarios.
> >
> > On Tue, Jul 25, 2017 at 3:42 AM, Vaishnavi K.R <
> vaishnavi@ericsson.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > >
> > > With my understanding in current ARIA, the node instances are made
> unique
> > > by prefixing the node name with the 'id of the service' (i.e. the
> primary
> > > key of the service table) as the instances are specific to the
service.
> > >
> > >
> > > What will be the name of the node instances if the default instances
> for
> > > the node template is '3' and how this will hold good during scale in
> and
> > > out?
> > >
> > >
> > > Could UUID be of great help in handling such cases by including that
> as a
> > > column in the database tables of the service and the node?
> > >
> > > This will wipe out the naming confusions and querying can be made easy
> > > with the UUIDs.
> > >
> > >
> > > Looking forward to your suggestion.
> > >
> > >
> > > Thanks,
> > >
> > > /Vaish
> > >
> >
>

Re: Unique identification of an instance element across services

[Maxim Orlov]

Actually the refactoring was made so the id would be more user readable.
The index is determined according to the used indices (it's not just a
running number). If indeed this poses an issue (or if indeed a uuid is
easier to recognize, or even use in a query), let's discuss it further...

On Tue, Jul 25, 2017 at 7:35 PM, Tal Liron  wrote:

> We used to use UUIDs but at some point this was refactored. I tend to agree
> with you.
>
> Actually, I would prefer it to be configurable. We have code in place for
> ID generation of various types: UUIDs, short UUIDs, and sequentials. All of
> them would seem useful to me for various scenarios.
>
> On Tue, Jul 25, 2017 at 3:42 AM, Vaishnavi K.R  >
> wrote:
>
> > Hi,
> >
> >
> > With my understanding in current ARIA, the node instances are made unique
> > by prefixing the node name with the 'id of the service' (i.e. the primary
> > key of the service table) as the instances are specific to the service.
> >
> >
> > What will be the name of the node instances if the default instances for
> > the node template is '3' and how this will hold good during scale in and
> > out?
> >
> >
> > Could UUID be of great help in handling such cases by including that as a
> > column in the database tables of the service and the node?
> >
> > This will wipe out the naming confusions and querying can be made easy
> > with the UUIDs.
> >
> >
> > Looking forward to your suggestion.
> >
> >
> > Thanks,
> >
> > /Vaish
> >
>

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Not entirely sure about that actually, let me double check that.

On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:

> It should be impossible in TOSCA to create an attribute that was not
> declared at the type. Are we allowing users to create any ad hoc attribute?
>
> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co> wrote:
>
> > Indeed runtime_properties became attributes in ARIA . As for the
> behavior,
> > attributes behave just as a dict would (behind the scenes attributes
> > translate to a proper Attribute TOSCA model).
> > No need to define the attributes on the node-type level, if an attribute
> > with that name exists in on the model, the value of that attribute would
> be
> > overridden, if you are creating a whole new attribute, a proper Attribute
> > model would be created for you.
> >
> > as for:
> >
> > ctx.node.attributes['map']['key'] = 'value'
> >
> > “map” is a name of an attribute which holds a dict, “key” is a key in
> that
> > dict.
> > ​
> >
> > On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Max,
> > >
> > > I see the runtime_properties have been replaced with "attributes" and
> > > there has been multiple changes with respect to attribute handling.
> > >
> > > What do you refer by "map" in your below example, Is that a keyword ?
> > > "ctx.node.attributes['map']['key'] = value"
> > >
> > > Also with runtime_properties plugins were able to update the database
> > with
> > > new key=value. Can we achieve the same with attributes ?
> > > Do we need to define the attributes in the node-types to be able to
> > update
> > > them by the plugins ?
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > > Sent: Tuesday, July 25, 2017 11:23 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: RE: Inputs and Node object context for python and shell
> scripts
> > >
> > > Hi Max,
> > >
> > > Yes I can access the context ctx with a python plugin and shell script
> as
> > > you have mentioned.
> > > But with python script .py files under implementation, am not sure if
> the
> > > ctx and inputs are passed as "globals". I will re-confirm this.
> > > The inputs which I was referring here were the lifecycle operation
> > inputs.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > > Sent: Tuesday, July 25, 2017 12:14 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Inputs and Node object context for python and shell
> scripts
> > >
> > > I'm not entirely sure to which inputs you are referring to, but any ctx
> > > attribute or method accessible from a python script is accessible form
> > any
> > > shell script. For example:
> > >
> > >- "ctx.node.attributes['map']['key']" (in python) is "ctx node
> > >attributes map.key" (under bash)
> > >- "ctx.node.attributes['map']['key'] = value" (in python) is "ctx
> > node
> > >attributes map.key value" (under bash)
> > >- "ctx.logger.info('some message')" (in python) is "ctx logger info
> > >'some message'" (under bash)
> > >
> > >
> > > On Mon, Jul 24, 2017 at 8:47 PM, Tal Liron <t...@gigaspaces.com> wrote:
> > >
> > > > I'm pretty sure you can access the inputs via the ctx call. Can
> anyone
> > > > confirm how to do this?
> > > >
> > > > We really need to document ctx usage...
> > > >
> > > > On Mon, Jul 24, 2017 at 5:57 AM, D Jayachandran <
> > > > d.jayachand...@ericsson.com
> > > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > With current ARIA implementation, the python and shell scripts are
> > > > > being executed by the "execution plugin".
> > > > >
> > > > > The context object and inputs are not passed to passed to python
> > > scripts.
> > > > > We would like this to be passed to the python scripts.
> > > > > For shell scripts atleast the inputs needs to be passed. The
> context
> > > > > object can be accessed via client.py with the SOCKET URL.
> > > > > Kindly let us know if this can be added as a JIRA issue ?
> > > > >
> > > > >
> > > > > Regards,
> > > > > DJ
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Indeed runtime_properties became attributes in ARIA . As for the behavior,
attributes behave just as a dict would (behind the scenes attributes
translate to a proper Attribute TOSCA model).
No need to define the attributes on the node-type level, if an attribute
with that name exists in on the model, the value of that attribute would be
overridden, if you are creating a whole new attribute, a proper Attribute
model would be created for you.

as for:

ctx.node.attributes['map']['key'] = 'value'

“map” is a name of an attribute which holds a dict, “key” is a key in that
dict.
​

On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Max,
>
> I see the runtime_properties have been replaced with "attributes" and
> there has been multiple changes with respect to attribute handling.
>
> What do you refer by "map" in your below example, Is that a keyword ?
> "ctx.node.attributes['map']['key'] = value"
>
> Also with runtime_properties plugins were able to update the database with
> new key=value. Can we achieve the same with attributes ?
> Do we need to define the attributes in the node-types to be able to update
> them by the plugins ?
>
> Regards,
> DJ
>
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Tuesday, July 25, 2017 11:23 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Inputs and Node object context for python and shell scripts
>
> Hi Max,
>
> Yes I can access the context ctx with a python plugin and shell script as
> you have mentioned.
> But with python script .py files under implementation, am not sure if the
> ctx and inputs are passed as "globals". I will re-confirm this.
> The inputs which I was referring here were the lifecycle operation inputs.
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> Sent: Tuesday, July 25, 2017 12:14 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell scripts
>
> I'm not entirely sure to which inputs you are referring to, but any ctx
> attribute or method accessible from a python script is accessible form any
> shell script. For example:
>
>- "ctx.node.attributes['map']['key']" (in python) is "ctx node
>attributes map.key" (under bash)
>- "ctx.node.attributes['map']['key'] = value" (in python) is "ctx node
>attributes map.key value" (under bash)
>- "ctx.logger.info('some message')" (in python) is "ctx logger info
>'some message'" (under bash)
>
>
> On Mon, Jul 24, 2017 at 8:47 PM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > I'm pretty sure you can access the inputs via the ctx call. Can anyone
> > confirm how to do this?
> >
> > We really need to document ctx usage...
> >
> > On Mon, Jul 24, 2017 at 5:57 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi,
> > >
> > > With current ARIA implementation, the python and shell scripts are
> > > being executed by the "execution plugin".
> > >
> > > The context object and inputs are not passed to passed to python
> scripts.
> > > We would like this to be passed to the python scripts.
> > > For shell scripts atleast the inputs needs to be passed. The context
> > > object can be accessed via client.py with the SOCKET URL.
> > > Kindly let us know if this can be added as a JIRA issue ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > >
> > >
> > >
> >
>

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

I'm not entirely sure to which inputs you are referring to, but any ctx
attribute or method accessible from a python script is accessible form any
shell script. For example:

   - "ctx.node.attributes['map']['key']" (in python) is "ctx node
   attributes map.key" (under bash)
   - "ctx.node.attributes['map']['key'] = value" (in python) is "ctx node
   attributes map.key value" (under bash)
   - "ctx.logger.info('some message')" (in python) is "ctx logger info
   'some message'" (under bash)


On Mon, Jul 24, 2017 at 8:47 PM, Tal Liron  wrote:

> I'm pretty sure you can access the inputs via the ctx call. Can anyone
> confirm how to do this?
>
> We really need to document ctx usage...
>
> On Mon, Jul 24, 2017 at 5:57 AM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > With current ARIA implementation, the python and shell scripts are being
> > executed by the "execution plugin".
> >
> > The context object and inputs are not passed to passed to python scripts.
> > We would like this to be passed to the python scripts.
> > For shell scripts atleast the inputs needs to be passed. The context
> > object can be accessed via client.py with the SOCKET URL.
> > Kindly let us know if this can be added as a JIRA issue ?
> >
> >
> > Regards,
> > DJ
> >
> >
> >
> >
>

Re: Openstack plugin

[Maxim Orlov]

Hey DJ,

Basically ARIA indeed has an adapter for cloudify-based plugins. This
enables support for any cloudify plugins (Provided the plugin.yaml has been
translated into TOSCA). Note that later on, ARIA will have native plugins
and will not rely on kindness of Cloudify.
You can find the Cloudify repo here
. It holds some
examples, the plugin.yaml and the adapter itself.

On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran  wrote:

> Thanks for the information Tal.  What is the adapter which you are
> referring here ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Friday, July 21, 2017 8:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Openstack plugin
>
> ARIA has an adapter that can use Cloudify plugins, and it has been tested
> successfully with both OpenStack and AWS so far.
>
> Unfortunately there are no instructions on how to use it. I know just the
> right person to write it and will ask him to do so. :)
>
> On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Will openstack plugin be available as part of any ARIA release ?
> > Is this already been looked upon or in the backlog ?
> >
> >
> > Regards,
> > DJ
> >
>

Re: async execution/task management

[Maxim Orlov]

However, note that since each process creates its own workflow_runner (and
consequently a new engine), starting and ending the workflow_runner should
be done from the same process.

On Thu, Jul 13, 2017 at 11:39 AM Maxim Orlov <ma...@gigaspaces.com> wrote:

> The execution id is indeed the linking factor between all execution
> related operations. ARIA doesn't provide asynchronous execution based
> operations. However, here
> <https://github.com/apache/incubator-ariatosca/blob/master/aria/cli/commands/executions.py#L204>
> you can see how ARIA runs executions in an asynchronous manner.
>
> On Wed, Jul 12, 2017 at 9:54 PM DeWayne Filppi <dewa...@gigaspaces.com>
> wrote:
>
>> I need to:
>>
>> 1. Launch an execution asynchronously
>> 2. View the execution status asynchronously
>> 3. Cancel the execution asynchronously
>>
>> I'm assuming the execution id is the key linking these.  Is this kind of
>> operation supported by the library, or is it assumed that the caller will
>> manage such ( e.g. by calling synchronous library calls in their own
>> threads and managing the thread externally)?  If possible with the
>> library,
>> is there an example?
>>
>> -- DeWayne
>>
>

Re: async execution/task management

[Maxim Orlov]

The execution id is indeed the linking factor between all execution related
operations. ARIA doesn't provide asynchronous execution based operations.
However, here

you can see how ARIA runs executions in an asynchronous manner.

On Wed, Jul 12, 2017 at 9:54 PM DeWayne Filppi 
wrote:

> I need to:
>
> 1. Launch an execution asynchronously
> 2. View the execution status asynchronously
> 3. Cancel the execution asynchronously
>
> I'm assuming the execution id is the key linking these.  Is this kind of
> operation supported by the library, or is it assumed that the caller will
> manage such ( e.g. by calling synchronous library calls in their own
> threads and managing the thread externally)?  If possible with the library,
> is there an example?
>
> -- DeWayne
>

Re: [VOTE] publish ariatosca 0.1.1

[Maxim Orlov]

   1. Validated signature & checksums
   2. Validated LICENSE, NOTICE, DISCLAIMER, "-incubating" in file name
   3. Ran RAT check
   4. Made a clean install using "pip install ."
   5. Ran tests using "make test"

+1

On Tue, Jul 11, 2017 at 2:27 AM, Suneel Marthi  wrote:

> +1 binding
>
> 1. Checked Sigs and Hashes
> 2. Verified RAT check
>
>
> On Mon, Jul 10, 2017 at 1:04 PM, Ran Ziv  wrote:
>
> > This is a vote to release Apache AriaTosca (Incubating) 0.1.1.
> > 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.1.1 release and placed it in
> ARIA's
> > /dist/dev folder:
> > *https://dist.apache.org/repos/dist/dev/incubator/
> > ariatosca/0.1.1-incubating/
> >  > ariatosca/0.1.1-incubating/>*
> >
> > The directory contains three packages:
> > source - The canonical Apache release - a snapshot of the repository.
> > sdist - The pythonic source distribution - contains generated docs,
> > examples, and files needed for install from source (yet doesn't contain
> > tests etc.).
> > bdist - The pythonic binary distribution - contains compiled code.
> >
> >
> > The sdist and bdist packages have been uploaded to test-PyPI:
> > https://test.pypi.org/project/apache-ariatosca/0.1.1/
> >
> >
> > The list of issues Resolved for this release can be found in the
> CHANGELOG
> > or here:
> >  > 1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)>
> > https://issues.apache.org/jira/browse/ARIA-312?filter=-
> > 1=project%3Dariatosca%20and%20status%20in%20(
> > resolved%2C%20closed)%20and%20fixVersion%3D0.1.1
> >
> >
> > Instructions for installation etc. may be found in the README file inside
> > the tarball.
> > (Please note that the relevant installation instructions are for "source
> > installation", not "install from PyPI")
> >
> >
> > To use RAT to validate package conformance with ASF standards, please use
> > the ".rat-excludes" file, for example:
> > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
> >
> >
> >
> > The vote will last 72 hours.
> >
> > Please vote:
> >
> > [ ] +1: Good to go!
> > [ ] 0: I don't care
> > [ ] -1: Don't release this because...
> >
> >
> > Thanks,
> > Ran
> >
>

Re: How can I use aria CLI options correctly?

[Maxim Orlov]

In order to get a more detailed message, you could use the verbosity flag -
"-v". This flag is supported both for the execution start command and the
logs list command. What you would want to do at this stage is try and
figure out what happend with the execution you already ran. In order to do
that, locate your execution id via "aria executions list", and then use the
list logs command "aria logs list -e  -vvv".

On Mon, Jun 12, 2017, 06:43 Chen, Wei D  wrote:

> Hi Ran,
>
> Thank you for your help! Here comes another issue when I run the "*aria
> services create hello-service -t hello* *aria executions start install -s
> hello-service*", the console shows me the below message:
> "
> Starting execution. Press Ctrl+C cancel
> 10:29:43 | I | Starting 'install' workflow execution
> 10:29:51 | I | web_app_1 Standard.configure started...
> 10:29:51 | I | Executing: /tmp/tmpeuRKHt-configure.sh
> 10:29:52 | I | Execution done (exit_code=1): /tmp/tmpeuRKHt-configure.sh
> 10:29:52 | E | web_app_1 Standard.configure failed
> 10:30:24 | I | web_app_1 Standard.configure started...
> 10:30:24 | I | Executing: /tmp/tmpvwDbY0-configure.sh
> 10:30:25 | I | Execution done (exit_code=1): /tmp/tmpvwDbY0-configure.sh
> 10:30:25 | E | web_app_1 Standard.configure failed"
>
> I have no idea why the configuration is failed, any way to trouble
> shooting the issue or where can I find more detailed error message?
>
> > -Original Message-
> > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > Sent: Friday, June 9, 2017 4:42 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: How can I use aria CLI options correctly?
> >
> > (I've replied on this same mail two days ago, so I guess there's been
> some sort
> > of a mistake. In any case, I've copy-pasted my reply here as well.)
> >
> > Hi Dave,
> >
> > Unfortunately, the README is currently much outddated. That is why the
> "aria
> > parse" command raises an invalid command error.
> >
> > We're working on updating the quick start guide, and hopefully it'll be
> up to date
> > early next week, although that too isn't going to provide a full
> documentation at
> > this time to ARIA but rather only an introduction.
> > In the meanwhile however, we'll be glad to help over on this mailing
> list.
> >
> >
> > The "parse" command indeed no longer exists; Similar functionality can
> be found
> > under "aria service-templates show", but first one has to use "aria
> service-
> > templates store", like so:
> > *aria service-templates store node-cellar.yaml nodecellar* *aria service-
> > templates show nodecellar -f*
> >
> >
> > To actually run workflows etc., you'd have to first create a service for
> a given
> > service-template, e.g.:
> > *aria service-templates store examples/hello-world/helloworld.yaml hello*
> > *aria services create hello-service -t hello* *aria executions start
> install -s hello-
> > service*
> >
> >
> >
> > hope this helps.
> >
> > On Fri, Jun 9, 2017 at 10:34 AM, Chen, Wei D 
> wrote:
> >
> > > Dear developers,
> > >
> > > I am currently on ARIA, and is trying to follow the quickstack guide
> > > from this post (https://github.com/apache/incubator-ariatosca), but I
> > > am lost there since the CLI option mentioned in the guide is supported
> yet.
> > >
> > > It said the below command can create a service instance, but seems
> > > like "parse" is not a valid option.
> > > - aria parse blueprints/tosca/node-cellar/node-cellar.yaml
> > >
> > > This is help manual I can see:
> > > $ aria -h
> > > Usage: aria [OPTIONS] COMMAND [ARGS]...
> > >
> > > ARIA's Command Line Interface
> > >
> > > To activate bash-completion. Run: eval "$(_ARIA_COMPLETE=source aria)"
> > >
> > > ARIA's working directory resides by default in ~/.aria. To change it,
> > > set the environment variable ARIA_WORKDIR to something else (e.g.
> /tmp/).
> > >
> > > Options:
> > > -v, --verbose Show verbose output. You can supply this up to three
> > > times (i.e. -vvv) --version Display the version and exit -h, --help
> > > Show this message and exit.
> > >
> > > Commands:
> > > executions Handle workflow executions
> > > logs Show logs from workflow executions node-templates Handle a
> > > service template's node templates nodes Handle a service's nodes
> > > plugins Handle plugins reset Reset ARIA's working directory
> > > service-templates Handle service templates on the manager services
> > > Handle services workflows Handle service workflows
> > >
> > > There is no "parse" option list there. I have also tried the
> > > installation via 'pip' with version 0.1,  and this is what I can see:
> > > $ aria node-cellar.yaml
> > > Validation issues:
> > >   0: location: aria-1.0
> > >  ReaderNotFoundError: location: aria-1.0
> > >
> > >
> > > So, what the error here means? How can I fix it?
> > >
> > > This is how the imports defined in the "node-cellar.yaml" from the
> > > code base.
> > > imports:
> > >   - types/openstack.yaml
> > >   - 

Re: [UPDATE] Work on ARIA-149: Support intrinsic functions in "dependencies" operation configuration

[Maxim Orlov]

Not entirely sure why the "implementation" gets its own field. It basically
another input to the operation. Though it's a special input (since it
enables for the plugin do decide which "function" to run), it's still an
inputs.  feel we already have a lot of different possible inputs to an
operation: (1) interface inputs, (2) operation inputs (3) task inputs. I
feel that the "implementation" should have a special place under the
operation inputs, but not a field on its own...

On Thu, May 25, 2017 at 1:22 AM, Tal Liron  wrote:

> We had a long face-to-face today and reached an alignment. ARIA-149 is
> being updated to reflect it.
>
> So, we are going all the way with this:
>
> The "implementation" and "inputs" fields in the models refer *only* to what
> comes from the TOSCA parser. They are passed from template to instance as
> is. This means that "implementation" should always be considered an
> artifact name. (Indeed, when we implement artifact in the near future, this
> field may be refactored in some way, possibly to become a foreign key to an
> artifact-related model.)
>
> The OperationTemplate and Operation models both also have a "configuration"
> field, a dict of special parameters used as hints for orchestration. The
> parser can generate them using our magical "dependencies" grammar
> extensions. They are normal parameters (typed, and can contain intrinsic
> functions).
>
> And, we are introducing two *new* fields to Operation and Task models (and
> the related Task API): "function" and "arguments". "function" is the full
> path to a Python function, and "arguments" is a dict of parameters that are
> sent as arguments to the function. These are ARIA's implementation details
> for orchestration, and are *not* directly related to TOSCA's
> "implementation" and "inputs" fields, and indeed the Task model does not
> have nor need the "implementation" and "inputs" (to put it another way:
> we've renamed these two fields in Task, but they have the exact same usage
> as before).
>
> The logic for tasks has not changed, but let's go over it again for
> clarification with the new fields in mind:
>
>1. The parser generates an OperationTemplate model, and sets the
>"implementation" and "inputs" fields. Two ARIA grammar extensions
>optionally apply:
>1. If the ">" is used in the "implementation", then the parser actually
>   leaves "implementation" empty (there is no artifact) and instead sets
>   "function".
>   2. If the ">" is used in "dependencies", they are converted to
>   "configuration".
>   2. During instantiation, all these fields are copied as is from
>OperationTemplate to Operation.
>3. During the configuration phase of instantiation, there are two
>possible routes:
>   1. For the default execution plugin, it generates "function" and
>   "arguments" according to whether the operation is local or remote,
> using
>   params from "configuration" if they are available (and valid). Also,
> any
>   extra "configuration" params set by the user, which are not
> recognized by
>   the plugin, just get appended to "arguments".
>   2. For other plugins, we already have "function" set for us by the
>   parser (according to what the user put in "implementation" after
> the ">").
>   So, we just append all "configuration" params if they exist to
> "arguments"
>4. For all plugins, "inputs" are also appended to "arguments".
>
> Some implications of this logic worth considering:
>
>1. "implementation" and "inputs" are never mangled and always adhere to
>the strict TOSCA typed interface contract.
>2. It's possible to use our special "dependencies" grammar to send
> *extra
>arbitrary* arguments to the Python operation function, *beyond* what is
>allowed by the strict TOSCA contract.
>3. Python operation functions do not have a way to know which arguments
>came from where: some arguments might be inputs and some might be extra
>configuration. We have currently decided that this distinguishes the
> two is
>cumbersome and not useful. If it does become important, we will need to
>revisit this logic.
>
>
> On Tue, May 23, 2017 at 11:09 AM, Tal Liron  wrote:
>
> > Why do you think that on-the-fly updates won't require implementation and
> > inputs? It's true that the execution plugin squashes inputs into
> arguments
> > and keeps the implementation in arguments.process.script_path, but that's
> > an implementation detail. Some plugins may care more about what is an
> input
> > and what isn't, or do other kinds of mangling to the implementation. In
> any
> > case, the user should have to know how to massage these values: they can
> > set up inputs and possibly configuration (same way as in TOSCA) and then
> > call Operation.configure to do the right thing.
> >
> > The implementation and function are not the same, as you can see even in
> > my trivial example. 

[jira] [Created] (ARIA-248) When applying tracked changes fails no message is returned

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-248:


 Summary: When applying tracked changes fails no message is returned
 Key: ARIA-248
 URL: https://issues.apache.org/jira/browse/ARIA-248
 Project: AriaTosca
  Issue Type: Bug
Reporter: Maxim Orlov


When the instumentation module tries to apply tracked changes, and it fails, it 
should print out the attributes it did manage to update. However, if one of 
those attributes is a _STUB (which is an object() type object), json.dumps 
fails to decode it. 
https://github.com/apache/incubator-ariatosca/blob/master/aria/storage/instrumentation.py#L259

This prevents from any msg to be returned.



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

[jira] [Resolved] (ARIA-160) Operation toolbelt unit tests fail spordically

[Maxim Orlov (JIRA)]

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

Maxim Orlov resolved ARIA-160.
--
Resolution: Fixed

> Operation toolbelt unit tests fail spordically
> --
>
> Key: ARIA-160
> URL: https://issues.apache.org/jira/browse/ARIA-160
> Project: AriaTosca
>  Issue Type: Bug
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
> Fix For: 0.1.0
>
>
> The unit tests in the module {{test_toolbelt.py}} fail remote builds 
> (TravisCI, Jenkins) sporadically.
> Stack trace:
> {code}
> workflow_context = WorkflowContext(deployment_id=1, 
> workflow_name=test_workflow, execution_id=1)
> executor =  at 0x7f57f8482a50>
> def test_host_ip(workflow_context, executor):
> interface_name = 'Standard'
> operation_name = 'create'
> _, dependency_node, _, _, _ = _get_elements(workflow_context)
> inputs = {'putput': True}
> interface = mock.models.create_interface(
> dependency_node.service,
> interface_name=interface_name,
> operation_name=operation_name,
> operation_kwargs=dict(implementation=op_path(host_ip, 
> module_path=__name__),
>   inputs=inputs)
> )
> dependency_node.interfaces[interface.name] = interface
> workflow_context.model.node.update(dependency_node)
> 
> @workflow
> def basic_workflow(graph, **_):
> graph.add_tasks(
> api.task.OperationTask.for_node(
> node=dependency_node,
> interface_name=interface_name,
> operation_name=operation_name,
> inputs=inputs
> )
> )
> 
> >   execute(workflow_func=basic_workflow, 
> > workflow_context=workflow_context, executor=executor)
> tests/orchestrator/context/test_toolbelt.py:101: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> tests/orchestrator/context/__init__.py:29: in execute
> eng.execute()
> aria/orchestrator/workflows/core/engine.py:59: in execute
> for task in self._ended_tasks():
> aria/orchestrator/workflows/core/engine.py:96: in 
> return (task for task in self._tasks_iter() if task.has_ended())
> aria/orchestrator/workflows/core/task.py:259: in __getattr__
> return getattr(self.model_task, attr)
> aria/orchestrator/workflows/core/task.py:178: in model_task
> return self._workflow_context.model.task.get(self._task_id)
> aria/storage/sql_mapi.py:59: in get
> result = query.first()
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2731: in first
> ret = list(self[0:1])
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2523: in 
> __getitem__
> return list(res)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2831: in 
> __iter__
> return self._execute_and_instances(context)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2854: in 
> _execute_and_instances
> result = conn.execute(querycontext.statement, self._params)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:945: in 
> execute
> return meth(self, multiparams, params)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/sql/elements.py:263: in 
> _execute_on_connection
> return connection._execute_clauseelement(self, multiparams, params)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1053: in 
> _execute_clauseelement
> compiled_sql, distilled_params
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1189: in 
> _execute_context
> context)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1393: in 
> _handle_dbapi_exception
> exc_info
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/util/compat.py:203: in 
> raise_from_cause
> reraise(type(exception), exception, tb=exc_tb, cause=cause)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1182: in 
> _execute_context
> context)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self =  0x7f57f97ee250>
> cursor = 
> statement = 'SELECT task.id AS task_id, task.name AS task_name, 
> task.implementation AS task_implementation, task.max_attempts AS t..._fk AS 
> task_execution_fk, task.relationship_fk AS task_relationship_fk 
> FROM task 
> WHERE task.id = ?
>  LIMIT ? OFFSET ?'
> parameter

[jira] [Resolved] (ARIA-165) Make node name suffix UUIDs become more readable

[Maxim Orlov (JIRA)]

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

Maxim Orlov resolved ARIA-165.
--
   Resolution: Fixed
Fix Version/s: 0.1.0

> Make node name suffix UUIDs become more readable
> 
>
> Key: ARIA-165
> URL: https://issues.apache.org/jira/browse/ARIA-165
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
> Fix For: 0.1.0
>
>
> Node names are currently constructed of the node template name with a UUID 
> suffix. While this makes the node name unique across all services, it also 
> makes the node names less readable, and since nodes are already unique via 
> their ID, it might be better to use a different type of suffix.
> One option would be to generate a shorter, no capital letters string, which 
> would be more readable, and (in very high probability) unique in a single 
> service.
> Another option would be to go for a running number suffix for each node of a 
> given node template, which could be simple, unique and readable.



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

[jira] [Resolved] (ARIA-230) Dry execution doesn't log empty operations

[Maxim Orlov (JIRA)]

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

Maxim Orlov resolved ARIA-230.
--
   Resolution: Fixed
Fix Version/s: 0.1.0

> Dry execution doesn't log empty operations
> --
>
> Key: ARIA-230
> URL: https://issues.apache.org/jira/browse/ARIA-230
> Project: AriaTosca
>  Issue Type: Bug
>Affects Versions: 0.1.0
>    Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Dry execution doesn't log empty operations



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

[jira] [Reopened] (ARIA-160) Operation toolbelt unit tests fail spordically

[Maxim Orlov (JIRA)]

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

Maxim Orlov reopened ARIA-160:
--

> Operation toolbelt unit tests fail spordically
> --
>
> Key: ARIA-160
> URL: https://issues.apache.org/jira/browse/ARIA-160
> Project: AriaTosca
>  Issue Type: Bug
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
> Fix For: 0.1.0
>
>
> The unit tests in the module {{test_toolbelt.py}} fail remote builds 
> (TravisCI, Jenkins) sporadically.
> Stack trace:
> {code}
> workflow_context = WorkflowContext(deployment_id=1, 
> workflow_name=test_workflow, execution_id=1)
> executor =  at 0x7f57f8482a50>
> def test_host_ip(workflow_context, executor):
> interface_name = 'Standard'
> operation_name = 'create'
> _, dependency_node, _, _, _ = _get_elements(workflow_context)
> inputs = {'putput': True}
> interface = mock.models.create_interface(
> dependency_node.service,
> interface_name=interface_name,
> operation_name=operation_name,
> operation_kwargs=dict(implementation=op_path(host_ip, 
> module_path=__name__),
>   inputs=inputs)
> )
> dependency_node.interfaces[interface.name] = interface
> workflow_context.model.node.update(dependency_node)
> 
> @workflow
> def basic_workflow(graph, **_):
> graph.add_tasks(
> api.task.OperationTask.for_node(
> node=dependency_node,
> interface_name=interface_name,
> operation_name=operation_name,
> inputs=inputs
> )
> )
> 
> >   execute(workflow_func=basic_workflow, 
> > workflow_context=workflow_context, executor=executor)
> tests/orchestrator/context/test_toolbelt.py:101: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> tests/orchestrator/context/__init__.py:29: in execute
> eng.execute()
> aria/orchestrator/workflows/core/engine.py:59: in execute
> for task in self._ended_tasks():
> aria/orchestrator/workflows/core/engine.py:96: in 
> return (task for task in self._tasks_iter() if task.has_ended())
> aria/orchestrator/workflows/core/task.py:259: in __getattr__
> return getattr(self.model_task, attr)
> aria/orchestrator/workflows/core/task.py:178: in model_task
> return self._workflow_context.model.task.get(self._task_id)
> aria/storage/sql_mapi.py:59: in get
> result = query.first()
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2731: in first
> ret = list(self[0:1])
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2523: in 
> __getitem__
> return list(res)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2831: in 
> __iter__
> return self._execute_and_instances(context)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2854: in 
> _execute_and_instances
> result = conn.execute(querycontext.statement, self._params)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:945: in 
> execute
> return meth(self, multiparams, params)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/sql/elements.py:263: in 
> _execute_on_connection
> return connection._execute_clauseelement(self, multiparams, params)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1053: in 
> _execute_clauseelement
> compiled_sql, distilled_params
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1189: in 
> _execute_context
> context)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1393: in 
> _handle_dbapi_exception
> exc_info
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/util/compat.py:203: in 
> raise_from_cause
> reraise(type(exception), exception, tb=exc_tb, cause=cause)
> .tox/py27/lib/python2.7/site-packages/sqlalchemy/engine/base.py:1182: in 
> _execute_context
> context)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> self =  0x7f57f97ee250>
> cursor = 
> statement = 'SELECT task.id AS task_id, task.name AS task_name, 
> task.implementation AS task_implementation, task.max_attempts AS t..._fk AS 
> task_execution_fk, task.relationship_fk AS task_relationship_fk 
> FROM task 
> WHERE task.id = ?
>  LIMIT ? OFFSET ?'
> parameters = (1, 1, 0)
> co

[jira] [Created] (ARIA-230) Dry execution doesn't log empty operations

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-230:


 Summary: Dry execution doesn't log empty operations
 Key: ARIA-230
 URL: https://issues.apache.org/jira/browse/ARIA-230
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Dry execution doesn't log empty operations



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

[jira] [Commented] (ARIA-165) Make node name suffix UUIDs become more readable

[Maxim Orlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIA-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16000785#comment-16000785
 ] 

Maxim Orlov commented on ARIA-165:
--

We can uitilze the SQLAlcehmy events mechanism, which could automate the name 
composition. However, this mechanism is a bit more complicated as it requires 
better knowledge of sqlalcehmy (and SQL). Example:
http://stackoverflow.com/questions/32277403/how-can-i-create-a-sqlalchemy-column-whose-default-is-to-be-equal-to-the-primary

Another optional fix is the use of the length of the list of the current nodes 
for the relevant node_template. This would enable easy suffices but once a node 
is deleted, a new node could get the old node's name. 
The latter is the current fix for this issue.

> Make node name suffix UUIDs become more readable
> 
>
> Key: ARIA-165
> URL: https://issues.apache.org/jira/browse/ARIA-165
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
>
> Node names are currently constructed of the node template name with a UUID 
> suffix. While this makes the node name unique across all services, it also 
> makes the node names less readable, and since nodes are already unique via 
> their ID, it might be better to use a different type of suffix.
> One option would be to generate a shorter, no capital letters string, which 
> would be more readable, and (in very high probability) unique in a single 
> service.
> Another option would be to go for a running number suffix for each node of a 
> given node template, which could be simple, unique and readable.



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

[jira] [Closed] (ARIA-214) Dry execution changes the state of non implemented operations

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-214.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Dry execution changes the state of non implemented operations
> -
>
> Key: ARIA-214
> URL: https://issues.apache.org/jira/browse/ARIA-214
> Project: AriaTosca
>  Issue Type: Bug
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> On dry runs, empty tasks are still being ran which changes the node states, 
> which they should now



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

[jira] [Updated] (ARIA-214) Dry execution changes the state of non implemented operations

[Maxim Orlov (JIRA)]

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

Maxim Orlov updated ARIA-214:
-
Summary: Dry execution changes the state of non implemented operations  
(was: Dry execution still change the state of non implemented operations)

> Dry execution changes the state of non implemented operations
> -
>
> Key: ARIA-214
> URL: https://issues.apache.org/jira/browse/ARIA-214
> Project: AriaTosca
>  Issue Type: Bug
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>
> On dry runs, empty tasks are still being ran which changes the node states, 
> which they should now



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

[jira] [Created] (ARIA-214) Dry execution still change the state of non implemented operations

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-214:


 Summary: Dry execution still change the state of non implemented 
operations
 Key: ARIA-214
 URL: https://issues.apache.org/jira/browse/ARIA-214
 Project: AriaTosca
  Issue Type: Bug
Reporter: Maxim Orlov
Assignee: Maxim Orlov


On dry runs, empty tasks are still being ran which changes the node states, 
which they should now



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

[jira] [Assigned] (ARIA-165) Make node name suffix UUIDs become more readable

[Maxim Orlov (JIRA)]

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

Maxim Orlov reassigned ARIA-165:


Assignee: Maxim Orlov

> Make node name suffix UUIDs become more readable
> 
>
> Key: ARIA-165
> URL: https://issues.apache.org/jira/browse/ARIA-165
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
>
> Node names are currently constructed of the node template name with a UUID 
> suffix. While this makes the node name unique across all services, it also 
> makes the node names less readable, and since nodes are already unique via 
> their ID, it might be better to use a different type of suffix.
> One option would be to generate a shorter, no capital letters string, which 
> would be more readable, and (in very high probability) unique in a single 
> service.
> Another option would be to go for a running number suffix for each node of a 
> given node template, which could be simple, unique and readable.



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

[jira] [Closed] (ARIA-163) Update node state for stub tasks

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-163.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Update node state for stub tasks
> 
>
> Key: ARIA-163
> URL: https://issues.apache.org/jira/browse/ARIA-163
> Project: AriaTosca
>  Issue Type: Story
>Affects Versions: 0.1.0
>    Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Currently each node that has no implementation for an operation, has its 
> operations labeled a stub tasks. Those stub tasks aren't run through the 
> normal path of the workflow engine, and thus no update to the state of the 
> node is being done. this should be fixed 



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

[jira] [Created] (ARIA-208) Missing backref for models

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-208:


 Summary: Missing backref for models
 Key: ARIA-208
 URL: https://issues.apache.org/jira/browse/ARIA-208
 Project: AriaTosca
  Issue Type: Bug
Reporter: Maxim Orlov
Priority: Minor


Some models in ARIA are missing backref fields. This should be according to the 
modeling document



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

[jira] [Created] (ARIA-163) Update node state for stub tasks

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-163:


 Summary: Update node state for stub tasks
 Key: ARIA-163
 URL: https://issues.apache.org/jira/browse/ARIA-163
 Project: AriaTosca
  Issue Type: Story
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Currently each node that has no implementation for an operation, has its 
operations labeled a stub tasks. Those stub tasks aren't run through the normal 
path of the workflow engine, and thus no update to the state of the node is 
being done. this should be fixed 



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

[jira] [Closed] (ARIA-147) Support auto-completion in CLI

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-147.

   Resolution: Fixed
Fix Version/s: 0.1.0

The current auto-completion supports only static bash completion. 
The current click framework does not provide a simple and elegant solution for 
dynamic auto-completion. 

> Support auto-completion in CLI
> --
>
> Key: ARIA-147
> URL: https://issues.apache.org/jira/browse/ARIA-147
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Add support for auto-completion in CLI:
> 1) commands/flags completion - (e.g. {{executions}}, {{--force}}, etc.)
> 2) Values completion - auto-complete possible values by querying the storage, 
> e.g. {{aria executions start -s my-service my-workflow}} - the 
> {{my-workflow}} workflow name should be able to auto-complete by querying the 
> service's workflows.



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

[jira] [Closed] (ARIA-158) Restore support for relationship ordering

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-158.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Restore support for relationship ordering
> -
>
> Key: ARIA-158
> URL: https://issues.apache.org/jira/browse/ARIA-158
> Project: AriaTosca
>  Issue Type: Bug
>Affects Versions: 0.1.0
>    Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>




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

[jira] [Closed] (ARIA-152) Openstack hello-world example

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-152.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Openstack hello-world example
> -
>
> Key: ARIA-152
> URL: https://issues.apache.org/jira/browse/ARIA-152
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Write an hello-world example which runs on Openstack, using the Openstack 
> plugin.



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

[jira] [Comment Edited] (ARIA-147) Support auto-completion in CLI

[Maxim Orlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980495#comment-15980495
 ] 

Maxim Orlov edited comment on ARIA-147 at 4/24/17 9:34 AM:
---

The commands auto completion is a builtin click feature. to activate it use 
{{eval "$(_ARIA_COMPLETE=source aria)"}}. 




was (Author: mxmrlv):
The commands auto completion is a builtin click feature. to activate it use 
{{export _ARIA_COMPLETE=source aria}}. 

> Support auto-completion in CLI
> --
>
> Key: ARIA-147
> URL: https://issues.apache.org/jira/browse/ARIA-147
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Maxim Orlov
>
> Add support for auto-completion in CLI:
> 1) commands/flags completion - (e.g. {{executions}}, {{--force}}, etc.)
> 2) Values completion - auto-complete possible values by querying the storage, 
> e.g. {{aria executions start -s my-service my-workflow}} - the 
> {{my-workflow}} workflow name should be able to auto-complete by querying the 
> service's workflows.



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

[jira] [Comment Edited] (ARIA-147) Support auto-completion in CLI

[Maxim Orlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980495#comment-15980495
 ] 

Maxim Orlov edited comment on ARIA-147 at 4/23/17 6:11 PM:
---

The commands auto completion is a builtin click feature. to activate it use 
{{export _ARIA_COMPLETE=source aria}}. 


was (Author: mxmrlv):
The commands auto completion is a builtin click feature. to activate it use 
```export _ARIA_COMPLETE=source aria```. 

> Support auto-completion in CLI
> --
>
> Key: ARIA-147
> URL: https://issues.apache.org/jira/browse/ARIA-147
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>
> Add support for auto-completion in CLI:
> 1) commands/flags completion - (e.g. {{executions}}, {{--force}}, etc.)
> 2) Values completion - auto-complete possible values by querying the storage, 
> e.g. {{aria executions start -s my-service my-workflow}} - the 
> {{my-workflow}} workflow name should be able to auto-complete by querying the 
> service's workflows.



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

[jira] [Commented] (ARIA-147) Support auto-completion in CLI

[Maxim Orlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980495#comment-15980495
 ] 

Maxim Orlov commented on ARIA-147:
--

The commands auto completion is a builtin click feature. to activate it use 
`export _ARIA_COMPLETE=source aria`. 

> Support auto-completion in CLI
> --
>
> Key: ARIA-147
> URL: https://issues.apache.org/jira/browse/ARIA-147
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>
> Add support for auto-completion in CLI:
> 1) commands/flags completion - (e.g. {{executions}}, {{--force}}, etc.)
> 2) Values completion - auto-complete possible values by querying the storage, 
> e.g. {{aria executions start -s my-service my-workflow}} - the 
> {{my-workflow}} workflow name should be able to auto-complete by querying the 
> service's workflows.



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

[jira] [Comment Edited] (ARIA-147) Support auto-completion in CLI

[Maxim Orlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980495#comment-15980495
 ] 

Maxim Orlov edited comment on ARIA-147 at 4/23/17 6:10 PM:
---

The commands auto completion is a builtin click feature. to activate it use 
```export _ARIA_COMPLETE=source aria```. 


was (Author: mxmrlv):
The commands auto completion is a builtin click feature. to activate it use 
`export _ARIA_COMPLETE=source aria`. 

> Support auto-completion in CLI
> --
>
> Key: ARIA-147
> URL: https://issues.apache.org/jira/browse/ARIA-147
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>
> Add support for auto-completion in CLI:
> 1) commands/flags completion - (e.g. {{executions}}, {{--force}}, etc.)
> 2) Values completion - auto-complete possible values by querying the storage, 
> e.g. {{aria executions start -s my-service my-workflow}} - the 
> {{my-workflow}} workflow name should be able to auto-complete by querying the 
> service's workflows.



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

[jira] [Created] (ARIA-144) sql_mapi raises an error in regards to date_time string

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-144:


 Summary: sql_mapi raises an error in regards to date_time string
 Key: ARIA-144
 URL: https://issues.apache.org/jira/browse/ARIA-144
 Project: AriaTosca
  Issue Type: Bug
Reporter: Maxim Orlov
Priority: Minor


provided the traceback:

tests/orchestrator/context/test_toolbelt.py:132: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/orchestrator/context/__init__.py:29: in execute
eng.execute()
aria/orchestrator/workflows/core/engine.py:60: in execute
for task in self._ended_tasks():
aria/orchestrator/workflows/core/engine.py:97: in 
return (task for task in self._tasks_iter() if task.has_ended())
aria/orchestrator/workflows/core/engine.py:110: in _tasks_iter
self._workflow_context.model.task.refresh(task.model_task)
aria/storage/sql_mapi.py:142: in refresh
self._load_relationships(entry)
aria/storage/sql_mapi.py:379: in _load_relationships
getattr(instance, rel.key)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/attributes.py:237: in 
__get__
return self.impl.get(instance_state(instance), dict_)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/attributes.py:584: in get
value = self.callable_(state, passive)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/strategies.py:557: in 
_load_for_state
return self._emit_lazyload(session, state, ident_key, passive)
:1: in 
???
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/strategies.py:603: in 
_emit_lazyload
return loading.load_on_ident(q, ident_key)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/loading.py:223: in 
load_on_ident
return q.one()
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2790: in one
ret = self.one_or_none()
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/query.py:2760: in 
one_or_none
ret = list(self)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/loading.py:90: in instances
util.raise_from_cause(err)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/util/compat.py:203: in 
raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/loading.py:75: in instances
rows = [proc(row) for row in fetch]
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/loading.py:437: in 
_instance
loaded_instance, populate_existing, populators)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
context = 
row = <[ValueError("Couldn't parse datetime string: u''") raised in repr()] 
SafeRepr object at 0x7f2074d11ea8>
state = 
dict_ = {'_sa_instance_state': }
isnew = True
load_path = EntityRegistry((,))
loaded_instance = True, populate_existing = False
populators = defaultdict(, {'quick': [('is_system_workflow', 
), ('created_at', )]})
def _populate_full(
context, row, state, dict_, isnew, load_path,
loaded_instance, populate_existing, populators):
if isnew:
# first time we are seeing a row with this identity.
state.runid = context.runid

for key, getter in populators["quick"]:
>   dict_[key] = getter(row)
E   ValueError: Couldn't parse datetime string: u''
.tox/py27/lib/python2.7/site-packages/sqlalchemy/orm/loading.py:498: ValueError



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

[jira] [Closed] (ARIA-142) defaults missing for execution plugin

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-142.

Resolution: Fixed

> defaults missing for execution plugin
> -
>
> Key: ARIA-142
> URL: https://issues.apache.org/jira/browse/ARIA-142
> Project: AriaTosca
>  Issue Type: Bug
>Affects Versions: 0.1.0
>    Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>
> execution plugin is missing default values for use_sudo and hide_output (both 
> are for fabric).



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

[jira] [Created] (ARIA-142) defaults missing for execution plugin

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-142:


 Summary: defaults missing for execution plugin
 Key: ARIA-142
 URL: https://issues.apache.org/jira/browse/ARIA-142
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


execution plugin is missing default values for use_sudo and hide_output (both 
are for fabric).



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

[jira] [Deleted] (ARIA-141) Implementation-less relationship tasks are being created.

[Maxim Orlov (JIRA)]

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

Maxim Orlov deleted ARIA-141:
-


> Implementation-less relationship tasks are being created.
> -
>
> Key: ARIA-141
> URL: https://issues.apache.org/jira/browse/ARIA-141
> Project: AriaTosca
>  Issue Type: Bug
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>
> Implementation-less tasks should not be created. If they do, the engine fails 
> to run since there is no implementation. 



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

[jira] [Closed] (ARIA-137) Support for predicate based queries in the SQL mapi

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-137.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Support for predicate based queries in the SQL mapi
> ---
>
> Key: ARIA-137
> URL: https://issues.apache.org/jira/browse/ARIA-137
> Project: AriaTosca
>  Issue Type: Story
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Currently the SQL mapi syntax doesn't provide with a way of predicate based 
> queries. we need to add support for gt, lt etc... (and a combinations of 
> them).



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

[jira] [Closed] (ARIA-136) ctx binary doesn't get installed via pip install

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-136.

   Resolution: Fixed
Fix Version/s: 0.1.0

> ctx binary doesn't get installed via pip install
> 
>
> Key: ARIA-136
> URL: https://issues.apache.org/jira/browse/ARIA-136
> Project: AriaTosca
>  Issue Type: Bug
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
> Fix For: 0.1.0
>
>
> the ctx binary is conditionally installed in {{setup.py}}, but it would seem 
> the {{pip install}} command does not install it as intended when installing 
> in editable mode ({{-e}} option)



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

[jira] [Assigned] (ARIA-136) ctx binary doesn't get installed via pip install

[Maxim Orlov (JIRA)]

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

Maxim Orlov reassigned ARIA-136:


Assignee: Maxim Orlov

> ctx binary doesn't get installed via pip install
> 
>
> Key: ARIA-136
> URL: https://issues.apache.org/jira/browse/ARIA-136
> Project: AriaTosca
>  Issue Type: Bug
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>Priority: Minor
>
> the ctx binary is conditionally installed in {{setup.py}}, but it would seem 
> the {{pip install}} command does not install it as intended when installing 
> in editable mode ({{-e}} option)



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

[jira] [Closed] (ARIA-125) Filtering returns the wrong models

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-125.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Filtering returns the wrong models
> --
>
> Key: ARIA-125
> URL: https://issues.apache.org/jira/browse/ARIA-125
> Project: AriaTosca
>  Issue Type: Bug
>Affects Versions: 0.1.0
>    Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> When using include, this basically might remove any reference to the original 
> model. This was already fixed under CFY:
> https://cloudifysource.atlassian.net/browse/CFY-6549



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

[jira] [Closed] (ARIA-86) Create a basic "Hello World" blueprint example

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-86.
---
Resolution: Fixed

> Create a basic "Hello World" blueprint example
> --
>
> Key: ARIA-86
> URL: https://issues.apache.org/jira/browse/ARIA-86
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Maxim Orlov
>




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

[jira] [Updated] (ARIA-135) Add plugin field to MockTask

[Maxim Orlov (JIRA)]

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

Maxim Orlov updated ARIA-135:
-
Summary: Add plugin field to MockTask  (was: Add plugin field to 
MockContext)

> Add plugin field to MockTask
> 
>
> Key: ARIA-135
> URL: https://issues.apache.org/jira/browse/ARIA-135
> Project: AriaTosca
>  Issue Type: Task
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>Priority: Minor
>
> for testing purposes, We need to add plugin field to all mock tasks objects. 
> This is needed for a better testing environment. 



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

[jira] [Created] (ARIA-135) Add plugin field to MockContext

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-135:


 Summary: Add plugin field to MockContext
 Key: ARIA-135
 URL: https://issues.apache.org/jira/browse/ARIA-135
 Project: AriaTosca
  Issue Type: Task
Reporter: Maxim Orlov
Assignee: Maxim Orlov
Priority: Minor


for testing purposes, We need to add plugin field to all mock tasks objects. 
This is needed for a better testing environment. 



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

[jira] [Closed] (ARIA-120) Builtin workflows have wrong execution order in relationship operations

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIA-120.

   Resolution: Fixed
 Assignee: Maxim Orlov
Fix Version/s: 0.1.0

> Builtin workflows have wrong execution order in relationship operations
> ---
>
> Key: ARIA-120
> URL: https://issues.apache.org/jira/browse/ARIA-120
> Project: AriaTosca
>  Issue Type: Bug
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> The execution order of relationships based operations of a node is wrong. 
> In the current state, all of the pre_configure source operations are executed 
> before any pre_configure target operations are executed.
> In the desired state, each source-target operations of a single relationship 
> are executed side by side (concurrently), and only once both are done, the 
> execution of the next relationship's source-target operations commences.



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

[jira] [Created] (ARIA-131) Make demand for networkx more strict

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-131:


 Summary: Make demand for networkx more strict
 Key: ARIA-131
 URL: https://issues.apache.org/jira/browse/ARIA-131
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Currently the networkx version has to be at least 1.8, but ARIA requires 1.9 
for it to work. We need to make it more strict



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

[jira] [Created] (ARIA-130) Passing inputs from the workflow to the operation changes the inputs

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-130:


 Summary: Passing inputs from the workflow to the operation changes 
the inputs
 Key: ARIA-130
 URL: https://issues.apache.org/jira/browse/ARIA-130
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Passing inputs from the workflow to the operation changes the inputs. This is 
caused by an in place change of the inputs.



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

[jira] [Created] (ARIA-125) Filtering returns the wrong models

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-125:


 Summary: Filtering returns the wrong models
 Key: ARIA-125
 URL: https://issues.apache.org/jira/browse/ARIA-125
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov


When using include, this basically might remove any reference to the original 
model. This was already fixed under CFY:
https://cloudifysource.atlassian.net/browse/CFY-6549



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

[jira] [Updated] (ARIA-122) Create central instantiation module

[Maxim Orlov (JIRA)]

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

Maxim Orlov updated ARIA-122:
-
Summary: Create central instantiation module  (was: Createe central 
instantiation module)

> Create central instantiation module
> ---
>
> Key: ARIA-122
> URL: https://issues.apache.org/jira/browse/ARIA-122
> Project: AriaTosca
>  Issue Type: Bug
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>
> Currently each template model provides a simple API for creating an instance 
> of the class. we should provide a simple API for editing the instantiation 
> processes between the template and the instance, This should be dove via a 
> central module/package (rather than on per class basis) 



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

[jira] [Created] (ARIA-122) Createe central instantiation module

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-122:


 Summary: Createe central instantiation module
 Key: ARIA-122
 URL: https://issues.apache.org/jira/browse/ARIA-122
 Project: AriaTosca
  Issue Type: Bug
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Currently each template model provides a simple API for creating an instance of 
the class. we should provide a simple API for editing the instantiation 
processes between the template and the instance, This should be dove via a 
central module/package (rather than on per class basis) 



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

[jira] [Created] (ARIA-117) Log model should have an Execution field

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-117:


 Summary: Log model should have an Execution field
 Key: ARIA-117
 URL: https://issues.apache.org/jira/browse/ARIA-117
 Project: AriaTosca
  Issue Type: Task
Reporter: Maxim Orlov
Assignee: Maxim Orlov


The Log model currently doesn't relate to a specific operation.
The field should be added to the model.



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

[jira] [Created] (ARIA-116) Missing type_hierarchy in relationship

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-116:


 Summary: Missing type_hierarchy in relationship
 Key: ARIA-116
 URL: https://issues.apache.org/jira/browse/ARIA-116
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


The model of Relationship is missing type_hierarchy. It should be reinstated.



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

[jira] [Created] (ARIA-109) Updating tracked changes should persist

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-109:


 Summary: Updating tracked changes should persist
 Key: ARIA-109
 URL: https://issues.apache.org/jira/browse/ARIA-109
 Project: AriaTosca
  Issue Type: Story
Affects Versions: 0.1.0
Reporter: Maxim Orlov


Updating tracked changes should persist. If the first update fails, the 
mechanism should try and update any remaining updates. Any failed changes 
should be written to the log.



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

[jira] [Updated] (ARIA-106) Create sqla logging handler

[Maxim Orlov (JIRA)]

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

Maxim Orlov updated ARIA-106:
-
Description: Create an sql based logging mechanism for operations and 
workflows.

> Create sqla logging handler
> ---
>
> Key: ARIA-106
> URL: https://issues.apache.org/jira/browse/ARIA-106
> Project: AriaTosca
>  Issue Type: Sub-task
>Affects Versions: 0.1.0
>    Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>
> Create an sql based logging mechanism for operations and workflows.



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

[jira] [Created] (ARIA-95) pip wheel for aria ignores dependencies

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-95:
---

 Summary: pip wheel for aria ignores dependencies
 Key: ARIA-95
 URL: https://issues.apache.org/jira/browse/ARIA-95
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


pip wheel for aria ignores dependencies provided in the requirement.txt



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

[jira] [Created] (ARIA-66) Convert custom parser fields into sqla based fields

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-66:
---

 Summary: Convert custom parser fields into sqla based fields
 Key: ARIA-66
 URL: https://issues.apache.org/jira/browse/ARIA-66
 Project: AriaTosca
  Issue Type: Sub-task
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Currently the dsl parser has custom implementations of different collections 
(e.g StrictList, FrozenDict etc...), those need to be implemented using sqla 
based columns and fileds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIA-58) Storage model to_dict creates symbolic links

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-58:
---

 Summary: Storage model to_dict creates symbolic links
 Key: ARIA-58
 URL: https://issues.apache.org/jira/browse/ARIA-58
 Project: AriaTosca
  Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov


When calling the to_dict method on any model, any data structure type field 
(such as list or dict) gets returned as a symbolic link, thus altering that 
dict/list changes the actual storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIA-57) Custom executions state transition support

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-57:
---

 Summary: Custom executions state transition support
 Key: ARIA-57
 URL: https://issues.apache.org/jira/browse/ARIA-57
 Project: AriaTosca
  Issue Type: Story
Affects Versions: 0.1.0
Reporter: Maxim Orlov
Assignee: Maxim Orlov
Priority: Minor


Executions should support custom valid state transitions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIA-52) Support order management in relationships

[Maxim Orlov (JIRA)]

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

Maxim Orlov updated ARIA-52:

Summary: Support order management in relationships  (was: 
Support-order-management-in-relationships)

> Support order management in relationships
> -
>
> Key: ARIA-52
> URL: https://issues.apache.org/jira/browse/ARIA-52
> Project: AriaTosca
>  Issue Type: Bug
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>Priority: Minor
>
> Currently changing the order of a node's (or node instance) relationships 
> does not affect the storage. The storage should reflect any order changes 
> applied to the relationships.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIA-52) Support-order-management-in-relationships

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIA-52:
---

 Summary: Support-order-management-in-relationships
 Key: ARIA-52
 URL: https://issues.apache.org/jira/browse/ARIA-52
 Project: AriaTosca
  Issue Type: Bug
Reporter: Maxim Orlov
Assignee: Maxim Orlov
Priority: Minor


Currently changing the order of a node's (or node instance) relationships does 
not affect the storage. The storage should reflect any order changes applied to 
the relationships.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARIATOSCA-39) Genericize storage models

[Maxim Orlov (JIRA)]

Maxim Orlov created ARIATOSCA-39:


 Summary: Genericize storage models
 Key: ARIATOSCA-39
 URL: https://issues.apache.org/jira/browse/ARIATOSCA-39
 Project: AriaTosca
  Issue Type: Story
Reporter: Maxim Orlov
Assignee: Maxim Orlov


Currently it is hard to work and extend the ARIA models when consuming ARIA. 
Those models should provide a simple API which would enable inherit 
columns/relationships/etc... while using a different sql based 
engine/session/metadata (e.g. sqlalchemy-flask based engine/session/metadata) 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-30) SQL base storage implementation

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-30.

   Resolution: Fixed
Fix Version/s: 0.1.0

> SQL base storage implementation 
> 
>
> Key: ARIATOSCA-30
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-30
> Project: AriaTosca
>  Issue Type: Story
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> ARIA Storage implementation should:
> 1. move models into SQLAlchemy based models.
> 2. remove the drivers concept as SQLAlchemy is the driver.
> 3. Introduce the MAPI which connects between the actual model driver and API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-25) Storage genericizing

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-25.

Resolution: Won't Fix

This is no longer relevant, as the storage has new architecture.

> Storage genericizing
> 
>
> Key: ARIATOSCA-25
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-25
> Project: AriaTosca
>  Issue Type: Task
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
>
> Currently the storage handles pointers within in several different classes, 
> This must be changed so the driver handles all of the storage related 
> treatments (i.e. pointer resolution). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-21) Reorder repository strucutre

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-21.

   Resolution: Fixed
Fix Version/s: 0.1.0

> Reorder repository strucutre
> 
>
> Key: ARIATOSCA-21
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-21
> Project: AriaTosca
>  Issue Type: Task
>        Reporter: Maxim Orlov
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-8) API for workflow context

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-8.
---
   Resolution: Fixed
Fix Version/s: 0.1.0

> API for workflow context
> 
>
> Key: ARIATOSCA-8
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-8
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Create an API for accessing the current workflow execution's context



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (ARIATOSCA-12) API for executing workflows

[Maxim Orlov (JIRA)]

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

Maxim Orlov reopened ARIATOSCA-12:
--
  Assignee: (was: Maxim Orlov)

> API for executing workflows
> ---
>
> Key: ARIATOSCA-12
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-12
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
> Fix For: 0.1.0
>
>
> Create an API for executing workflows



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-12) API for executing workflows

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-12.

   Resolution: Fixed
Fix Version/s: 0.1.0

> API for executing workflows
> ---
>
> Key: ARIATOSCA-12
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-12
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Create an API for executing workflows



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-9) API for operation context

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-9.
---
   Resolution: Fixed
Fix Version/s: 0.1.0

> API for operation context
> -
>
> Key: ARIATOSCA-9
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-9
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> Create an API for accessing the current operation's context



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: JIRA configuration changes

[Maxim Orlov]

+1 good points, could be really helpful

On Mon, Nov 14, 2016 at 10:58 PM, Avia Efrat  wrote:

> Overall, Ran's suggestions go well with my vision of the development
> process.
> I just want to further emphasize, the less options and fields in a Jira
> issue screen (as long as it suits our general needs), the better.
>
> On Mon, Nov 14, 2016 at 10:04 PM, Ran Ziv  wrote:
>
> > 1) AFAIK in JIRA this is only possible using custom screens and fields.
> > Even if those already exist in ASF JIRA, I'd rather not deviate too much
> > from the default configuration, as explained before, though it's not
> > something I strongly oppose or so.
> >
> > 2) I think you'll see our ARIA when searching for ARIA when we drop the
> > aria-ng repo and move our website to the apache one :)
> > In any case, again, this is merely the project's *key*. if im not
> mistaken
> > the project name can actually even remain ARIATOSCA.
> >
> > 3) It doesn't AFAIK - it's true that some fields are necessary for using
> > the agile scrum board, but the issue type scheme is not part of that.
> >
> > On Mon, Nov 14, 2016 at 9:53 PM, John D. Ament 
> > wrote:
> >
> > > On Mon, Nov 14, 2016 at 2:29 PM Ran Ziv  wrote:
> > >
> > > > John -
> > > >
> > > > 1) You can see the fields that are on these screens by default and
> > > subtract
> > > > the ones I asked to be removed. Regarding your suggestion about
> > "affected
> > > > version" - in an ideal world, I'd obviously agree - and this is
> indeed
> > > what
> > > > I had in previous JIRAs I've worked with - but this so simple to do
> in
> > > JIRA
> > > > actually, and requires custom screens, which usually lead to custom
> > > fields,
> > > > and that's one slippery slope I'd rather we just avoid altogether.
> As I
> > > > mentioned, the theme was to make things simpler, while keeping the
> > making
> > > > process simple :)
> > > > I've checked out several other Apache projects, and all of them have
> > > fields
> > > > which are redundant for some issue types.
> > > >
> > >
> > > You're assuming the issue type scheme doesn't have any field
> settings.  I
> > > can't say for certain whether they do or do not in ASF's JIRA.
> > >
> > >
> > > >
> > > >
> > > > 2) ARIATOSCA is the project's name because of what you've mentioned,
> > but
> > > I
> > > > see no reason why this should be confusing for anyone using ARIA or
> > > having
> > > > heard about TOSCA. This is a mere technical issue, and could go a
> long
> > > way
> > > > for making our lives easier.
> > > >
> > >
> > > https://www.google.com/search?q=aria
> > > https://www.google.com/search?q=tosca
> > >
> > > I see our "TOSCA" as the third search result for tosca, but nothing
> about
> > > our ARIA when searching for ARIA, hence where I see confusion.
> > >
> > >
> > > >
> > > >
> > > > 3) Not sure I see the conflict here. From my experience in agile
> > > projects,
> > > > the issue scheme I suggested fits just fine as well, and
> "improvement"
> > > and
> > > > "wish" tend to only cause confusion and make things harder to filter
> > etc.
> > > >
> > >
> > > What I'm trying to draw out is if you've checked to make sure that the
> > JIRA
> > > configuration for Agile doesn't expect those issue types.
> > >
> > >
> > > >
> > > >
> > > > 4) I completely understand your concern, and indeed I mean for this
> > data
> > > to
> > > > be public knowledge, and for outside contributers to be allowed in
> the
> > > > "sprint" if/when necessary (and only if they'd be interested in it).
> > > >
> > > >
> > > > Ran
> > > >
> > > >
> > > > On Mon, Nov 14, 2016 at 9:19 PM, John D. Ament <
> johndam...@apache.org>
> > > > wrote:
> > > >
> > > > > On Mon, Nov 14, 2016 at 1:54 PM Ran Ziv 
> wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > So over a month ago I created this JIRA ticket
> > > > > >  for the
> Apache
> > > > infra
> > > > > > team, asking them to make several adjustments in our JIRA
> > > > configuration.
> > > > > >
> > > > > > It still hasn't been taken care of, but in any case John has
> > brought
> > > it
> > > > > to
> > > > > > my attention that these suggestions should be discussed here as
> > well
> > > > > (back
> > > > > > then we were pretty new to Apache, and I thought asking one of
> the
> > > > > mentors
> > > > > > to create the ticket could have sufficed).
> > > > > >
> > > > > >
> > > > > >
> > > > > > The general theme of the requested changes is about simplifying
> the
> > > > > > process, while at the same time not deviating too much from the
> > > default
> > > > > > configuration, so not to complicate things from the other end.
> > > > > >
> > > > > >
> > > > > > The specific changes I asked for are:
> > > > > >
> > > > > > 1) Removing unnecessary fields from the create-issue and
> > > resolve-issue
> > > > > > screens - the default screens are 

[jira] [Closed] (ARIATOSCA-5) Adapt workflow API uses to the modified API

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-5.
---
   Resolution: Fixed
Fix Version/s: 0.1.0

> Adapt workflow API uses to the modified API
> ---
>
> Key: ARIATOSCA-5
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-5
> Project: AriaTosca
>  Issue Type: Sub-task
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
> Fix For: 0.1.0
>
>
> The built-in workflows and graph translation mechanism need to be changed to 
> use the new modified API for building workflow graphs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (ARIATOSCA-3) API for creating workflows

[Maxim Orlov (JIRA)]

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

Maxim Orlov closed ARIATOSCA-3.
---
   Resolution: Fixed
Fix Version/s: 0.1.0

> API for creating workflows
> --
>
> Key: ARIATOSCA-3
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-3
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Ran Ziv
> Fix For: 0.1.0
>
>
> Create an API for creating workflows by building graphs of tasks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARIATOSCA-5) Adapt workflow API uses to the modified API

[Maxim Orlov (JIRA)]

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

Maxim Orlov updated ARIATOSCA-5:

Summary: Adapt workflow API uses to the modified API  (was: Adapt workflow 
API users to the modified API)

> Adapt workflow API uses to the modified API
> ---
>
> Key: ARIATOSCA-5
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-5
> Project: AriaTosca
>  Issue Type: Sub-task
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>
> The built-in workflows and graph translation mechanism need to be changed to 
> use the new modified API for building workflow graphs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARIATOSCA-9) API for operation context

[Maxim Orlov (JIRA)]

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

Maxim Orlov reassigned ARIATOSCA-9:
---

Assignee: Maxim Orlov

> API for operation context
> -
>
> Key: ARIATOSCA-9
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-9
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>    Assignee: Maxim Orlov
>
> Create an API for accessing the current operation's context



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)