RE: [tosca] sharing types between different profiles

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tal,

 

Yes, I feel strongly that profiles should be versioned, meaning the fully qualified profile name should have a ânameâ component and a âversionâ component clearly separated by a well-known separator (e.g. a colon). For example, the following defines Version 2.0 of the Simple Profile:

 

profile: org.oasis-open.simple:2.0

 

I also think it makes most sense to allow sharing of type definitions between different profiles only if those profiles are different versions of the same profile. For example, letâs assume that the Simple Profile v2.0 defines a Compute node type, as follows:

 

tosca_definitions_version: tosca_2_0

profile: org.oasis-open.simple:2.0

node_types:

  Compute:

    derived_from: Root

    properties:

      <<remaining definitions omitted>>

 

Now letâs assume weâre releasing an update to the Simple Profile, which will be Version 2.1. However, Version 2.1 of the Simple Profile does not introduce any changes to the Compute node type, meaning the Compute node type in Version 2.1 is identical to the Compute node type in Version 2.0, and it should be possible to use the two interchangeably. Iâm suggesting that this could be indicated using a âversionâ keyword in the node type definition (or some other keyword if that is more clear), where the value of that keyword specifies the profile version that has the original Compute node definition to which this Compute node definition is identical. The following code snippet shows this:

 

tosca_definitions_version: tosca_2_0

profile: org.oasis-open.simple:2.1

node_types:

  Compute:

    # The Compute node is defined in Version 2.0 of this profile

    version: 2.0

 

Any other definitions in the v2.1 Compute node type definition must be ignored.

 

Hopefully this makes things more clear.

 

Thanks,

 

Chris

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Tal Liron
Sent: Thursday, September 24, 2020 8:36 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] sharing types between different profiles

 

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