-
Type: Bug
-
Status: New
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Profile-YAML
-
Labels:None
-
Proposal:
The Simple Profile spec includes the following grammar for Property Definitions:
<property_name>:
type: <property_type>
description: <property_description>
required: <property_required>
default: <default_value>
status: <status_value>
constraints:
<property_constraints>
entry_schema:
<schema_definition>
According to the spec, this grammar must be used in both Node Types and Node Templates. However, the "properties" sections in node types and node templates have distinctly different goals:
- Property sections in Node Types are used to "declare" the presence of Properties, very much the same way one declares variables in programming languages. The spec uses the following example:
num_cpus:
type: integer
description: Number of CPUs requested for a Compute node instance.
default: 1
required: true
constraints: - valid_values: [ 1, 2, 4, 8 ]
- Property sections in Node Templates are used to assign values to properties that were previously defined in the associated Node Types. The spec includes the following compute node example:
node_templates:
my_server:
type: tosca.nodes.Compute
properties:
num_cpus: 2
Clearly this "properties" grammar is very different from the "properties" grammar in Node Types, but nowhere is this distinction documented.
The same problem exists for "attributes" and "capabilities" as well: the attributes and capabilities sections in Node Types declare the presence of these attributes and capabilities, and the attributes and capabilities sections in Node Templates assign values to previously declared attributes and capabilities.
Capabilities seem to introduce one more complication. Section A.4.16.3 includes the following example:
some_capability:
type: mytypes.mycapabilities.MyCapabilityTypeName
properties:
limit: 100
In this example, the presence of a capability of a certain type is declared, and then in the same declaration a value is assigned to one of the properties in the capability. Not sure if this is a valid use case, but either way this grammar isn't documented anywhere.