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 <
[email protected]> 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:[email protected]]
> Sent: Monday, September 11, 2017 11:23 AM
> To: [email protected]
> 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:[email protected]]
> Sent: Thursday, September 07, 2017 9:22 PM
> To: [email protected]
> 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 <
> [email protected]>
> 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:[email protected]]
> > Sent: Wednesday, September 06, 2017 7:05 PM
> > To: [email protected]
> > 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 <[email protected]> wrote:
> >
> > > (I'll let Tal take this one :P)
> > >
> > > On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran <
> > > [email protected]>
> > > 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:[email protected]]
> > > > Sent: Wednesday, September 06, 2017 2:16 PM
> > > > To: [email protected]
> > > > 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 <
> > > > [email protected]
> > > > > 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
> > > > >
> > > >
> > >
> >
>
