Hi Peter,
I think that with sufficient abstraction, all of your firewalling concepts should be expressible in TOSCA. I use an abstraction framework based on John Strassner s Policy
Continuum . The policy continuum states that policies can be expressed at various levels of abstractions, and it introduces examples of these different levels of abstractions. While John was focused on policies, the levels of abstractions framework extends
naturally to modeling as well, and in my opinion the combination of models with associated policies at different levels of abstractions provides a very nice construct to automate intent. I m attaching a slide introducing John s different levels of abstractions,
and how this can be used for real-time media delivery. I d love to work with you to apply this to your firewalling example.
Thanks,
Chris
From: Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com>
Sent: Sunday, June 13, 2021 11:26 PM
To: Tal Liron <
tliron@redhat.com>
Cc: Chris Lauwers <
lauwers@ubicity.com>;
tosca@lists.oasis-open.org Subject: RE: [tosca] On "complex"
In my world, intent is expressed by the difference between firewall and firewalling .
My
intent is that there must be firewalling in place between two logical connectivity domains.
The
realization of firewalling could be many things, depending on many actual circumstances ...
a firewall between two actual networks
Virtual firewall
Physical firewall
A slice of a physical firewall
several firewalls deployed in the right places, or
SDN configuration rules deployed on all routers with access to the networks
?
Note that the firewalling intent will need user-defined inputs what kind of firewalling is required? Is any specific content-type to be blocked? Just a simple
routing rule that isolates content? Encryption? ? The realization will depend on these choices, and in a day 2 scenario, the inputs may be modified so that the previous realization is no longer possible, and a different realization must be deployed in its
stead.
Is TOSCA today able to express the intent of firewalling, or only the various realizations of that intent?
You can place an abstract node to express some realizations that use a single firewall (virtual, physical, ), but some of my examples above are not really expressible
like that. Using SDN technology, for example, firewalling is a distributed property of multiple router configurations and if someone adds a router, then it must also have that configuration in order to realize the full intent. How is that expressed as a
node in a topology?
The intent of firewalling can of course be hand-waved as a Policy, but that basically just delegates the responsibility for the intent to some hard-coded functionality
in the orchestrators, and that to me is not the same as being able to express the intent in the TOSCA language . That to me seems like it is just a catch-all saying If you have an intent that is not expressible as nodes and relationships, then simply invent
a custom Policy to express it .
I am probably not sufficiently experienced with TOSCA to see some obvious answers to the above.
Peter
From: Tal Liron [ mailto:
tliron@redhat.com ]
Sent: 10. juni 2021 18:31
To: Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com >
Cc: Chris Lauwers <
lauwers@ubicity.com >;
tosca@lists.oasis-open.org Subject: Re: [tosca] On "complex"
On Thu, Jun 10, 2021 at 2:57 AM Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com > wrote:
I see (at least) four roles related to the use of TOSCA:
We can expand this list to many, many more when thinking of the broader business and industry use cases.
I'm OK with the charter as is, but I agree that in the actual spec we need to be specific about roles. Now that we take profiles more seriously we are indeed reworking the spec for the two different kinds of design roles (topology designers
vs. profile designer).
The reason I'm OK with the charter is that the bottom line for all this technology -- cloud and automation -- is business: reducing operational costs while providing customers with what they need. The key words are efficiency, flexibility,
agility. "Easy" is not altogether useful. And "simple" ... not useful at all for me.
I'm personally not afraid of the word "complex" in this context. A complex problem wants solutions that match its complexity toe to toe. I'm more afraid of abstractions that attempt to hide away complexity, effectively passing the buck
to another part of the system and leading to integration nightmares.
I see the distinctions missing in some discussions for example about intent . In my world, the designers
do not have any intent of their own, designers just create the templates that satisfy the intents of the deployers on behalf of the end-users.
Good point. I will just point out that the word "intent" is often used as a technical synonym for "declarative". But, it's often worth taking a step back and reminding ourselves what we're intending to achieve vs. what we are able to declare
and are declaring. The two words are different.
This is exactly where I get lost in the "substitution mapping" discussions. I think we sometimes lose track of the actual real-world problems and get caught up in our own grammatical webs.
Attachment: Model Continuum.pdf Description: Model Continuum.pdf