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