OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Thanks Peter. Just to make sure I understand your definitions correctly: both catalog-based and clone-and-modify orchestration use TOSCA templates, but whereas
the catalog-based templates define inputs to express per-customer-instance variability, clone-and-modify templates do not use inputs and instead hard-code per-customer-instance values directly in the template?
 
More comments inline
 
 


From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>

Sent: Monday, January 17, 2022 11:25 PM
To: Chris Lauwers <lauwers@ubicity.com>; Tal Liron <tliron@redhat.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: Differentiating TOSCA from HEAT


 
I think this is because we are on the same page, but the discussions and the uses I see in the field reveal that not everyone uses TOSCA
that way.
 
I distinguish sharply between the templates in a catalog and the instantiations created from templates.
 
In catalog based orchestration, there is a sharp distinction between the actors who define the templates in the catalog and those who
instantiated those templates to create a service. Particularly, to call it catalog based, the latter will not create or modify TOSCA templates.
Yes, this is the distinction between Day 0 (profile and service design) and Day 1 and 2 (service deployment and service management). Different tasks and as a result
different skillsets.
 
It is possible and meaningful to use TOSCA as a tool for designing instances. A uses picks a template, adds a few nodes and relations
and instantiates (aka. clone-and-modify). Maybe the altered template is even pushed back into a repository of templates.

I agree that this is possible. I just question if this is useful. This uses TOSCA as a glorified install script, not as an orchestration language.
 
It is also possible and meaningful to hack a workflow/plan/runbook generated by an orchestrator, as Tal mentions in the mail from January
6, 2022:
 
There are various reasons why Heat isn't great. The relevant one for our group is: it creates its worfklows automatically for you but there is almost no visibility into them, and definitely no hackability.
Visibility is the task of tooling. Hackability defeats the whole purpose of automation. If something needs to be changed, change the template in the catalog and update/redeploy.
Don t change the instance or workflow generated from that template.
 
But in catalog based orchestration , the actors who instantiate services:

        
Do not write (or even necessarily know) TOSCA

        
Do not hack any part of the orchestration process after deciding to deploy a template with some inputs
 
So like cloud-native orchestration , I see catalog based orchestration as a restricted part of the general concept of orchestration ,
where the restriction comes at a cost and with some benefit. I believe I outlined the benefits below.
Yes, my assumption has been that this is exactly the focus of TOSCA. TOSCA is a language for automating lifecycle management. The whole point of automation is to
achieve autonomy (i.e. to get human operators out of the loop).
 
The problem with catalog based orchestration is highlighted by Tal s second mail from January 6:
 
From the perspective of a from-the-trenches engineer: there's nothing more frustrating then a big automatic system that does a zillion things for you, but then can't do the simplest thing that you can do in a command
terminal in one minute.
Welcome to Kubernetes

Chris, and all,
 
We absolutely agree that the clone-and-modify option is bad, and that hackability is bad. I like the glorified install script way of putting it. I cannot
find any comments in red below, that I disagree with.
 
If everyone here also agrees, and then we can close this discussion.
 
But remember the demo using TOSCA for chemical plants? They were using TOSCA as a day 0 tool to design each plant separately the same template never really
got instantiated more than once. So features involving inputs would be of little interest or value.
 
So the opinions of Chris and myself are not the only tenable ones. Just because I think that clone-and-modify is a bad paradigm in my world of high-volume-telco-customer-facing-services,
doesn t prove that it is bad in all worlds.
 
Being on the same page, however, is a necessary (but not sufficient) condition for having meaningful and convergent discussions instead of running in circles.
 
If we do agree, then we have a hard requirement for the language design:
 
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
 
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.
 
Opinions?
 
Peter
 
 


From: Chris Lauwers [mailto:lauwers@ubicity.com]

Sent: 27. januar 2022 23:01
To: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>; Tal Liron <tliron@redhat.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: Differentiating TOSCA from HEAT


 
Thanks Peter. Just to make sure I understand your definitions correctly: both catalog-based and clone-and-modify orchestration use TOSCA templates, but whereas
the catalog-based templates define inputs to express per-customer-instance variability, clone-and-modify templates do not use inputs and instead hard-code per-customer-instance values directly in the template?
 
More comments inline
 
 


From: Bruun, Peter Michael (CMS RnD Orchestration) < peter-michael.bruun@hpe.com >

Sent: Monday, January 17, 2022 11:25 PM
To: Chris Lauwers < lauwers@ubicity.com >; Tal Liron < tliron@redhat.com >
Cc: tosca@lists.oasis-open.org
Subject: RE: Differentiating TOSCA from HEAT


 
I think this is because we are on the same page, but the discussions and the uses I see in the field reveal that not everyone uses
TOSCA that way.
 
