Yes, you can do that. Think of imports as being essentially like a smart copy-paste from one YAML file to another. In the end, ARIA treats it as just one big service template.
In other words, the requirements-and-capabilities matching occurs only after all imports were done and the final service template is valid. On Mon, Oct 23, 2017 at 10:45 AM, Steve Baillargeon < [email protected]> wrote: > Thank you Tal > > Can ARIA handle the case when ST1 imports ST2 with a relationship (link) > between source node template AA defined in ST1 and target node template BB > defined in ST2? > For instance, a SoftwareComponent node is defined in ST1 with a specific > requirement to run on a Compute node that is defined in ST2. > > -Steve > > -----Original Message----- > From: Tal Liron [mailto:[email protected]] > Sent: Thursday, October 19, 2017 2:18 PM > To: [email protected] > Subject: Re: Note template names > > Some good questions here. Let me try to break it down, > > On Thu, Oct 19, 2017 at 12:39 PM, Steve Baillargeon < > [email protected]> wrote: > > > Node template names must be unique within a given service template. > > > > Yes. Actually, there is an "interesting" issue with this: in YAML, a dict > could have multiple keys with the same name. What happens in that case is > that subsequent keys (node template names in this case) override previous > ones of the same name. So, you can syntactically have two node templates of > the same name, but only one will count. > > We tried to find ways in ARIA to emit an error in this case, but actually > it's very hard to do because it's a YAML spec issue that allows it. > > > > What about the case when ST1 imports ST2 as follows. > > ST1 has 2 node templates: template A derived from node type X and > > template B derived from node type Y. > > ST2 has 1 node template: template A derived from node type Z . > > > > Actually, the "imports" keyword isn't 100% clear in the TOSCA spec. What > we do in ARIA is merge the dicts, and again identical keys (node template > names) will override without error. So, the final behavior will be > undefined. > > However, I think that in this particular case ARIA can do something more, > because we handle merging ourselves (it's not an issue of the YAML spec). I > have opened a new JIRA about this: > https://issues.apache.org/jira/browse/ARIA-390 >
