RE: [tosca-comment] Feedback on TOSCA 1.3 spec

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tal,

 

There is always a balance between restricting (i.e. limiting what are considered valid values for entity names) and protecting (i.e. warning the designer when theyâve likely made a mistake). Youâre arguing against any restrictions, which would then also result in no protections. Adamâs suggestion of modeling after XML might be an acceptable compromise. Do you see use cases where this is too restrictive?

 

Thanks,

 

Chris

 

 

From: Tal Liron <tliron@redhat.com>
Sent: Sunday, March 1, 2020 3:57 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: adam souzis <adam@onecommons.org>; tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] Feedback on TOSCA 1.3 spec

 

On Sun, Mar 1, 2020 at 12:33 PM Chris Lauwers <lauwers@ubicity.com> wrote:

I tend to agree with Adam: the names weâre talking about are only relevant to the orchestrator

 

Aren't they more relevant to the designer? Imagine a rich graphical TOSCA design studio where you drag and drop icons representing node templates. Those names are useful and relevant specifically at the design level and may represent architectural concepts, rather than a compute resource at a (possibly unknown!) target domain. That's exactly the kind of abstraction TOSCA is supposed to provide. Otherwise we would just be using Heat templates or Kubernetes specs.

 

I hope you aren't thinking about restricting type names, too? Couldn't they potentially have some kind of runtime reality? (it all depends, it's all implementation-specific)

 

(and will likely be used (only) to look up instances by name in whatever database the orchestrator uses).

 

If that's the case, all lookup technologies should support arbitrary strings. Again, I don't see a problem or any reason to restrict.

 

Itâs reasonable to restrict those names, since there is little benefit to allowing arbitrary names here.

 

What benefit would we get from restricting database key values? I see only cons and limitations

 

Generally, more restrictions = more difficulties, less restrictions = more opportunities.

 

Think of another design use case: generating TOSCA service templates automatically from some existing system/deployment, in which case node template names might reflect some kind of runtime reality. What if we decide to forbid slashes, but the runtime environment uses them in some important way? Restricting names would create a burden, which to me seems wholly unnecessary.

 

I'm very worried that this restriction will hamper valid use cases, especially those we cannot think of yet.

 

Any domain-specific names (e.g. the name to assign to an Openstack Compute instance or a Kubernetes deployment name) should be modeled as properties, and handled transparently by the orchestrator. For such properties, we must allow arbitrary values as Tal suggests.

 

You seem to agree, then, with my first paragraph: node template names do not have to be the domain-specific name, and properties may often be better suited for this role. Does your domain have restrictions on names, as most do? Then, create a data type that has a regex constraint for it. Do you want to use the template name as is? Fine, just take into account that it can be an arbitrary Unicode string of any length.

 

By the way, let's all remind ourselves that these are node template names, not node instance names. Assuming an orchestrator wants to use these names directly (instead of using a property, as you and I suggest), node instance names might be more likely generated from some kind of template system, e.g. adding a number or UUID to the node template name. The best solution, I think, would be to incorporate templating in your orchestrator. Imagine something like this:

 

topology_template:

  node_templates:

    server:

      type: VM

      properties:

        instance_name_template: server-{clusterId}-{instanceId}-{revision}

 

The "instance_name_template" could then be rendered by the orchestrator at runtime, using runtime values that cannot be known to TOSCA.

 

OFF TOPIC

 

It just occurred to me that it might be useful to have something like a "get_template_name" intrinsic function (with no arguments) to get the name of self, thus allowing the above property to be:

 

instance_name_template: { concat: [ { get_template_name: [] }, server-{clusterId}-{instanceId}-{revision} ] }

 

Or maybe not. :) While possibly useful, it would seem to break a certain unspoken divide between design-time and run-time naming and constructs. It also looks awkward.