I distinguish sharply between the templates in a catalog and the instantiations created from templates.
 
In catalog based orchestration, there is a sharp distinction between the actors who define the templates in the catalog and those who
instantiated those templates to create a service. Particularly, to call it catalog based, the latter will not create or modify TOSCA templates.
Yes, this is the distinction between Day 0 (profile and service design) and Day 1 and 2 (service deployment and service management). Different tasks and as a result
different skillsets.
 
It is possible and meaningful to use TOSCA as a tool for designing instances. A uses picks a template, adds a few nodes and relations
and instantiates (aka. clone-and-modify). Maybe the altered template is even pushed back into a repository of templates.

I agree that this is possible. I just question if this is useful. This uses TOSCA as a glorified install script, not as an orchestration language.
 
It is also possible and meaningful to hack a workflow/plan/runbook generated by an orchestrator, as Tal mentions in the mail from
January 6, 2022:
 
There are various reasons why Heat isn't great. The relevant one for our group is: it creates its worfklows automatically for you but there is almost no visibility into them, and definitely no hackability.
Visibility is the task of tooling. Hackability defeats the whole purpose of automation. If something needs to be changed, change the template in the catalog and update/redeploy.
Don t change the instance or workflow generated from that template.
 
But in catalog based orchestration , the actors who instantiate services:

        
Do not write (or even necessarily know) TOSCA

        
Do not hack any part of the orchestration process after deciding to deploy a template with some inputs
 
So like cloud-native orchestration , I see catalog based orchestration as a restricted part of the general concept of orchestration ,
where the restriction comes at a cost and with some benefit. I believe I outlined the benefits below.
Yes, my assumption has been that this is exactly the focus of TOSCA. TOSCA is a language for automating lifecycle management. The whole point of automation is to
achieve autonomy (i.e. to get human operators out of the loop).
 
The problem with catalog based orchestration is highlighted by Tal s second mail from January 6:
 
From the perspective of a from-the-trenches engineer: there's nothing more frustrating then a big automatic system that does a zillion things for you, but then can't do the simplest thing that you can do in a
command terminal in one minute.
Welcome to Kubernetes

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. There are two ways to approach variability: 1) 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. 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!) 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. And so I don't find it particularly offensive to have something before TOSCA in the toolchain. 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".) 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.) 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. 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.)

Thanks Tal,
 
I find this answer contradictory.
 
Either TOSCA has the expressive power required for the intended variability or it doesn t.
 
You say that pre-processing is
inevitable because it isn t, but you also say it
is already the case , because it is.  I am unable to reconcile those statements, please help.
 
From the inevitable part, I think you mean isn t , and so clearly, in
your opinion TOSCA is not and should not be ( undesirable ) sufficiently expressive for day 0 because if it were, then there would be no need for pre-processors.
 
If there can be a pre-processor input format that is more expressive than TOSCA, and you do say if not support it, in our specs ,
then yes our specs should be standardizing that format as TOSCA . Unfortunately, this would introduce yet one or two layers of parameterization on top of those of YAML, inputs, properties and attributes, and it would further complicate the language.
 
Alternatively, the role of TOSCA becomes
just as an intermediate format, useful for checking consistency of the output from whatever tool produced TOSCA.
 
I am not sure how to progress from here
 
Peter
 
 
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Tal Liron
Sent: 28. januar 2022 18:07
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.


 


There are two ways to approach variability:


 


1) 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.


 


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!)


 


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.


 



And so I don't find it particularly offensive to have something before TOSCA in the toolchain. 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".)


 



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.)


 



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.


 


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.)

