[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Re: Differentiating TOSCA from HEAT
More comments â From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron On Fri, Jan 28, 2022 at 5:32 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:
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.
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:
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â
😊 Another reason for this is that I have a lot of trust in TOSCA's validation capability. If the pre-processor creates a broken design then the TOSCA processor will emit an error and we won't continue in the toolchain.
(Yet another reason for my adamant resistance to allow for requirements to "dangle".) Same question as before: how does support for variability (and support for dangling requirements, for that matter) limit the ability of a validator to ensure correctness of a template? Actually, I had some thoughts about enhancing the CSAR format to specifically allow for pre-processors. Basically some kind of META directive that instructs the toolchain to do something else first before using
the ".tosca" files therein. This would allow TOSCA inventory systems (such as used by ONAP) to continue using CSAR, at least, in a standard way. (A preprocessor for an entire CSAR would be quite painful.) The real problem with ONAP is that A&AI (their inventory system) is not based on TOSCA models. In fact, none of the ONAP components use the same data models (or even the same meta model). As a result ONAP cannot
guarantee correct integration of the various components used to manage a service. Introducing pre-processors for TOSCA doesnât fix this fundamental architectural flaw. Creating a pure TOSCA-based ONAP would
😊 And by the way preprocessing isn't just for variability of topologies, but also for profiles. I'm thinking of something simple like specifying the profile version somewhere outside of TOSCA and then injecting it,
maybe into TOSCA metadata. Or it can be a "last tested" timestamp, etc. These may be good features to have, in which case they should be supported by the TOSCA language. So, again, my point is that variability it is inevitable and it's perhaps worthwhile to at least address it, if not support it, in our specs. (Puccini does talk about it in its FAQ.) Completely agree that variability is inevitable, but what shouldnât be inevitable is for TOSCA users to use non-TOSCA templating languages to get around shortcomings of the TOSCA language. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]