RE: [tosca] On "complex"

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.

tosca message