I'll help. When I said "it's already the case" I meant that in reference to Peter's comment directly above (I was responding inline) about the very limited variability that TOSCA offers using topology inputs. I don't think topology inputs and the get_input function are controversial. They are already here, always have been, and are part of how we understand TOSCA. They are right there in the "mental model" for the TOSCA processor that we all agreed upon. What would be controversial is to change TOSCA in a way that would allow for topological variability. For example something like this: topology_template: node_templates: {% if inputs.loadbalancing == true %} frontend: type: Loadbalancer {% else %} frontend: type: Web {% endif %} monitor: type: Monitor {% if inputs.loadbalancing == true %} requirements: - instance: frontend {% endif %} If there are people who want TOSCA to have built-in support for this ... well, I don't think we would all agree to that. I would be very worried about the implications. Are you suggesting that we need to add features for such total variability in TOSCA? It sounds to me that you're aligned with me and Peter on this. So maybe there's a different misunderstanding here. Lacking such total variability, users that need it -- and don't want to maintain multiple complete .yaml files with identical portions -- would thus introduce a preprocessor. That's what I mean by "inevitable" -- there's absolutely no way for us to forbid it. So, I think it's best for us to acknowledge that such usages exist and perhaps find a way to deal with them in spec (e.g. by supporting them in CSAR). On Fri, Jan 28, 2022 at 2:09 PM Bruun, Peter Michael (CMS RnD Orchestration) < peter-michael.bruun@hpe.com > wrote: Thanks Tal, I find this answer contradictory. Either TOSCA has the expressive power required for the intended variability or it doesn t. You say that pre-processing is inevitable because it isn t, but you also say it is already the case , because it is. I am unable to reconcile those statements, please help. From the inevitable part, I think you mean isn t , and so clearly, in your opinion TOSCA is not and should not be ( undesirable ) sufficiently expressive for day 0 because if it were, then there would be no need for pre-processors. If there can be a pre-processor input format that is more expressive than TOSCA, and you do say if not support it, in our specs , then yes our specs should be standardizing that format as TOSCA . Unfortunately, this would introduce yet one or two layers of parameterization on top of those of YAML, inputs, properties and attributes, and it would further complicate the language. Alternatively, the role of TOSCA becomes just as an intermediate format, useful for checking consistency of the output from whatever tool produced TOSCA. I am not sure how to progress from here Peter From: tosca@lists.oasis-open.org [mailto: tosca@lists.oasis-open.org ] On Behalf Of Tal Liron Sent: 28. januar 2022 18:07 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. There are two ways to approach variability: 1) 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. 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!) 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. And so I don't find it particularly offensive to have something before TOSCA in the toolchain. 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".) 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.) 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. 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.)

Thanks for clarifying. Sorry for the misunderstanding. Get Outlook til Android From: Tal Liron <tliron@redhat.com> Sent: Friday, January 28, 2022 10:54:14 PM To: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> Subject: Re: [tosca] Re: Differentiating TOSCA from HEAT   I'll help. When I said "it's already the case" I meant that in reference to Peter's comment directly above (I was responding inline) about the very limited variability that TOSCA offers using topology inputs. I don't think topology inputs and the get_input function are controversial. They are already here, always have been, and are part of how we understand TOSCA. They are right there in the "mental model" for the TOSCA processor that we all agreed upon. What would be controversial is to change TOSCA in a way that would allow for topological variability. For example something like this: topology_template:   node_templates:     {% if inputs.loadbalancing == true %}     frontend:       type: Loadbalancer     {% else %}     frontend:       type: Web     {% endif %}     monitor:       type: Monitor       {% if inputs.loadbalancing == true %}       requirements:       - instance: frontend       {% endif %} If there are people who want TOSCA to have built-in support for this ... well, I don't think we would all agree to that. I would be very worried about the implications. Are you suggesting that we need to add features for such total variability in TOSCA? It sounds to me that you're aligned with me and Peter on this. So maybe there's a different misunderstanding here. Lacking such total variability, users that need it -- and don't want to maintain multiple complete .yaml files with identical portions -- would thus introduce a preprocessor. That's what I mean by "inevitable" -- there's absolutely no way for us to forbid it. So, I think it's best for us to acknowledge that such usages exist and perhaps find a way to deal with them in spec (e.g. by supporting them in CSAR). On Fri, Jan 28, 2022 at 2:09 PM Bruun, Peter Michael (CMS RnD Orchestration) < peter-michael.bruun@hpe.com > wrote: Thanks Tal,   I find this answer contradictory.   Either TOSCA has the expressive power required for the intended variability or it doesn’t.   You say that pre-processing is inevitable because it isn’t, but you also say it is already the case , because it is.  I am unable to reconcile those statements, please help.   From the “ inevitable ” part, I think you mean “isn’t”, and so clearly, in your opinion TOSCA is not and should not be (“ undesirable ”) sufficiently expressive for day 0 – because if it were, then there would be no need for pre-processors.   If there can be a pre-processor input format that is more expressive than TOSCA, and you do say “ if not support it, in our specs ”, then yes – our specs should be standardizing that format as “TOSCA”. Unfortunately, this would introduce yet one or two layers of parameterization on top of those of YAML, inputs, properties and attributes, and it would further complicate the language.   Alternatively, the role of TOSCA becomes just as an intermediate format, useful for checking consistency of the output from whatever tool produced TOSCA.   I am not sure how to progress from here…   Peter     From: tosca@lists.oasis-open.org [mailto: tosca@lists.oasis-open.org ] On Behalf Of Tal Liron Sent: 28. januar 2022 18:07 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.   There are two ways to approach variability:   1) 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.   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!)   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.   And so I don't find it particularly offensive to have something before TOSCA in the toolchain. 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".)   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.)   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.   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.)