Type URI Prefixes
In order to avoid naming collisions with other TOSCA definitions existing in the industry, the TOSCA type definitions of this Data Model will use the onap.* prefixes as part of their fully-qualified names (URIs).
Note
The qualifying prefix onap.* here is a just "quarantine" zone where new TOSCA types of the ONAP DM will stay as long as they are being discussed.
Has a type reached its maturity, an action should be taken to make this type part of the tosca.nfv.* namespace.
onap.* | |
onap.datatypes.* | |
onap.nodes.* | |
onap.capabilities.* | |
onap.policies.* | |
onap.groups.* |
Lowercase & Uppercase
All lowercase for namespace prefixes: tosca.onap.capabilities.Root.
UpperCamelCase for all shorthand (i.e., not including the namespace part) type names: Root, VirtualLink, SoftwareImage.
lowerCamelCase or snake_case for names of properties, attributes, inputs, capabilities, requirements, etc.
Type Names
The TOSCA types used to reflect the ETSI “descriptor” concept should be named without adding special postfixes like *D, *Desc, *Descr, etc.
Reason: in this DM, the representations of “Description” and “Instance” objects are distinguished very clearly: the ETSI “Descriptions” are modelled as node types, while their “Instances” are modelled as node templates (ref to the Patterns section). Therefore, there is no need to overload type names with unnecessary postfixes.
shitao li : The suggestion is fine, but the reason is a little bit confuse, in TOSCA ,
A Node Type is a reusable entity that defines the type of one or more Node Templates.
A Node template is an instance of a specified Node Type and can provide customized properties, constraints or operations which override the defaults provided by its Node Type and its implementations.
while in ETSI NFV, "descriptor" is a concept in the design mode, "instance" is a concept of runtime model.
12 Comments
Andrei Kojukhov
Sitao,
I think you just rephrase what Anatoly mentioned:
Agreed?
Lingli Deng
Hi guys, I suppose it might be better we avoid the confusion here. By Design time, we usually talks about the practice of taking input of VNF packages/artifacts and output the templates for a certified VNF, network service or end-to-end service by SDC. Those templates are used in the Run Time to initiate instances of VNF or service. This is different from what Anatoly meant in his description I believe. If we need to reload the terms for Design Time and Run Time, it is for the best to clarify the difference and avoid confustion.
Anatoly Katzman
Agree. I have just put up a brief summary of the differences between the two models: Design-Time Data Model vs Run-Time Data Model.
I believe that the term "instance" contributes to the confusion most of all. Both the Design-Time and Run-Time models use this term, but these are totally different instances. In design-time, the term "instance" unfortunately stands for an inclusion of a lower-level template into a higher-level composition. This is why here I propose the term "occurrence" for what today is called a design-time instance.
shitao li
Anatoly Katzman I agree, call it "occurrence" is more appropriate.
Andrei Kojukhov
So a Node Template is an occurrence of a Node Type? Actually it is quite close to how TOSCA YAML standard defines a Node Template and how it relates to Node type;
A Node Template specifies the occurrence of a software component node as part of a Topology Template. Each Node Template refers to a Node Type that defines the semantics of the node (e.g., properties, attributes, requirements, capabilities, interfaces). Node Types are defined separately for reuse purposes
shitao li
First, node type and node template are all design time concept in TOSCA (I mean tosca-simple-profile-yaml), TOSCA has defined those normative node types for people to use, such as compute, storage, network. For a specific cloud service design, the designer can model the topology of the serivce by using a topology template in a service template, then each component of the service can be modeled as a node template with approproate node types in the topology template.
TOSCA is working on another spec which is called instance-model, before this spec, TOSCA is mainly about design time model.
Andrei Kojukhov
Ok, so we agree on this point.
Andrei Kojukhov
Lingli,
Node templates while used by TOSCA processor at run-time are part of VNF descriptor service templates and provided by VNF vendor as part of a package.
So they relate to both design time and run-time.
Anatoly Katzman
In response to shitao li:
>>>>>>>>
shitao li: tosca.onap.* is not prefix as used in OASIS TOSCA?please refer to ONAP R2+ Naming convention discussion for detail. I think tosca.onap.* should relate to type name defintion convention.
<<<<<<<<
Shitao, you have a good point here, calling that section "Namespace" was very misleading. I have renamed the section to "Type URI Prefixes". In addition, I have adopted your proposal for the onap.* prefix.
Andrei Kojukhov
So I would like to see an example for ONAP profile. An example for node type for TOSCA NFV profile is tosca.nodes.nfv.VDU.
Chesla Wechsler
I know I'm commenting late, but if you don't include D or Descriptor, etc., here, what do we want to call the runtime node type for a VNF? Does that then have to be VNF instance? I would contend that more time is spent talking about runtime instances than descriptors or models (done once as the cookie cutters, then reused to create the cookies). Perhaps using D or Desc or Descriptor here is the better place to keep things distinguished than from the runtime model? Is there any thought to onap.design.<design time objects> and onap.runtime.<run time objects>?
Anatoly Katzman
This is a design-time model, knows nothing about run time.
Run-time instances should be captured by another model, which doesn't have to be TOSCA by the way.