Re: [tosca] sharing types between different profiles

[Tal Liron <tliron@redhat.com>]

Hi Chris,

I had difficulty following your "version" example. Perhaps you mean that the "version" string is appended to the "profile" string and type name when figuring out the canonical type name? E.g. a type name with version 3 in the Simple Profile 1.3:

org.oasis-open.simple-1.3:Compute:3

This could be OK, but could also lead to confusion if different "editions" of the same profile version are released.

I am leaning towards Calin's idea, but with a twist. I think we can have a keyword allowing canonical aliases. The idea is that the internal canonical type name is always usable as we have assumed until now, derived from the profile string and the type name, but profile writers *can also* provide additional canonical names for specific types, and that these aliases can be used directly when referring to type names. You would still need to import the profile to register the aliases in addition to the default name, but it might allow for special variants.

Example profile:

profile org.oasis-open.simple-1.3

node_types:

 Compute:

ÂÂÂ aliases:

ÂÂÂ - org.oasis-open.simple-1.2.ComputeLegacy

And you could then refer to this type in two ways:

imports:

- profile: org.oasis-open.simple-1.3

 namespace: simple

topology_template:

 node_templates:

ÂÂÂ Server1:

ÂÂÂÂÂ type: simple:Compute

ÂÂÂ Server2:

ÂÂÂÂÂ type: org.oasis-open.simple-1.2.ComputeLegacy

This does lead me back to my early idea that canonical type names would actually be part of the specification, allowing you two ways to refer to a type name.

On Tue, Sep 22, 2020 at 4:08 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Thanks for a very good discussion about Profiles earlier today. Iâd love to continue the dialogue over email if possible.

1. I believe we all agree that there is a need to âshareâ types between different profiles (or, said a different way, to indicate that Type A in Profile 1 is exactly the same as Type B in Profile 2). The obvious use case for this is when two profiles are really just two different versions of the same profile, and most of the types defined in these profiles donât change as part of a version upgrade.
2. One question we need to answer, then, is whether it should also be allowed to share types between different profiles that arenât related at all (i.e. that arenât just different versions of the same profile). My inclination would be to not allow/support this. I think it is helpful to know/understand which profile a type belongs to. Having a type belong to different versions of the same profile makes sense, but having a type belong to 2 completely unrelated profiles feels like a bridge too far.
3. If we want to limit âtype sharingâ between different versions of the same profile, then we need a mechanism for indicating that two different profiles are really just two different versions of the same profile. The naming convention for profiles as proposed by Tal includes a version part, but it doesnât mandate/formalize this. If weâre going to support versioning of profiles, then we need to be able to separate the profile name from the version, either using some sort of âstandardâ delimiter in the profile name, or using an explicit version keyword.
4. Based on these assumptions, then, there may be a very elegant way to support type sharing, using the (already existing) version keyname in type definitions. The current versions of the TOSCA specification donât explain what that âversionâ keyword is intended to be used for, but the presumption is that the âversionâ reflects the version of the type definition itself. What if instead, we interpreted that âversionâ in the type definition as a âprofile versionâ, and specifically as the version of the (same) profile where that type was previously defined? For example, if a TOSCA parser âonboardsâ Profile 1 of version 1.1, and it encounters a type definition A with a version set to 1.0, it would find version 1.0 of Profile 1, and reuse the type definition for A as defined in that version. Of course, that means that all other parts of the definition of Type A in the 1.1 profile will be ignored (and should be optional).

I believe this may be a simpler alternative to having to introduce âinvariant namesâ in type definitions, but:

• It limits type sharing to different versions of the same profile
• It requires grammar support for versioning of Profiles.

Please let me know what you think.

Chris

Â