attributes InstanceAttribute 0..N Corresponds to the attributes defined in the group type and holds the actual attribute values. Each attribute value indicates the value at the time the attribute was accessed. Attributes reflect the state of the underlying group and may change at any time. capabilities InstanceCapability 0..N Corresponds to the capabilities defined in the group type and desired values specified in the group template. Each capability property value indicates the final value used by the orchestrator for that property requirements InstanceRequirement 0..N Maps the source instance in a requirement relationship to the target instances. The mapping is 1 to N and does not have to be 1-1 or onto with respect to all source and target instances. Figure 6 Structure of InstanceGroups, shown as a UML class diagram InstanceMetadata Definition InstanceMetadata consists of named objects (a map: name InstanceObject). Because InstanceObjects → can encoded arbitrary information, virtually any information can be added to the instance model as InstanceMetadata. The instance model version is required (e.g., tosca_instance_version: tosca_simple_yaml_1_0) Orchestrators may add any additional metadata they like, such as their name and version, licensing, location, signatures, etc. InstanceMetdata should really be part of InstanceObject so any entity in the instance model can encode any information (like annotations) as InstanceObjects. InstanceInput Definition For each input in the service template, and InstanceInput instance is created containing the value used by the orchestrator for the input. Each InstanceInput is a <name, value> pair consisting of the name of the input in the respective TOSCA input definition and the value of the input encoded for the respective type of the input in the TOSCA input definition. InstancePolicy Definition For each policy applied in the service template, an InstancePolicy instance is created and, if applicable, references from the InstancePolicy to the instance model entities the policy is matched are created. Note that not all policies may be used by the orchestrator if they don’t match with entities in the final service topology created by the orchestrator.
attributes InstanceAttribute 0..N Corresponds to the attributes defined in the group type and holds the actual attribute values. Each attribute value indicates the value at the time the attribute was accessed. Attributes reflect the state of the underlying group and may change at any time. capabilities InstanceCapability 0..N Corresponds to the capabilities defined in the group type and desired values specified in the group template. Each capability property value indicates the final value used by the orchestrator for that property requirements InstanceRequirement 0..N Maps the source instance in a requirement relationship to the target instances. The mapping is 1 to N and does not have to be 1-1 or onto with respect to all source and target instances. Figure 6 Structure of InstanceGroups, shown as a UML class diagram InstanceMetadata Definition InstanceMetadata consists of named objects (a map: name → InstanceObject). Because InstanceObjects can encoded arbitrary information, virtually any information can be added to the instance model as InstanceMetadata. The instance model version is required (e.g., tosca_instance_version: tosca_simple_yaml_1_0) Orchestrators may add any additional metadata they like, such as their name and version, licensing, location, signatures, etc. InstanceMetdata should really be part of InstanceObject so any entity in the instance model can encode any information (like annotations) as InstanceObjects. InstanceInput Definition For each input in the service template, and InstanceInput instance is created containing the value used by the orchestrator for the input. Each InstanceInput is a <name, value> pair consisting of the name of the input in the respective TOSCA input definition and the value of the input encoded for the respective type of the input in the TOSCA input definition. InstancePolicy Definition For each policy applied in the service template, an InstancePolicy instance is created and, if applicable, references from the InstancePolicy to the instance model entities the policy is matched are created. Note that not all policies may be used by the orchestrator if they don’t match with entities in the final service topology created by the orchestrator.
TOSCA-Instance-Model-v1.0-wd01-rev06.docx