Thanks for a very good discussion about Profiles earlier today. I’d love to continue the dialogue over email if possible.
-
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.
-
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.
-
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.
-
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
|