Hi Tal Thanks for the info. In summary, the last imported node template overrides the previous node template if they are using the same name. I feel this is the correct behavior and the only enhancement I see is an indication of such occurrence back to the "user". Another option is to add a system-wide configurable attribute to decide between 1) override and notify/log (default) versus 2) stop and send error message.
What about node types. Say I want to override a normative node type with my own custom type using the same node type name (yes this is a strange case). Can I import a custom node type that will override a normative node type? -Steve -----Original Message----- From: Thomas Nadeau [mailto:[email protected]] Sent: Monday, October 23, 2017 1:38 PM To: [email protected] Subject: Re: Note template names > On Oct 23, 2017, at 1:12 PM, Tal Liron <[email protected]> wrote: > > TOSCA says some things about how imports happen, but not that match. I > think we are aligned with the spec here. That is what I suspected, but best to check explicitly. > By the way, I'm quite proud of the implementation in ARIA: we handle > imports in a threadpool, so that if you are importing from many http > repositories at the same time, each download will happen simultaneously. > Performance is as optimal as it can be. (We are also caching the > results according to the conditional http request standard.) I had no reservations about that. 8) —Tom > > On Mon, Oct 23, 2017 at 12:06 PM, Thomas Nadeau > <[email protected]> > wrote: > >> >> Just for my own understanding, is the algorithm you describe >> used based on what TOSCA specifies, >> or is this our implementation detail? I ask because you can imagine >> process done >> one at a time, i.e.: per-file, but the processed results can of >> course, be different. >> >> —Tom >> >> >> >>> On Oct 23, 2017, at 12:46 PM, Tal Liron <[email protected]> wrote: >>> >>> 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 >>>> >> >>
