You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by D Jayachandran <d....@ericsson.com> on 2017/07/24 10:57:00 UTC

Inputs and Node object context for python and shell scripts

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

Posted by Tal Liron <ta...@cloudify.co>.
Hi DJ,

Not entirely sure what you are asking here.

You can definitely access the artifact *models* via ctx. However, you are
probably thinking about accessing the artifacts files themselves.

We do not currently have a working mechanism for artifacts. They are only
stored locally in the .aria home directory, but copied to the remote hosts
only if needed for remote execution. Related is also to fully support the
get_artifact intrinsic function, a quite complicated one.

There are a few related open JIRA tickets to handle this.



On Thu, Aug 3, 2017 at 6:32 AM, D Jayachandran <d....@ericsson.com>
wrote:

> Am resending this to be on the same thread.
>
> Do we also need to consider wrapping the artifacts model in the node
> object context being received by the plugin method ?
> The artifacts can be used by the plugins during execution right ?
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Maxim Orlov [mailto:maxim@cloudify.co]
> Sent: Thursday, August 03, 2017 1:32 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell scripts
>
> 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.jayachandran@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:maxim@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.jayachandran@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: 8888
> > >>                             isService: false
> > >>
> > >>         database:
> > >>             type: nodes.Container.Application.Kubernetes
> > >>             properties:
> > >>                 name: { get_input: db_name }
> > >>                 image: { get_input: db_image }
> > >>                 port: { get_input: db_port }
> > >>             interfaces:
> > >>                 Standard:
> > >>                     inputs:
> > >>                         name: { get_property: [ database, name] }
> > >>                         image: { get_property: [ database, image] }
> > >>                         exposed_port: { get_property: [ database,
> > >> port]
> > }
> > >>                         isService: true
> > >>                     create:
> > >>                         inputs:
> > >>                             name: { get_property: [ database, name] }
> > >>                             image: { get_property: [ database, image]
> }
> > >>                             exposed_port: { get_property: [
> > >> database, port] }
> > >>                             isService: true
> > >>
> > >> NODE TYPES
> > >>
> > >> node_types:
> > >>     nodes.Container.Application.Kubernetes:
> > >>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage
> > >> > collected
> > >> >
> > >> >
> > >> > Regards,
> > >> > DJ
> > >> >
> > >> > -----Original Message-----
> > >> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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
> > >> > > >> > > <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
Am resending this to be on the same thread.

Do we also need to consider wrapping the artifacts model in the node object context being received by the plugin method ?
The artifacts can be used by the plugins during execution right ?


Regards,
DJ

-----Original Message-----
From: Maxim Orlov [mailto:maxim@cloudify.co] 
Sent: Thursday, August 03, 2017 1:32 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

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....@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:maxim@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.jayachandran@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: 8888
> >>                             isService: false
> >>
> >>         database:
> >>             type: nodes.Container.Application.Kubernetes
> >>             properties:
> >>                 name: { get_input: db_name }
> >>                 image: { get_input: db_image }
> >>                 port: { get_input: db_port }
> >>             interfaces:
> >>                 Standard:
> >>                     inputs:
> >>                         name: { get_property: [ database, name] }
> >>                         image: { get_property: [ database, image] }
> >>                         exposed_port: { get_property: [ database, 
> >> port]
> }
> >>                         isService: true
> >>                     create:
> >>                         inputs:
> >>                             name: { get_property: [ database, name] }
> >>                             image: { get_property: [ database, image] }
> >>                             exposed_port: { get_property: [ 
> >> database, port] }
> >>                             isService: true
> >>
> >> NODE TYPES
> >>
> >> node_types:
> >>     nodes.Container.Application.Kubernetes:
> >>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage 
> >> > collected
> >> >
> >> >
> >> > Regards,
> >> > DJ
> >> >
> >> > -----Original Message-----
> >> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 
> >> > > >> > > <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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....@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:maxim@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.jayachandran@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: 8888
> >>                             isService: false
> >>
> >>         database:
> >>             type: nodes.Container.Application.Kubernetes
> >>             properties:
> >>                 name: { get_input: db_name }
> >>                 image: { get_input: db_image }
> >>                 port: { get_input: db_port }
> >>             interfaces:
> >>                 Standard:
> >>                     inputs:
> >>                         name: { get_property: [ database, name] }
> >>                         image: { get_property: [ database, image] }
> >>                         exposed_port: { get_property: [ database, port]
> }
> >>                         isService: true
> >>                     create:
> >>                         inputs:
> >>                             name: { get_property: [ database, name] }
> >>                             image: { get_property: [ database, image] }
> >>                             exposed_port: { get_property: [ database,
> >> port] }
> >>                             isService: true
> >>
> >> NODE TYPES
> >>
> >> node_types:
> >>     nodes.Container.Application.Kubernetes:
> >>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage
> >> > collected
> >> >
> >> >
> >> > Regards,
> >> > DJ
> >> >
> >> > -----Original Message-----
> >> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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
> >> > > >> > > <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
Hi Max,

Do we also need to consider wrapping the artifacts model in the node object context being received by the plugin method ?
The artifacts can be used the plugins during execution.


