RE: [tosca] Towards an instance model for TOSCA

[Chris Lauwers <lauwers@ubicity.com>]

Our emails crossed, but as I stated in my earlier email, this is exactly what âselectableâ node templates with ânode filtersâ are for. No need to introduce new grammar (or new interpretation of grammar) although I do agree that the current node filter grammar is insufficiently flexible.

 

Thanks,

 

Chris

 

From: Tal Liron <tliron@redhat.com>
Sent: Thursday, October 03, 2019 7:59 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Towards an instance model for TOSCA

 

Quick addendum. :) I can foresee the argument that a node template is too explicit a way to specify the "dangling" requirement. What if I want to allow for a filtering-like or matching ability? What if I don't want a server with exactly 16 gb of RAM? How about this:

 

node_templates:

  my_app:

    relationships:

    - host: my_server

 

  my_server:

    properties:

      archs: [ x86, arm ]

      min_ram: 16 gb

 

One might argue that it's annoying to have to create node types that include these "matching" parameters. I would argue, as I have for so long, that our Simple Profile has always been poorly designed and that it encourages the wrong kinds of practices for node template design. All node templates are best understood as "matches" for node instances, rather than explicit descriptions of specific node instances. Node types (and capability types) should always be designed with such matching in mind.

 

A related point: we have discussed the option of enriching the requirement grammar to allow for better matching. I imagine that we had in mind a requirement grammar that could express that "min_ram", "max_ram" and "one of these architectures" features I implemented above using properties. Well, I would argue that we would never be able to create a properly universal grammar for this, because the "matching" parameters are always implementation-specific and use-case-specific. Consider a more complex example:

 

  my_server:

    properties:

      archs: # numbers represent preference priorities

        x86: 1 # favorite

        arm: 2 # less favorite

        risc-v: 2 # this is equally preferable to arm

      ram:

        preferred_min: 16 gb

        acceptable_min: 8 gb # we can accept this if we have no choice, but prefer not to

      features: # numbers represent degree of requirement

        dpdk: 1.0 # a 1.0 means "must have"

        mmx: 0.9

        avx512: 0.5 # 0.5 and lower are "nice to have"

 

As you can see, we can allow for the orchestrator to have sophisticated "matching" (or provisioning, allocating, etc.). Really, we can allow for any kind of matching feature in this way. If we define a rich requirement grammar instead, orchestrators would always be limited to whatever grammar we provide. Which will surely always be insufficient as new technologies po up. Or even: too sophisticated. Some orchestrators would not be able to implement a very sophisticated requirement grammar. Finding ways to restrict such grammar to match the orchestrator's apabilities would be extremely complex.