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/09/06 07:07:43 UTC
Use & impact of role/host attribute in ARIA
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
Re: Use & impact of role/host attribute in ARIA
Posted by Ran Ziv <ra...@cloudify.co>.
A JIRA for this already exists, actually:
https://issues.apache.org/jira/browse/ARIA-151
Tal, your "remote configuration" suggestion is similar to the first bullet
in the issue's description, though there are a few other suggestions on how
to deal with this as well.
On Mon, Sep 11, 2017 at 6:56 PM, Tal Liron <ta...@cloudify.co> wrote:
> I agree with you, DJ.
>
> Until now, I think we wanted to make sure that the defaults would make
> sense for most uses, but indeed I agree that
>
> I suggest that we add another configuration parameter, "remote" (boolean)
> to enforce this. If "remote" is not specified, we will use the heuristic.
> If it is, we will do what the "remote" value says.
>
> So it would look something like this:
>
> topology_template:
> node_templates:
> loadbalancer_host:
> type: openstack.Instance
> interfaces:
> Standard:
> configure:
> implementation:
> primary: scripts/configure.sh
> dependencies:
> - remote > false
>
> What do you think? If it makes sense to you, I can create a JIRA for it.
> And you could do the PR. :)
>
> On Mon, Sep 11, 2017 at 12:59 AM, D Jayachandran <
> d.jayachandran@ericsson.com> wrote:
>
> > Hi,
> >
> > The Compute node can still be "host" but it does not mean it has to
> > remote always ? If we can want execution-plugin to handle remote host,
> > Some-other parameter should decide if it’s a remote host or not.
> >
> > Regards,
> > DJ
> > -----Original Message-----
> > From: D Jayachandran [mailto:d.jayachandran@ericsson.com]
> > Sent: Monday, September 11, 2017 11:23 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Use & impact of role/host attribute in ARIA
> >
> > 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 <ra...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Use & impact of role/host attribute in ARIA
Posted by Tal Liron <ta...@cloudify.co>.
Feel free to take over the JIRA issue. :)
On Mon, Sep 18, 2017 at 10:50 PM, D Jayachandran <
d.jayachandran@ericsson.com> wrote:
> Hi Tal,
>
> This seems to be a better option and we can contribute for it.
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@cloudify.co]
> Sent: Monday, September 11, 2017 9:26 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> I agree with you, DJ.
>
> Until now, I think we wanted to make sure that the defaults would make
> sense for most uses, but indeed I agree that
>
> I suggest that we add another configuration parameter, "remote" (boolean)
> to enforce this. If "remote" is not specified, we will use the heuristic.
> If it is, we will do what the "remote" value says.
>
> So it would look something like this:
>
> topology_template:
> node_templates:
> loadbalancer_host:
> type: openstack.Instance
> interfaces:
> Standard:
> configure:
> implementation:
> primary: scripts/configure.sh
> dependencies:
> - remote > false
>
> What do you think? If it makes sense to you, I can create a JIRA for it.
> And you could do the PR. :)
>
> On Mon, Sep 11, 2017 at 12:59 AM, D Jayachandran <
> d.jayachandran@ericsson.com> wrote:
>
> > Hi,
> >
> > The Compute node can still be "host" but it does not mean it has to
> > remote always ? If we can want execution-plugin to handle remote host,
> > Some-other parameter should decide if it’s a remote host or not.
> >
> > Regards,
> > DJ
> > -----Original Message-----
> > From: D Jayachandran [mailto:d.jayachandran@ericsson.com]
> > Sent: Monday, September 11, 2017 11:23 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Use & impact of role/host attribute in ARIA
> >
> > 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 <ra...@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
RE: Use & impact of role/host attribute in ARIA
Posted by D Jayachandran <d....@ericsson.com>.
Hi Tal,
This seems to be a better option and we can contribute for it.
Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:tal@cloudify.co]
Sent: Monday, September 11, 2017 9:26 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA
I agree with you, DJ.
Until now, I think we wanted to make sure that the defaults would make sense for most uses, but indeed I agree that
I suggest that we add another configuration parameter, "remote" (boolean) to enforce this. If "remote" is not specified, we will use the heuristic.
If it is, we will do what the "remote" value says.
So it would look something like this:
topology_template:
node_templates:
loadbalancer_host:
type: openstack.Instance
interfaces:
Standard:
configure:
implementation:
primary: scripts/configure.sh
dependencies:
- remote > false
What do you think? If it makes sense to you, I can create a JIRA for it.
And you could do the PR. :)
On Mon, Sep 11, 2017 at 12:59 AM, D Jayachandran < d.jayachandran@ericsson.com> wrote:
> Hi,
>
> The Compute node can still be "host" but it does not mean it has to
> remote always ? If we can want execution-plugin to handle remote host,
> Some-other parameter should decide if it’s a remote host or not.
>
> Regards,
> DJ
> -----Original Message-----
> From: D Jayachandran [mailto:d.jayachandran@ericsson.com]
> Sent: Monday, September 11, 2017 11:23 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Use & impact of role/host attribute in ARIA
>
> 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 <ra...@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
> > > > >
> > > >
> > >
> >
>
Re: Use & impact of role/host attribute in ARIA
Posted by Tal Liron <ta...@cloudify.co>.
I agree with you, DJ.
Until now, I think we wanted to make sure that the defaults would make
sense for most uses, but indeed I agree that
I suggest that we add another configuration parameter, "remote" (boolean)
to enforce this. If "remote" is not specified, we will use the heuristic.
If it is, we will do what the "remote" value says.
So it would look something like this:
topology_template:
node_templates:
loadbalancer_host:
type: openstack.Instance
interfaces:
Standard:
configure:
implementation:
primary: scripts/configure.sh
dependencies:
- remote > false
What do you think? If it makes sense to you, I can create a JIRA for it.
And you could do the PR. :)
On Mon, Sep 11, 2017 at 12:59 AM, D Jayachandran <
d.jayachandran@ericsson.com> wrote:
> Hi,
>
> The Compute node can still be "host" but it does not mean it has to
> remote always ? If we can want execution-plugin to handle remote host,
> Some-other parameter should decide if it’s a remote host or not.
>
> Regards,
> DJ
> -----Original Message-----
> From: D Jayachandran [mailto:d.jayachandran@ericsson.com]
> Sent: Monday, September 11, 2017 11:23 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Use & impact of role/host attribute in ARIA
>
> 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 <ra...@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
> > > > >
> > > >
> > >
> >
>
RE: Use & impact of role/host attribute in ARIA
Posted by D Jayachandran <d....@ericsson.com>.
Hi,
The Compute node can still be "host" but it does not mean it has to remote always ? If we can want execution-plugin to handle remote host, Some-other parameter should decide if it’s a remote host or not.
Regards,
DJ
-----Original Message-----
From: D Jayachandran [mailto:d.jayachandran@ericsson.com]
Sent: Monday, September 11, 2017 11:23 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Use & impact of role/host attribute in ARIA
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....@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 <ra...@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
> > > >
> > >
> >
>
RE: Use & impact of role/host attribute in ARIA
Posted by D Jayachandran <d....@ericsson.com>.
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....@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 <ra...@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
> > > >
> > >
> >
>
Re: Use & impact of role/host attribute in ARIA
Posted by Tal Liron <ta...@cloudify.co>.
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....@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 <ra...@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
> > > >
> > >
> >
>
RE: Use & impact of role/host attribute in ARIA
Posted by D Jayachandran <d....@ericsson.com>.
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 <ra...@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
> > >
> >
>
Re: Use & impact of role/host attribute in ARIA
Posted by Tal Liron <ta...@cloudify.co>.
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 <ra...@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
> > >
> >
>
Re: Use & impact of role/host attribute in ARIA
Posted by Ran Ziv <ra...@cloudify.co>.
(I'll let Tal take this one :P)
On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran <d....@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
> >
>
RE: Use & impact of role/host attribute in ARIA
Posted by D Jayachandran <d....@ericsson.com>.
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
>
Re: Use & impact of role/host attribute in ARIA
Posted by Ran Ziv <ra...@cloudify.co>.
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
>