RE: Differentiating TOSCA from HEAT

[Chris Lauwers <lauwers@ubicity.com>]

Thanks Peter, a couple more comments below:

 

From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Sent: Friday, January 28, 2022 3:32 AM
To: Chris Lauwers <lauwers@ubicity.com>; Tal Liron <tliron@redhat.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: Differentiating TOSCA from HEAT

 

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.

OK, when I find some time, Iâll try to summarize the discussion about âtypes of orchestratorsâ so far.

 

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.

Agreed. The difference here is that the lifetime of these industrial processes is several years (or even decades), not weeks or months. But while variability of templates may not be much of a requirement here, the need for automation is exactly why theyâre adopting TOSCA so we need to make to continue to beef up automation/orchestration features. From their demo, I remember that their implementation includes a robust âdiscoveryâ component (which is based on Redfish, I believe). Adamâs Unfurl supports discovery as well. This is likely another area of TOSCA that needs further development.

 

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.

Iâm assuming that even if we design for the âcatalog-basedâ paradigm that supports variability, nothing prevents people from using TOSCA with a âclone and modifyâ paradigm.

 

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?

 

Completely agree.

 

Peter

 

Chris