If youâre still not convinced, then here is one more use case that uses relationships and capabilities (these scenarios pretty much write themselves
😊):
- It does not involve substitution, so we can avoid that discussion for now.
- It strictly uses profiles, which eliminates the option for âusersâ of the profile to just re-write TOSCA templates files to use latest versions everywhere. When you use profiles, you
need to use what youâre given.
I inserted the use case as a first section to the document I sent out earlier. The âderivation rulesâ use case has not been changed.
As a general âbest practiceâ I believe that it is better to make the profile designers do a little extra work to make service template design easier. We shouldnât burden service template designers with the task of âupgradingâ all the âlibrariesâ
they use to the latest versions just to make things work.
Thanks,
Chris
From: Tal Liron <tliron@redhat.com>
Sent: Tuesday, October 6, 2020 3:41 PM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] sharing types between profiles
The situation is quite realistic! But I'm not convinced that sharing types is the right solution:
-
If Org2 is not interested in upgrading their old product, and Org1 is intent on continuing to use it, well I think it would make sense to have different service templates for each version because you really are using different products.
-
Let's say we do want a workaround feature using invariant names -- well, it would be the responsibility of Org2 to include those. But, as stated, they do not want to support their old product, so they won't. This is one reason why I said that if we do want
to allow some kind of equivalency feature then I think it should be in the control of the service template writer, not the profile writer. The user should be the one deciding what versions they want to allow or disallow.
Generally I think that substitution is out of the realm of TOSCA, and that's good. This would obviously be implemented in many different ways according to how the orchestrator works. Some orchestrators might even fill in a substitution
using existing systems without any TOSCA service template behind them. As long as it can behave like a certain node type (reqs, caps, properties, interface mappings) then it would be fine.
In the end, I don't think it should be TOSCA's role to decide what is substitutable and what isn't. Remember that just the node type is not enough -- there should be other decisions, some of them runtime-dependent, as to what to "grab"
from the inventory or pool or registry or datacenter or whatever, and I think it would usually be configured via policy (a substitution policy). If you want your orchestrator to allow for substitutions using older versions of a type, that should be fine. I
would hate for TOSCA grammar to be in the way of any kind of service composition plans.
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
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
|