More comments
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Friday, January 28, 2022 9:07 AM
To: Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com>
Cc: Chris Lauwers <
lauwers@ubicity.com>;
tosca@lists.oasis-open.org Subject: [tosca] Re: Differentiating TOSCA from HEAT
On Fri, Jan 28, 2022 at 5:32 AM Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com > wrote:
All potential
intended variability of each type of service in the catalog must be easily expressible as a function of the inputs. Note that this creates two levels of intent based , and I am not sure that was clear in the previous work on TOSCA for intent based modeling:
The intent of the Day 0 designer to express in as few templates as possible the intended variability offered to the Day 1+ users
The intent of the Day 1+ users, expressed by a) selecting a template from the catalog and b) providing input values
I think there's great no need to say so, because this is already the case. :) But it won't hurt to make it clear.
If the expressive power of inputs is too low (or too hard to use), then the users will begin to spawn variants of the templates for those cases that are not expressible. I hope we all agree that that is undesirable.
Alternatively, we face another bad scenario, that to express the intended variability, users invent their own home-grown formats to use as input to some TOSCA-generating scripts. That road, in my opinion defies the purpose of TOSCA
as a standard.
I think this is inevitable, but I also don't think it's the end of the world.
I m not sure I agree with this. I believe this is only inevitable if we don t do our jobs right. For service designers, it s extra hassle and extra cost to introduce additional templating support or other tooling
to get around shortcomings of TOSCA. Assuming proper support for variability in the TOSCA language, I don t believe service designers would go through the effort of introducing such additional tooling.
There are two ways to approach variability:
Integrate variability into TOSCA. This, I think is undesirable. Take a look at Helm charts -- what an unholy mess. Not only can they not be validated at design time, they are almost
impossible to read, modify, or fix. They even allow for (code) plugins that do custom variability. This should be the poster child for the opposite of what TOSCA purports to be.
Yes, but arguably Helm exists exactly because Kubernetes manifest files do not support variability. At its core, Helm charts are nothing more than templatized Kubernetes manifest files. You re absolutely right that
this is the wrong approach to take (in my opinion, the Helm team has a track record of making wrong architectural decisions see tiller ). Any language design that forces people to overlay templating will absolutely result in a unholy mess .
2) Add a preprocessor to the toolchain. You called it a "TOSCA-generating script" but it also can be some kind of template modification (not full generation). I'm not a fan of text templating for YAML, but otherwise
it is possible to create some other higher-level templating that is purpose-built for YAML, and perhaps even purpose-built for TOSCA. (This is an idea for a project if someone wants to contribute to the ecosystem!)
I can t think of any other (properly-designed) language where users routinely use pre-processing to get around language limitations. This feels especially counter-intuitive with TOSCA. The TOSCA specification was
intentionally moved from XML to YAML because TOSCA files are intended to be authored by humans, not by tools.
The idea of TOSCA being part of a toolchain is central to how I think about it. Because I deal with already-existing orchestrators such as Ansible and Terraform or larger pyramids of orchestrator, I must think of
TOSCA as being an input (albeit a processed input, and even a continuous input for Day 2 when I deal with attributes) into the next step in the process. I am not going to, and cannot, fork my orchestration universe in order to redesign it around a specific
version of TOSCA.
I m not sure how adding additional support for variability into TOSCA is incompatible with your goal of using TOSCA as an input format for existing orchestrators?
And so I don't find it particularly offensive to have something before TOSCA in the toolchain.
If TOSCA is the input , then having something before TOSCA may not be offensive , but it sure smells fishy