Node templates as specifications (and implications for node filters)

[tliron]

WHAT IS A NODE TEMPLATE?

When a TOSCA service template is instantiated we assume that all its node templates would also be instantiated. From an orchestration perspective this could involve a wide range of diverse activities such as provisioning resources, configuring routes, allocating connections from a pool, and even delegating the whole process to a subsystem external to the orchestrator. We want TOSCA to cover all of these uses.

But what does "instantiating" mean from TOSCA's perspective? TOSCA 1.3 suggests that there is a difference between the normal semantics of instantiation and something called "selection". The very suggestive (and very brief) section 2.9.2 presents an example of the node template being "abstract", the idea being that if the select directive is used then instantiating should make use of a preexisting node representation. The assumption here is that there exists a store of node representations, which conform to the appropriate TOSCA node types, and that we can use filtering grammar to "select" one (and only one?) of them. This of course has profound implications for the TOSCA processor model, which we have considered. But many questions remain and we should think carefully about the semantics and grammar.

First, I want to point out that the suggested TOSCA semantics are not the same as the orchestration semantics. I would imagine that in many cases node representations would be created as needed for preexisting resources, irrespective of any TOSCA directives. This depends entirely on the semantics of what that node type represents:

• A virtual machine is a "provisionable" resource, so it's easy to imagine that instantiating a node template would involve creating it, though pools of pre-provisioned VMs could also be used. We could decide on a 1:1 relationship between node representations and VMs and let TOSCA users control the decision, but this might be an opaque implementation detail in some cloud platforms. For example, a smart platform might self-optimize and automatically pool VMs when necessary, i.e. when a certain class of them is requested often. The more interesting question, then, is whether we would be OK with using a VM which does not match our required properties exactly. For example, if we need 1GB of RAM, but the platform optimized and created a pool of VMs with 2GB of RAM, we would usually still be OK with that, at least normally.
• A baremetal machine cannot be created (unless we find ways to 3D print computers in the future!), so the only possible orchestration semantics would be allocating a machine from a cluster/farm.
• An IP route is a logical entity that is always "created" by reconfiguring routing tables. It's nonsensical to talk about selecting a preexisting route for these. It's not a "resource". Is there any scenario where a TOSCA select directive would be used for these? I can't think of one.

My point in presenting these examples is that all node templates represent a kind of "requirement"—or rather a specification—for the orchestrator. Fulfillment has diverse and sometimes opaque semantics. I do not think it's useful for us to assume that the default relationship between a node template and a "node" is that something new is created. In other words, the issue of whether a "new" node representation is really a new "thing" or just a newly-made representation for something already out there is outside the scope of TOSCA.

SPECIFYING NODES

As it stands in TOSCA 1.3 we have two ways to "specify" nodes to the orchestrator:

• Properties. These are exact values. We "assign" them in TOSCA, but we know they might not actually exist until a "resource" or something else implements them. My point is: properties express what we want. In other words: they are specifications.
• Property filters. We're back at section 2.9.2 here. Simply put, property filters also express what we want. The difference is in the flexibility of their expression, as they can use conditions (e.g. ranges) rather than (and in addition to) exact values. Ignoring TOSCA semantics, there is no real difference between a range and an exact value. An exact value is just a minimal, strictest expression of a range.

This thinking has been guiding my node type designs for a while now. Consider these two examples:

node_types:

  MachineStrict:
    properties:
      ram: { type: scalar-unit.size }

  MachineFlexible:
    properties:
      min-ram: { type: scalar-unit.size }
      preferred-ram: { type: scalar-unit.size }
    attributes:
      actual-ram: { type: scalar-unit.size }

For both of these types, I neither want nor need to tell the orchestrator how to get me a machine. Will it provision a new VM? Allocate a baremetal machine? Or can it use an existing VM from a pool? For my design purposes none of this matters, and in fact I assume that the orchestrator will know much better than I do which solution is most efficient at any given time for any given environment. (If I really want to make sure that my machine is not already in use by any other tenant then I can add a boolean property called "exclusive". In some cases it might not matter either way, so this property does not even have to be required: true.)

The example in section 2.9.2 suggests that the "right" way to implement MachineFlexible is to just use MachineStrict with a select directive and property filters. I think this is not good advice. Firstly, because, as I point out, as a designer I do not differentiate between selection and "non-selection" (whatever that even means, exactly). But, secondly, and perhaps more convincingly, the property filter grammar is woefully insufficient. Even when considering our recent discussions on beefing up the grammar, we are still missing the more subtly important semantics. It can't even express the trivial semantics I've used here: I need a minimum amount of RAM but will work best with a higher amount of RAM. And that's just a very simple example. Consider more complex (but fully realistic) semantics:

data_types:

  MachineConfig:
    properties:
      min-ram: { type: scalar-unit.size }
      preferred-ram: { type: scalar-unit.size }

node_types:

  Machine:
    properties:
      basic-config: { type: MachineConfig }
      performance-config: { type: MachineConfig }
    attributes:
      actual-ram: { type: scalar-unit.size }

Here we're giving the orchestrator two choices of specifications. And this is not only for initial deployment: imagine that the orchestrator could migrate, in Day 2, from a basic-config to a performance-config according to changing conditions. Do we need more bandwidth? Migrate up. Is the cluster too congested? Migrate as many existing machines down to "basic" as you can. There can be policies, even TOSCA policies, to manage the rules and triggers for this behavior.

This leads me to the final big point of this discussion: the relationship between a node template and its node representation(s) is not just a fixed Day 1 absolute. A running service can change node representations if necessary in Day 2. There's nothing in TOSCA that disallows it or that should disallow it. This is not just about changing the attributes of an existing node representation, but about fully swapping implementations in and out. Even types can change, as long as the base type of the node template (its contract) remains intact. This kind of abstraction is the basis for TOSCA substitution mapping as well as the 2.9.2 example of an "abstract" node template, which indeed uses an "abstract" node type (tosca:Compute).

My conclusion is simple: the select directive and the node filter grammar are unnecessary, insufficient, and even confusing for all my use cases. I can do what they do and much more through carefully crafted types, which start from the assumption that every node template is a specification. I have not used the select feature in TOSCA 1.3 and don't see myself using it moving forward into TOSCA 2.0.

EXTERNAL NODES

So does 2.9.2 still have value? I think it might, but not for a select directive, which I don't think think makes sense for orchestration. Instead, it can be used, pretty much as-is, for our new external directive.

After many complex debates we have reached an agreement to support an external directive for requirements, which allows for requirements to be fulfilled with nodes that are not based on node templates within the current service template (TOSCA 2.0 wd05-rev03 5.3.5.3.1). I have been largely unhappy with that feature because it allows for broken Day-0 topologies. By definition the target node is not part of the design and cannot even be directly referred to in TOSCA (only indirectly via TOSCA path). However, I can see the 2.9.2 grammar being used instead of our current solution as a way to resolve almost all my concerns. The idea is simple: move the node filter from the requirements grammar to its own node template, as per 2.9.2.

So, instead of this:

node_templates:

  app:
    type: WebApp
    requirements:
    - host:
        directives: [ external ]
        node: Machine
        node_filter:
          properties:
            ram: { $greater_than: 1 GB } # we're still working out the syntax

...do this:

node_templates:

  app:
    type: WebApp
    requirements:
    - host: server

  server:
    type: Machine
    directives: [ external ]
    node_filter:
      properties:
        ram: { $greater_than: 1 GB }

So much better! The topology is complete. It's a bit more verbose, but that verbosity adds power and clarity.

SYNTAX

The "external" directive must change the syntax for node templates. Clearly we cannot specify anything for an "external"-designated node template except its type and property filters, because all its properties, attributes, interfaces, operations, and even artifacts are "given" to us by that external node representation. Thus there is also no confusion as for the use of SELF in property filters: it always refers to that external node representation. There is no other.

To summarize:

• If an external directive exists then only the type and node_filter keynames are allowed, the former being mandatory (as always). (metadata and description should also be OK.)
• If the external directive does not exist then node_filter cannot be used.

[lauwers]

A lot to digest :-) Would you mind going through this on Tuesday 8/23/2022?

[tliron]

Sure, I can probably summarize it more succinctly. I just wanted to lay out the entire argument.

[calincurescu]

I assume node directives control the creation/modification of the representation graph:

• Thus the default (let's call it create directive) just creates the node and puts it in the representation graph.
• The select directive, just gives a symbolic name to another node, but cannot do anything else since its properties, capabilities, requirements have already been defined. It's like and alias or a symbolic link, to a node it selects via a `node_filter. The selected node might be:
  • local in the same service (created by the same service template), or
  • external to the service (previously created by another service template), the alias thus representing it in the local representation graph.
• The substitute directive creates a special node in the top-level service that is implemented by a set of nodes in the substitution representation graph. Here properties, requirements, capabilities are created as usual but there is also a substitution mapping that maps them to the nodes in the substitution representation graph.

[tliron]

To follow up on today's discussion, we ended up with some of you saying that the default behavior in TOSCA is an implied and implicit "create" of node representations. I don't think we should assume that and I don't think we need to assume that. In my initial example I tried to show that the decision of whether to "create" or "select" a node representation is sometimes (I would think often) not something that concerns the designer, but rather is left to the orchestrator or platform to decide. And this has nothing to do with whether or not the designer wants to create a new resource. The TOSCA semantics and the resource semantics are not the same.

A full example:

node_types:

  Machine:
    properties:
      min-ram: { type: scalar-unit.size, required: false }
      preferred-ram: { type: scalar-unit.size, required: false }
    attributes:
      actual-ram: { type: scalar-unit.size }

service_template:
  node_templates:

    server:
      type: Machine
      properties:
        min-ram: 1 gb

Let's assume that the environment is a TOSCA frontend for a cloud platform, a frontend that's natively integrated into that cloud rather than an external add-on, meaning that the product itself provides TOSCA as an option for interaction. I think that's a scenario we'd all like to see, right? Native support for TOSCA in all cloud platforms? In this case let's assume that this cloud platform has strong inventory management, which can also be accessed with an RPC API. A tool can use CRUD operations in the RPC API in order to manage the inventory resources and relationships between them. Or, it can use the TOSCA frontend to do a more fully topological design. For all APIs there should be only one data store: both TOSCA and RPC refer to the same inventory. So, that inventory is the node representations, at least for some node types. Of course there may be various node types that refer to other subsystems: a User type interacting with the cloud's RBAC system, logical features that exist on specific applications, etc. In every case we don't want to create multiple sources of truth. We don't want to require implementations to create a duplicate database just to support some specific TOSCA features, right? That is a very hefty requirement that would immediately make TOSCA at best a 2nd-class citizen in these situations, at worse it would be impossible to support. Storage is not free and data duplication has severe logistical costs. The good news is that I don't believe we have to make that requirement.

So, in our example above, what node representation would be used for the node template? Would a new inventory item be created (equivalent to Create in the RPC API) or would an already-existing one be used (equivalent to Get in the RPC API)? The point I want to make is that this is an implementation detail and that it is not a good idea for TOSCA to have opinions on implementation details when unnecessary. And it doesn't matter for TOSCA: the bottom line is that the node template would finally refer to a node representation, assuming deployment is successful.

What if the designer does want to specify that they want a "new" machine? Of course, what "new" means may not have anything to do with TOSCA node representation semantics. A "new" baremetal machine doesn't mean "3D print a new computer for me". It means "use an existing machine that has not already been allocated to other tasks". For our cloud, it means that machine is already in the inventory (Get in RPC). In the case of virtual machines, "new" could mean two things: 1) provision a new VM (Create in RPC), or 2) use a pre-provisioned VM from a standby pool (Get in RPC). Does the user care which one of these options is used? Would they even know? These are all implementation semantics.

I would enable this feature like so:

node_types:

  Machine:
    properties:
      min-ram: { type: scalar-unit.size, required: false }
      preferred-ram: { type: scalar-unit.size, required: false }
      exclusive-only: { type: boolean, required: false }
    attributes:
      actual-ram: { type: scalar-unit.size }

  VirtualMachine:
    derived_from: Machine

We can use the Machine type if we don't care about whether it's baremetal or virtual, or VirtualMachine if we do care. We can control the "newness" of the resource by setting the exclusive-only property. Again, we don't care about whether or not this is a new node representation: it might already be in the inventory. What we care about is that nobody else is using that resource, hence the name of the property is not new. Of course there may be cases, for some resources, where actual newness is an issue. In that case, sure, go ahead and create a property named new.

All this is to say that whatever problem we are trying to solve with the directives and node_filter keynames in TOSCA shouldn't have anything to do with all of the above. If we try to turn directives into actual orchestration semantics we will end up having overly strong opinions about the implementation that would make TOSCA an awkward if not impossible fit for many common cloud scenarios.

[tliron]

Some progress on alignment we made today:

1. I think we all agree that even though TOSCA 1.3 section 2.9.2 is named "Using an abstract node template to define infrastructure requirements for software", we don't think that "abstraction" is the right use case or purpose for this grammatical feature. Rather, we all understand it as a complement (I see it as a replacement) for requirement fulfillment.
2. Calin is pointing us to the right direction in terms of how this feature can be properly understood: it has to do with indirection. Calin understands it as an extra level of indirection (an alias): so node_template2 could be an alias for node_template1 which actually refers to a node representation. I propose that we don't describe this as an extra level. Instead, we can say: both node_template2 and node_template1 refer to the same node representation. I think the "alias" idea is especially difficult to put in place if we deal with external node representations: node_template2 would be an alias for what? That external node representation might not even have any node templates associated with it, and if it does we can't access them in TOSCA (that's what external means, by definition). So, to me, a simple indirection is best: every successfully deployed node template is associated with a node representation. What we are allowing for is a many-to-one association between node templates and node representations.
3. Where we're stuck is in understanding how the association between node templates and node representations is made at that moment of deployment (Day 1). I insist that it's not about "creation vs. selection" because TOSCA should not have an opinion about inventory management (see arguments above: we don't want to force implementations to create an additional inventory system just for the TOSCA frontend). Moreover, we didn't talk about Day 2 today, but consider that the platform might "swap out" node representations with new ones (must be equivalent). For example, if a VM fails a new VM can be created automatically by the platform with all the same TOSCA associations. A new VM means a new node representation in the inventory (or a VM already existing in a pool). To me "creation vs. selection" is an irrelevant and unnecessary distinction if what we're talking about is indirection (point 2 above).

[lauwers]

This discussion illustrates how different applications of TOSCA may need to interpret different TOSCA features differently, or may not need certain features:

• In Tal's examples, TOSCA is expected to be used as a frontend to Cloud platforms that already have their own orchestration semantics. TOSCA is used to encode the abstractions already supported by the Cloud orchestrator. Or, said a different way, the orchestration semantics are tied to the types defined in TOSCA. In the example presented above, an orchestrator is expected to know that a property called preferred-ram signals a preference for a given amount of RAM.
• In a pure TOSCA orchestrator, on the other hand, all the orchestration semantics are provided by the TOSCA language only, and no semantics are associated with specific types. This means that we can't "... leave decisions up to the orchestrator..." since a TOSCA orchestrator won't know how to do anything that it hasn't been explicitly instructed to do using TOSCA as its programming language. Specifically, a TOSCA orchestrator will never be able to decide whether to re-use an already existing node vs. creating a new node.
  Fortunately, the TOSCA spec anticipates these different uses of the language and the directives keyword was introduced expressly to support the pure TOSCA orchestration scenario. The 1.3 spec defines the directives keyword as follows:

directives:  An optional list of directive values to provide processing instructions to orchestrators and tooling.

What this implies is that directives should only be used in those scenarios where the orchestrator needs such instructions. If your Cloud platform already knows what to do, then directives are not needed and they should not be used. We should clarify this in the spec.

[tliron]

I think that's not a bad direction, but if that's the case we cannot attach special grammatical "powers" to directives. Right now "select" and "substitute" definitely affect other keynames so that they cannot be ignored by any TOSCA processor, even if the orchestrator has no use or support for them. If we can find a way to make them more transparent and optional then I am very much for it. Alternatively, for these specific features we might better use keynames instead if we want them to have grammatical effects.

As for your second point, that a generic orchestrator won't know what to do with types, well, isn't that what interfaces and artifacts are for? You could associate a Python script (artifact) with a node type that would know exactly what to do with preferred-ram (and Python would always be able to do programmable things much, much better than TOSCA). We took care to remove the "standard" lifecycle interface from TOSCA (the one in the old Simple Profile), and I think likewise we should not have lifecycle-related features in the grammar. The decision on whether to create/provision or select/reuse is, to me, exactly lifecycle-related. I would suggest that real code (e.g. Python), rather than the anemic node filter syntax, would provide a far better orchestration experience than generic CRUD-like operations, and that TOSCA is very well suited for such custom LCM semantics. For example, if you had an operation called "provide" you could intelligently create or reuse a node representation according to properties, external inventory systems, current bandwidth, etc. And each type can have its own appropriate semantics.

And just to say generally -- we are three people working mainly right now on TOSCA 2.0. None of us represents the entirety of users and potential users, so we all should represent them as best we can and always err on the side of not overreaching the spec. I'm strongly opposed to TOSCA dictating a specific data model or its semantics, as it makes TOSCA immediately unusable for existing systems.

[pmjordan]

I am no longer either a user or even a potential user; all I can do is think back to when I was in that category. When I do so I am clear that there are scenarios where I would want the orchestrator to act as described in the cloud front end example from @tliron but also scenarios where I want to use TOSCA to ask the orchestrator to allocate from a known resource pool and to add additonal resources to that pool.

I'm afraid that I'll have to leave it to the main three to propose syntax that can support that.

[tliron]

Thanks for your input, @pmjordan. I'm actually most in favor of what I understood directives to be originally: generic strings that can be used by any orchestrator as hints for any purpose. The spec could then suggest a few real-world examples, but I don't see a need to standardize them (as such). Except ... that we have associated specific grammatical features with specific directives. If we find a way to decouple that relationship then I think the sky is the limit.