RE: [tosca] sharing types between profiles

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tal,

 

If you put your âtype_aliasesâ in org.profile.v3, then your solution is exactly what weâre proposing, albeit with less elegant syntax 😊 What I suggested earlier this week is to use the âversionâ keyword directly in the type definition to indicate that a type definition is exactly the same as a definition with the same name in a previous version of the profile. That conveys the same information as what youâre specifying using âtype_aliasesâ.

 

Thanks,

 

Chris

 

From: Tal Liron <tliron@redhat.com>
Sent: Wednesday, October 7, 2020 8:47 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] sharing types between profiles

 

On Tue, Oct 6, 2020 at 6:18 PM Chris Lauwers <lauwers@ubicity.com> wrote:

If youâre still not convinced, then here is one more use case that uses relationships and capabilities (these scenarios pretty much write themselves 😊):

 

I'm still not on board. :) Rather, your example I think supports my point.

 

The template writer in this example is using both "org.profile" and the "platform profile", but "platform profile" has been validated only against  "org.profile" v1. What you are suggesting here is that the "org.profile" maintainer would explicitly allow a carte blanche future compatibility already at v1. But what if v3 has breaking changes?

 

I do agree that there should be a way in TOSCA to work around this. Let me attempt a new suggestion that might be workable as a flexible compromise. How about a new global keyword called "type_aliases" which essentially instructs the parser to treat two or more separate names in the namespaces as equivalent/interchangeable. You could put this section in a profile, in a service template, or even in its own individual file that you could import either in a profile or a service template.

 

So imagine something like this:

 

imports:

- profile: org.profile.v3
  namespace: p3
- profile: org.profile.v2
  namespace: p2
- profile: org.profile.v1
  namespace: p1

 

type_aliases:

  capability_types:

  - [ p3:Host, p2:Host, p1:Host ]

  - [ p2:Network, p1:Network ]

  data_types:

  - [ p2:Port, p1:Port ]

 

So, again, this section could exist in org.profile.v3, or in its own file ("compatibility.yaml"), or within the service template.