I tend to agree with Adam: the names weâre talking about are only relevant to the orchestrator (and will likely be used (only) to look up instances by name in whatever database the orchestrator uses). Itâs reasonable to restrict those names,
since there is little benefit to allowing arbitrary names here. 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.
Chris
From: Tal Liron <tliron@redhat.com>
Sent: Thursday, February 20, 2020 5:15 AM
To: adam souzis <adam@onecommons.org>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] Feedback on TOSCA 1.3 spec
I'm saying that if something like this:
node_templates:
'a \U00000041 @ \f b\n" &* ':
type: foo
is considered a valid template you asking for trouble with little gain.
Again, I don't see any technical trouble with implementations dealing with it, there is no security risk (any more than us allowing properties of type "string" to have arbitrary values), and for international reasons we do not want to limit
use of Unicode (see the example I linked). I definitely don't see it in our scope to delve into which Unicode we want to allow (ideographic alphabets) and which not (emojis). Aesthetically some designers' choices of node template names might not seem productive
or appealing, but that is their choice, and software can deal with it.
Even with very restricted limits (ASCII only, lowercase only, no spaces or punctuation) you can make "bad" choices:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
The only technical requirement I think we need is the one we have: that node template names be unique within that topology template. That allows implementations to place them in hashmaps by using the name as key, or to use that name as
a UNIQUE column in a database.
By the way, though the YAML 1.1 spec does require map keys to be unique, some YAML parser implementations (example) do not enforce it. It's worth making sure.
|