Sorry too quick I used a link to my own cache of the Intent article here is an official one:
https://pure.tue.nl/ws/portalfiles/portal/135476597/Tamburri2019_Article_TOSCA_basedIntentModellingGoal.pdf With Damien and Chris as authors, I assume everyone is familiar with it, but I don t think we discussed it while I was a member.
Peter
From: Bruun, Peter Michael (CMS RnD Orchestration)
Sent: 11. januar 2022 15:45
To: Chris Lauwers <
lauwers@ubicity.com>; Tal Liron <
tliron@redhat.com>
Cc:
tosca@lists.oasis-open.org Subject: RE: Differentiating TOSCA from HEAT
I definitely think that those 4 concepts are quite different.
-
Declarative orchestration
This is an
intrinsic feature of a language, stating that the language declares what should exist (or not exist). The declarative language should not spell out not how it is made. It is still declarative if the language has a way to include the
means to make it exist artifacts, interfaces.
-
Cloud-native orchestration
This is, as I understood Tal s slides, a
subset of orchestration problems, where the systems under orchestration satisfy a set of cloud-native constraints, that allows the orchestrator to have no concept of sequencing of actions. If just one of the systems does not satisfy those constraints,
then cloud-native orchestration is not sufficient to solve the problem.
Tal please provide a better definition.
The assumption is that all systems in the world ought to comply with the cloud-native principles, and those that don t should either be fixed or discarded as outdated technology
alongside the Steam Roller and the Edison Phonograph.
-
Intent-based orchestration
On this subject we have this:
https://github.hpe.com/hpsd/hpsp/files/18603/Tamburri2019_Article_TOSCA_basedIntentModellingGoal.pdf I agree 100% with this definition of intent:
Intent modelling Intent modelling entails modelling infrastructure blueprints by specifying a highest-level goal to be satisfied, regardless of how sub-level intents or goals are satisfied.
To me expressing intent is to say I need Firewalling instead of I need a Firewall . Or I need Load-balancing not I need a Load Balancer .
There are clearly cases where TOSCA can do this if the intent-decomposition is expressible as substitutions, but I also see intents and realizations of intent where TOSCA would
force the designer to manually perform the decomposition of intent, and so the resulting TOSCA template would be
derived from the original intent, but it would no longer express the original intent as an object in its own right. Notice that a program written in C is similarly
derived from some original intent, but the intent itself is no longer explicitly present in-language. Clearly, C is not an intent-based language, and the fact that you can define and implement a function that expresses an intent doesn t make it so. It
takes more to be Intent based than being able to implement intent .
So unless we can prove that TOSCA with substitutions can explicitly express all possible intent, then I am not convinced that TOSCA is intent based.
Of course a firewalling intent could be implemented as an actual firewall, but I remember when OpenFlow was in fashion, and you can express a simple firewalling or load-balancing
intent as a set of OpenFlow rules. Those rules are not a Node , they get deployed on a potentially variable number of switches. So where would I put this in my TOSCA template?
You could solve this by pushing intent to Policies so add in your template a Firewalling Policy, and Firewalling happens. But the implementation of that intent would have
to be hard-coded in the orchestrator, and so the Policy is just a name for a hard-coded functionality, it is not a language for defining the firewalling intent.
-
Desired state orchestration
This is a property of an orchestrator, where the way it knows what to do is expressed in terms of a desired state of the systems under orchestration. In the case of TOSCA service
creation, the desired state can be expressed as the pair of a TOSCA specification and a set of input values. For TOSCA service destruction, I am not sure how we express the desired state of now that service should no longer exist , because I am still not
sure how we identify a previously created service. Basically, without having defined identifiers for deployed services, the concept of that service with TOSCA eludes me.
In the Intent paper, referenced above, there is the distinction between Goal and Intent, and I think Goal is the same as Desired State . A TOSCA template is not a Goal, but
a Goal can be created by combining a template with a specific input and an entry point (deploy, undeploy, update/modify, upgrade, ). An Orchestrator that does that can be said to be doing desired state orchestration .
From: Chris Lauwers [ mailto:
lauwers@ubicity.com ]
Sent: 10. januar 2022 22:32
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
Cloud native orchestration
I think we should wait for Tal s input. I am no expert in that. I just gave it a shot.
I d love to get some closure on this. I d like to present the following (likely controversial) opinion: for users of Orchestration, the following concepts are equivalent and
mean the same thing:
-
Declarative orchestration
-
Cloud-native orchestration
-
Intent-based orchestration
-
Desired state orchestration
If you disagree, please let me know why and how these concepts are different.
Thanks,
Chris