ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From D Jayachandran <d.jayachand...@ericsson.com>
Subject RE: Use & impact of role/host attribute in ARIA
Date Mon, 11 Sep 2017 05:53:17 GMT
Hi Tal,

I don’t follow how can we decide all the Compute nodes as "hosted". I can still have a local
compute node and I want the executor plugin to run my scripts locally.


Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:tal@cloudify.co] 
Sent: Thursday, September 07, 2017 9:22 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA

Really, the only important one is "host" role. For the TOSCA get_property and get_attribute
functions there is support for a keyword called "HOST", which explicitly follows the path
of outbound relationships to Container capabilities (there might be several) to the final
Compute node. So Container and Compute play special roles in TOSCA.

A related role is "feature" which exists for the tosca.capabilities.Node
(note: for the capability type, not the node type!). This is followed for
*inbound* relationships to find the "HOST". This is that nodes that have relationships to
the "feature" capability of any other node (it is declared in tosca.nodes.Root) would be able
to find their host.

There are a few other roles for ARIA-specific extensions: plugins, workflows, and scaling
policies.

We could have solved this by looking for hardcoded type names, but as I said it seemed like
a bad idea to me. As the TOSCA spec changes, these names might change or their might be other
ways to reach hosts. The "role"
keeps things generic and untied to the spec.


On Thu, Sep 7, 2017 at 3:06 AM, D Jayachandran <d.jayachandran@ericsson.com>
wrote:

> Hi Tal,
>
> How do we conclude certain normative types play "special roles" ? I 
> will wait for Ran to explain on the remove execution part.
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@cloudify.co]
> Sent: Wednesday, September 06, 2017 7:05 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> First of all, "role" is an extension and is only used internally. It 
> is indeed not defined by TOSCA and you shouldn't be using it yourself.
>
> The reason "role" exists is to avoid hardcoding functionality to type 
> names. Certain normative types play special roles in TOSCA: certain 
> relationships are special, as are certain capabilities, data types, 
> etc. In order to avoid having ARIA look for a specific type name, it 
> checks the "role" extension. Internally, "role" is inherited (and can 
> be overridden), so that anything that inherits from 
> tosca.nodes.Compute, for example, would also have the "host" role. 
> (For past versions of the NFV Profile, we likely had the VDU type as 
> having "host" role, even though it did not inherit from tosca.nodes.Compute).
>
> Then execution plug tries to find out if the operation is hosted 
> remotely by seeing if the node is hosted: either a host itself, or has 
> a relationship to a node that is hosted. I'll leave it to Ran to 
> explain why this needs to be the case. :)
>
>
>
> On Wed, Sep 6, 2017 at 6:27 AM, Ran Ziv <ran@cloudify.co> wrote:
>
> > (I'll let Tal take this one :P)
> >
> > On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran < 
> > d.jayachandran@ericsson.com>
> > wrote:
> >
> > > Yes, I can see that Ran. So that was my question , why was role 
> > > being added to the types ?
> > > TOSCA spec does not say about a parameter called role. I feel this 
> > > is not aligned with TOSCA spec.
> > >
> > > Regards,
> > > DJ
> > >
> > > -----Original Message-----
> > > From: Ran Ziv [mailto:ran@cloudify.co]
> > > Sent: Wednesday, September 06, 2017 2:16 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Use & impact of role/host attribute in ARIA
> > >
> > > This is where the execution plugin decides whether to run locally 
> > > or remotely (ssh):
> > > https://github.com/apache/incubator-ariatosca/blob/0.1.
> > > 1/aria/orchestrator/execution_plugin/instantiation.py#L42
> > >
> > > This is indeed related to the "host" role definition.
> > >
> > > Here you can see the assignment of the "host" role to the Compute type:
> > > https://github.com/apache/incubator-ariatosca/blob/
> > > 1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_
> > > extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63
> > >
> > >
> > > Ran
> > >
> > > On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran < 
> > > d.jayachandran@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I just noticed the "role" attribute is added for different
> "capability"
> > > > and "node" types in ARIA profiles. There is no such role with 
> > > > the TOSCA spec.
> > > > Why is this been added in the profiles ? What is the use of them ?
> > > >
> > > > I faced an issue when I run a local script as part of the 
> > > > Interface operation. The script was provided to the execution 
> > > > plugin as "run_script_with_ssh" rather than "run_script_locally".
> > > > The "role" seemed to have a saying on deciding this. Based on 
> > > > this role a host is being added to any node instance. With the 
> > > > host being set a script is configured either as " run_script_with_ssh"
> > > > rather than "run_script_locally".
> > > >
> > > > So I want to understand under which cicumstances is a host being 
> > > > added to a node and which decided if the script execution is 
> > > > local
> or ssh ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>
Mime
View raw message