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 <[email protected]> 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 < > [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 > > > > > > > > > > > > > > > > > > > > >
