Re: [tosca] On "complex"

[Tal Liron <tliron@redhat.com>]

Peter, it seems your definition of "intent" here is decidedly abstract. You "intend" a general result without caring and without specifying the implementation.

TOSCA can be as specific as you want it to be.

I agree that for the level of abstraction you want in this case a policy might be best. But I can also see "firewalling" expressed via relationship types or node templates.

As I've expressed numerous times, I think TOSCA would have been more expressive if it weren't object oriented. If nodes were assemblages rather than objects then we could bundle in "firewalled" as a capability. As it stands if we want to enable it right now we would have to re-derive all our node types from a "firewallable" base type, or else make sure that the capability is built-in at the root node type. Policies are the best solution for grammatical reasons -- it's the only way to bundle-in extra properties to existing types.

As for policies being "custom", I don't really understand why they are more custom than, say, a relationship type. It's true that we can do more to make the policy grammar more expressive, but I wonder what more you would need in this case. How about just associating an artifact with the policy, as its implementation? We've been discussing making artifacts more flexible than they are now.

On Mon, Jun 14, 2021 at 1:25 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:

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

oÂÂ Virtual firewall

oÂÂ Physical firewall

oÂÂ 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.