Feel free to take over the JIRA issue. :) On Mon, Sep 18, 2017 at 10:50 PM, D Jayachandran < [email protected]> wrote:
> Hi Tal, > > This seems to be a better option and we can contribute for it. > > > Regards, > DJ > > -----Original Message----- > From: Tal Liron [mailto:[email protected]] > Sent: Monday, September 11, 2017 9:26 PM > To: [email protected] > 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 < > [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 > > > > > > > > > > > > > > > > > > > > >
