Hi Chris,
Again good questions.
And what do you mean by production rules
Each line in a BNF defines how to produce some part of the language. In general production rules are also a key part of logic reasoning producing true results
from other true results.
Graph grammars have similar rules for transforming one valid graph into another. This is particularly relevant for day-2 scenarios where you want to transform
an already deployed topology into something modified to express a changed intent, for example.
Substitution mappings are also a kind of production rules in this sense.
BNF just formalizes syntax, not the language and its associated semantics.
Of course a grammar is just syntax, a full language consists of grammar, static and dynamic semantics. So the Graph Grammar is not the DSD language it is
just the structural backbone to which the semantics are attached.
The grammar of TOSCA allows you to define any topology consisting of nodes and relationships, i.e. any graph. Now YAML is a bit tricky to express using BNF, but
in principle, we can make a BNF grammar that defines all valid TOSCA specifications (I still think we should attempt that).
Since every conceivable concept in the universe can be described as a graph, this makes TOSCA infinitely flexible, but it also means that out-of-the-box it provides
no information and no constraints whatsoever on which topologies are meaningful and which ones are not. As I wrote below: Flexibility is not the same as good. So for a given class of problems topologies that realize customer access, VPN, etc it is useful
to add information to describe which topology graphs are meaningful realizations of that intent, and which ones are not. There is an elaborate example of this in the presentation I originally gave to the TC.
You can see the graph grammar as a Wizard that helps you define and evolve over time those topology graphs that realize a certain class of intents. Adding a
site to an access topology makes sense, but adding a CRM system does not. This is very similar to syntax directed editing realized by many IDEs for programming languages it uses a grammar to define how to expand, within a set of rules and policies, an
existing definition to another one.
So where a TOSCA specification allows you to define one topology, a specification in the DSD language corresponds to a grammar for a class of TOSCA topologies.
Yes, TOSCA is more than a single topology, because substitutions do actually also define production rules for expanding a grammar, even recursively, as you point out. So in that sense, TOSCA with substitutions is also defining a graph grammar. So you are
actually familiar with the concept but it can be greatly simplified.
It is quite simple to translate TOSCA to DSD we do have such a translator, so this is very similar to what Tal is doing when translating TOSCA directly to K8,
and so I very much support that approach.
The difference is that DSD takes on the task of being a grammar of topology-graphs more directly. Interestingly, the requirements-capabilities functionality (including
dangling requirements) is expressed in DSD as a very simple, easy to understand function call (as in any other function you could think of in TOSCA or HOT). It is extremely simple to read and understand, making the complexities of understanding substitution
mappings in TOSCA a bit odd for me to listen to.
what do you mean by a BNF grammar is not fully compositional
Ok, I may be nit-picking a bit. You can only add a rule in a BNF by adding the new production into one or more existing rules so you need to modify something
in what is already there. Think of object orientation: In Java you can add a class saying Y extends X , instead of having to edit X to add Y there. Martin Fowler has some other great refactoring examples using virtual methods: Assume you have an enum
class with values A, B, and C. You could write your code so that every place the enum is used, you have a switch-statement with a case for A, B, and C. But what if you later add D to the enum? You then have to go visit all those switch-statement to add a D-case
branch. This is not compositional. But if instead you define semantic abstract methods on the enum, and use those everywhere, then when you add D into the enum, you just define those metods for D, and the rest of the code will now work with D without modification.
So when I say compositional , in this context I basically mean that I can add things.
Again, req-caps have that property in TOSCA you can add something new with some capabilities, and then it may be picked up when matched by some existing requirements.
Notice, that I am fond of TOSCA it has all the right elements. Only sometimes, things get a bit more complicated than necessary. Why do we have 6 (or is it
7?) different inheritance hierarchies in TOSCA I have just two in DSD, and that nicely covers everything I see in TOSCA. It just makes life hard for users to understand more concepts than are really needed.
I assume we agree that TOSCA is denotational as well?
Definitely.
Doesn t this example mix and match the semantics of the language vs. the semantics of the program created using the language?
Hmm. There is a coupling in that a language feature can cause problems with hard-to-understand language usage. The comefrom is an example of that.
You should be able to inspect each piece of code written in a language to understand what it does without having to understand all other parts of the program.
And once you understand what it means it shouldn t change if you modify some other part of the program. An example that violates this is macros in C. A program that makes heavy use of macros can be extremely hard to understand because adding a new macro could
have unforeseeable consequences.
Yes, the individual program is doing the misuse of macros, but it is the language feature that makes this likely to happen.
This is important for language design particularly for me in DSD, but I am not saying that TOSCA has any such a problem this is really just my own concern
as a language designer.
I absolutely try to look at TOSCA as a programming language. My orchestrator doesn t know how to do anything other than what it is programmed to do by TOSCA service
templates, i.e. by applying TOSCA language semantics to those templates. Also, substitution mapping is definitely intended to be recursive.
You could define a programming language using XML or YAML syntax. There are rules for XML and YAML, but they have no semantics of their own it is all down to
how they are interpreted. Having a system that interprets XML or YAML as a programming language does not turn XML or YAML into programming languages themselves.
Now TOSCA is a lot stronger and has more semantics that XML or YAML, but it still fits very precisely into the OASIS family I mean this in a very positive way.
To be a programming language TOSCA needs to be Turing-complete. Function and Logic programming languages achieve Turing-completeness through recursion. I guess
you could achieve Turing completeness in TOSCA using recursively expanding substitution mappings, but the purpose of substitution mappings is not to make TOSCA Turing-complete. TOSCA is not striving to be a programming language in this sense, and it shouldn t.
Basically, I find the semantics of TOSCA very loosely defined. Yes, there are the things you mention, but there is a lot of room for interpretation. If you give
the same TOSCA definition to your orchestrator, to one of Tal s and to mine, the result would not be expected to be the same, would it?
As I remember our discussions over the past year, we have explicitly avoided any such strong portability requirements for TOSCA. This is fine it is a deliberate
decision, and it is ok. We just need to distinguish between the specific ways that each of us interprets and strengthens TOSCA in our implementations and TOSCA itself.
I don t look at undeploy as a way to undo
Ok.
I maintain that there really are only 5 canonical entry points into a TOSCA service template to which all other actions can be reduced: deploy, undeploy, update/modify,
upgrade, and run workflow
I recognize these, but I also have recreate . Assume the topology you deployed in the infrastructure is somehow damaged out-there in the real world, then recreating
it or part of it is really a useful action to recover.
Basically, I find two modalities out-there in the target systems. Set or Recreate. Some things can just be updated by sending a new declarative update. In other
cases what was there before needs to be destroyed before something new can be pushed. Note that recreate does not mean just to recreate in exactly the same way but rather to recreate under new circumstances. In a TOSCA context, an entry point to reevaluate
the conditions for a previously performed substitution may lead to a different substitution happening than the last time. So in DSD that would be an example of recreate . Maybe that is what you mean by upgrade ?
Cloud native orchestration
I think we should wait for Tal s input. I am no expert in that. I just gave it a shot.
Peter
From: Chris Lauwers [mailto:
lauwers@ubicity.com]
Sent: 8. januar 2022 00:58
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
Hi Peter, more questions (that will show my ignorance)