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 <[email protected]>
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:[email protected]]
> Sent: Monday, July 31, 2017 10:22 PM
> To: [email protected]
> 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 <
> [email protected]
> > 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:[email protected]]
> > Sent: Monday, July 31, 2017 6:08 PM
> > To: [email protected]
> > 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
> > <[email protected]>
> > 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:[email protected]]
> > > Sent: Sunday, July 30, 2017 7:37 PM
> > > To: [email protected]
> > > 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 <[email protected]>
> wrote:
> > >
> > > > Not entirely sure about that actually, let me double check that.
> > > >
> > > > On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <[email protected]> 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 <[email protected]>
> > 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 <
> > > >> > [email protected]
> > > >> > > 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:[email protected]]
> > > >> > > Sent: Tuesday, July 25, 2017 11:23 AM
> > > >> > > To: [email protected]
> > > >> > > 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:[email protected]]
> > > >> > > Sent: Tuesday, July 25, 2017 12:14 AM
> > > >> > > To: [email protected]
> > > >> > > 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
> > > >> > > <[email protected]>
> > > >> 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 <
> > > >> > > > [email protected]
> > > >> > > > > 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
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
