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.