Hi,
I also created a use-case that illustrates why this type compatibility is quite important in some substitutions:
Letâs say in year 2020, we have two organizations
Org1 and Org2 where:
- Org1 creates a service template that imports a third-party profile say
org.3rdp.profile.v1. This template contains a node node1 of a type
NodeTypeA from the org.3rdp.profile.v1. For node1 the substitute directive is specified, and is meant to allow substitution templates from other organizations to provide an implementation.
- In addition, the template contains a node
node2 of type NodeTypeB from the same org.3rdp.profile.v1. The type
NodeTypeB contains a requirement for a target node of NodeTypeA from the same profile. In the service template
node2 specifies node1 as the requirement target node.
- Then in the same year 2020,
Org2 creates a substitution template for that node.
- Both templates are put in the same catalogue and happily work together.
Now in year 2022 letâs say:
- Org1 wants to update its service template and wants to use
org.3rdp.profile.v2 since it wants to use the updated NodeTypeB for it contains more properties that are relevant to the service upgrade.
- NodeTypeA
also exists in org.3rdp.profile.v2 and is unchanged from the type in
org.3rdp.profile.v1
- NodeTypeB still contains a requirement for a target node of
NodeTypeA from the same profile.
- The problem is that if
Org1 wants to use NodeTypeB from org.3rdp.profile.v2 then it automatically requires to use
NodeTypeA from the same profile. This is totally fine, but suddenly the substitution template for
node1 does not work anymore since it requires a NodeTypeA from the
org.3rdp.profile.v1 and will not work with the updated service template, even though the
NodeTypeA type remained the same across profiles.
- Moreover, in 2022,
Org2 is not really interested to release an update for their substitution template unless you buy the license for the entire new version 2 of their product.
BR/C
From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Tuesday, 6 October 2020 at 23:21
To: Chris Lauwers <lauwers@ubicity.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] sharing types between profiles
Thanks, Chris, this is useful, and indeed a different problem than the one we discussed.
In my view users should indeed not be allowed to refine this way: the "participant.yaml" must be updated to use profile v2 before. The issue, as I see it, is that profiles are not just versioned types -- they are collections of types designed
to work together. There is a context to them. Otherwise, what we get here is a carte blanche to use "participant.yaml", written for v1, in environments for which it has not been validated.
However, there is still an opportunity for the profile designer to allow for such changes: create a "base" profile which both v1 and v2 imports from, and which contains Person. The "base" profile would stay in v1 while the main profile
is bumped to v2.
During this weekâs TOSCA Language Ad-Hoc meeting, we discussed at length the need for allowing type definitions to be shared between different versions of profiles.
Tal kept us honest by reminding us we need to focus on the basic problems weâre trying to solve. We kept coming back to substitution mapping as the primary use case, since we may need to match node types defined in different profiles. This led us to consider
solutions that are specific to substitution mapping.
However, I remain convinced that substitution mapping is only one of a dozen or so use cases where type sharing may be required. In fact, I would argue that this
feature may be necessary for all TOSCA features that identify types by name. To illustrate my point, Iâm attaching a document that illustrates the problem in the context of the new derivation rules weâve been discussing. I hope the text in the document is
sufficiently clear, but please let me know if you have any questions.
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|