Regards,
DJ
-----Original Message-----
From: D Jayachandran 
Sent: Wednesday, August 02, 2017 12:26 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Inputs and Node object context for python and shell scripts

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:maxim@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.jayachandran@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: 8888
>>                             isService: false
>>
>>         database:
>>             type: nodes.Container.Application.Kubernetes
>>             properties:
>>                 name: { get_input: db_name }
>>                 image: { get_input: db_image }
>>                 port: { get_input: db_port }
>>             interfaces:
>>                 Standard:
>>                     inputs:
>>                         name: { get_property: [ database, name] }
>>                         image: { get_property: [ database, image] }
>>                         exposed_port: { get_property: [ database, port] }
>>                         isService: true
>>                     create:
>>                         inputs:
>>                             name: { get_property: [ database, name] }
>>                             image: { get_property: [ database, image] }
>>                             exposed_port: { get_property: [ database, 
>> port] }
>>                             isService: true
>>
>> NODE TYPES
>>
>> node_types:
>>     nodes.Container.Application.Kubernetes:
>>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage 
>> > collected
>> >
>> >
>> > Regards,
>> > DJ
>> >
>> > -----Original Message-----
>> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 
>> > > >> > > <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
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:maxim@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.jayachandran@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: 8888
>>                             isService: false
>>
>>         database:
>>             type: nodes.Container.Application.Kubernetes
>>             properties:
>>                 name: { get_input: db_name }
>>                 image: { get_input: db_image }
>>                 port: { get_input: db_port }
>>             interfaces:
>>                 Standard:
>>                     inputs:
>>                         name: { get_property: [ database, name] }
>>                         image: { get_property: [ database, image] }
>>                         exposed_port: { get_property: [ database, port] }
>>                         isService: true
>>                     create:
>>                         inputs:
>>                             name: { get_property: [ database, name] }
>>                             image: { get_property: [ database, image] }
>>                             exposed_port: { get_property: [ database, 
>> port] }
>>                             isService: true
>>
>> NODE TYPES
>>
>> node_types:
>>     nodes.Container.Application.Kubernetes:
>>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage 
>> > collected
>> >
>> >
>> > Regards,
>> > DJ
>> >
>> > -----Original Message-----
>> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 
>> > > >> > > <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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.jayachandran@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: 8888
>>                             isService: false
>>
>>         database:
>>             type: nodes.Container.Application.Kubernetes
>>             properties:
>>                 name: { get_input: db_name }
>>                 image: { get_input: db_image }
>>                 port: { get_input: db_port }
>>             interfaces:
>>                 Standard:
>>                     inputs:
>>                         name: { get_property: [ database, name] }
>>                         image: { get_property: [ database, image] }
>>                         exposed_port: { get_property: [ database, port] }
>>                         isService: true
>>                     create:
>>                         inputs:
>>                             name: { get_property: [ database, name] }
>>                             image: { get_property: [ database, image] }
>>                             exposed_port: { get_property: [ database,
>> port] }
>>                             isService: true
>>
>> NODE TYPES
>>
>> node_types:
>>     nodes.Container.Application.Kubernetes:
>>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage
>> > collected
>> >
>> >
>> > Regards,
>> > DJ
>> >
>> > -----Original Message-----
>> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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
>> > > >> > > <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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
@operationdef 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....@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: 8888
>                             isService: false
>
>         database:
>             type: nodes.Container.Application.Kubernetes
>             properties:
>                 name: { get_input: db_name }
>                 image: { get_input: db_image }
>                 port: { get_input: db_port }
>             interfaces:
>                 Standard:
>                     inputs:
>                         name: { get_property: [ database, name] }
>                         image: { get_property: [ database, image] }
>                         exposed_port: { get_property: [ database, port] }
>                         isService: true
>                     create:
>                         inputs:
>                             name: { get_property: [ database, name] }
>                             image: { get_property: [ database, image] }
>                             exposed_port: { get_property: [ database,
> port] }
>                             isService: true
>
> NODE TYPES
>
> node_types:
>     nodes.Container.Application.Kubernetes:
>         derived_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:maxim@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.jayachandran@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 <Node> has been garbage
> > collected
> >
> >
> > Regards,
> > DJ
> >
> > -----Original Message-----
> > From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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
> > > >> > > <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
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: 8888 
                            isService: false 
        
        database:
            type: nodes.Container.Application.Kubernetes
            properties:
                name: { get_input: db_name }
                image: { get_input: db_image }
                port: { get_input: db_port }
            interfaces:
                Standard:
                    inputs: 
                        name: { get_property: [ database, name] }
                        image: { get_property: [ database, image] }
                        exposed_port: { get_property: [ database, port] }
                        isService: true
                    create:
                        inputs: 
                            name: { get_property: [ database, name] }
                            image: { get_property: [ database, image] }
                            exposed_port: { get_property: [ database, port] }
                            isService: true

NODE TYPES

node_types:
    nodes.Container.Application.Kubernetes:
        derived_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:maxim@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.jayachandran@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 <Node> has been garbage 
> collected
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 
> > >> > > <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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.jayachandran@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 <Node> has been garbage collected
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
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 <Node> has been garbage collected


Regards,
DJ

-----Original Message-----
From: Maxim Orlov [mailto:maxim@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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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....@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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
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:maxim@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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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 <ta...@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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
Not entirely sure about that actually, let me double check that.

On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <ta...@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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by Tal Liron <ta...@cloudify.co>.
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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@cloudify.co>.
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.jayachandran@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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
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.jayachandran@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:maxim@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 <ta...@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.jayachandran@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

Posted by D Jayachandran <d....@ericsson.com>.
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:maxim@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 <ta...@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.jayachandran@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

Posted by Maxim Orlov <ma...@gigaspaces.com>.
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 <ta...@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.jayachandran@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

Posted by Tal Liron <ta...@gigaspaces.com>.
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.jayachandran@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
>
>
>
>