<none>: RootNodeType – Part 1
Properties
name type Prescription default description
name (component name)
string optional N/A Component or service common name • This is different than the Node’s “name”
attribute or its “ID”. • It is a property that can be matched via a
requirement.(e.g. for MySQL Community Edition, name=“MySQL CE”)
version(component version)
string optional N/A Component or service’s version.(e.g. for “MySQL”, version might be “5.0.9”
Definition: The fundamental type that all TOSCA NodeTypes derive from.
Interfaces
name description
Install Formerly “create”
configure -
start -
stop -
uninstall Formerly “delete”
suspend CIMI, OpenStack
pause CIMI, OpenStack
capture CIMI
restore CIMI
Requirements
name requirementType lowerbound upperbound constraints
N/A - - - -
Capabilities
name capabilityType lowerbound upperbound constraints
N/A - - -
* Cells shaded in blue indicate suggested new interfaces (operations that correspond to “compute” and “storage”
<none>: RootNodeType – Part 2
Definition: The fundamental type that all TOSCA NodeTypes derive from.
InstanceStates
state Allowed operations description
installing uninstall Being installed.
starting stop, uninstall Being started.
started stop, uninstall (pause, suspend, capture, restore, restart)
Available and ready for use.
configuring ? Should “configure” be assumed to be part of “starting”?
stopping start, stop, uninstall (restart) Being stopped.
stopped start, uninstall (capture, restore, restart)
Powered off; no saved CPU or memory state.
uninstalling Being uninstalled. Note this applies to a CIMI Machine, CIMI Volume, CIMI Network
restart IFF this is justifiable different than a “stop” followed by a “start”
pausing Being paused. Allowable actions : start, restart, and delete.
paused Resources remain instantiated ; processing stopped; not enabled for tasks. Allowable actions: start, restart, backup, restore, delete. (sleep)
suspending Machine being suspended. Allowable actions when in this state are: start, restart, and delete.
suspended machine and its virtual resources are stored on non-volatile storage. (hibernate)
error CIMI Machine, CIMI Volume, CIMI Network
capturing CIMI Volume (snapshot), could apply to VMs?
available CIMI Volume (perhaps use started instead?)
Notes: • If lifecycle operations are sequential (i.e. rely upon script completion) then perhaps allowing operations for “transitional” states do not
make sense. • Seems to help “imperative” models more so than declarative
The set of Potential InstanceState values available for any node:
RootNodeType: Tier (this is a “grouping” type)
Definition
A tier is a topological concept used to describe sets of nodes (or sub-topologies) that can be deployed and managed as a single logical processing element with specific scalability, availability and other group-wise semantics while supporting a specific kind of application processing (sometimes referred to as “roles”). Tiers that support the same kind of application processing are substitutable. The application processing capability of a tier is a function of the kinds of application components which are hosted by its constituent compute elements. The tier’s scaling discipline defines how and when the capacity of the tier is adjusted.
Requirements
name requirementType lowerbound upperbound constraints
N/A - - - -
Capabilities
name capabilityType lowerbound upperbound constraints
nodes ServerContainerCapability 0 unbounded TBD – It seems that “tiers” should capable of containing any type of nodes not just servers.
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A - -
Properties
name type Prescription default description
minInstances integer Required 1 Minimum number of instances for scaling tier (range 1 - N).
maxInstances integer Required 1 Maximum number of instances for scaling tier (range 1 - N).
* This is primarily a grouping concept for scaling. Is there a better way?
RootNodeType : Compute (formerly Server)
Definition
An instantiated compute resource that encapsulates both CPU and Memory. Ideally, this would support a “built-in” host OS (or platform API), as many typical / common use cases assume one.
Interfaces
name parms description
N/A
Requirements
name requirementType lowerbound upperbound description
container ServerContainerRequirement 0 1 Optional.
Capabilities
name capabilityType lowerbound upperbound description
os OperatingSystemContainerCapability 0 1 Optional <or> Runtime Capability <or> VMCapability
Properties (ServerProperties)
Name type Prescription default description restriction
cpuArch string Optional N/A
numCpus integer Required 1 Number of CPUs: Number of CPUs (for the virtual machine).• How does this value factor with “Tier” for scaling? • Note: These could be “virtual” CPUs
• Restricted only by provider capability?
memory integer Required N/A? Memory (in MB): Amount of memory (for the virtual machine)
- Same as above?
disk integer Required N/A? Disk (in GB): Amount of disk space to allow execution of the application (e.g. for the Virtual Machine)• Perhaps define a type based on “integer” that
represents “storage size” Megabytes to be used by both memory and disk properties (and elsewhere)
-same as above?
RootNodeType : Storage
Definition
TBD
Requirements
name requirementType lowerbound upperbound constraints
TBD
Capabilities
name capabilityType lowerbound upperbound constraints
TBD
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
TBD
RootNodeType : Network
Definition
TBD
Requirements
name requirementType lowerbound upperbound constraints
TBD
Capabilities
name capabilityType lowerbound upperbound constraints
TBD
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
logicalName string Logical network name
RootNodeType : OperatingSystem (Optionally merge as a property of “Compute” Node Type)
Definition
TBD – This is typically a guest OS. Ideally, if indeed for 99% of use cases it is simply an OSType and version would like to flatten this conceptually as properties on Server/VM
Requirements
name requirementType lowerbound upperbound constraints
container OperatingSystemContainerRequirement 1 1
Capabilities
name capabilityType lowerbound upperbound constraints
software SoftwareContainerCapability 0 unbounded
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
OS string Optional N/A Opeerating System name (e.g. “Ubuntu”). Note: Still an option to to model OS independently.
OSVersion string Optional N/A Operationg System version (e.g. “12.04)”. Still an option al to model OS independently.
RootNodeType : WebServer
Definition
TBD – Ideally, would like to move towards an “Application Runtime” (indicates additive APIs / language to the OS) since that is its primary purpose.
Requirements
name requirementType lowerbound upperbound constraints
container SoftwareContainerRequirement 1 1
Capabilities
name capabilityType lowerbound upperbound constraints
webapps WebApplicationContainerCapability 0 unbounded
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
N/A
RootNodeType : DBMS
Definition
TBD
Requirements
name requirementType lowerbound upperbound constraints
container SoftwareContainerRequirement 1 1
Capabilities
name capabilityType lowerbound upperbound constraints
databases DatabaseContainerCapability 0 unbounded
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
N/A
RootNodeType : SoftwareComponent
Definition
Provides a simple means to define a generic software component to be modeled and referenced while allowing scripts to be invoked, etc. (Chef cookbooks run etc.) as part of the topology.
Requirements
name requirementType lowerbound upperbound constraints
Capabilities
name capabilityType lowerbound upperbound constraints
InstanceStates
state description
N/A -
Interfaces
name parms description
<derived from Root>
Properties
name type Prescription default description
TBD
RootNodeType : WebApplication
Definition
TBD – “Web” is unecessary, any “Application” with exported endpoints is valid, perhaps just use “Application”
Requirements
name requirementType lowerbound upperbound constraints
container SoftwareContainerRequirement 1 1
Capabilities
name capabilityType lowerbound upperbound constraints
N/A
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
N/A
RootNodeType : Database
Definition
TBD
Requirements
name requirementType lowerbound upperbound constraints
container DatabaseContainerRequirement 1 1
Capabilities
name capabilityType lowerbound upperbound constraints
clients DatabaseEndpointCapability (ConnectionTarget?)
0 unbounded
InstanceStates
state description
N/A -
Interfaces
name parms description
N/A
Properties
name type Prescription default description
TBD
DBName Logical DB Name
DBUser Admin only?
DBPassword Admin only?
DBPort Could this be supplied by “connection” along with IP?
AppLayer (Composite NodeType)(as a Service Template)
PaaSLayer (Composite NodeType)(as a Service Template)
- At its simplest a,“ApplicationRuntime” environment
IaaSLayer (Composite NodeType)(as a Service Template)
Public (Quantum)
Network
SugarCRM with abstract Layers (Node Types) allowing substitution
VM (Nova)
Compute
Apache
WebServer
SugarCRMApp
WebApplication
Linux Operating
System
1..n
IaaSLayer
Layer
PaaSLayer
Layer
Storage (Cinder)
Storage
==
==
hostedOn
PHPModule
ApacheModule
DependsOn
hostedOn
hostedOn
DependsOnSugarCRMApp
WebApplication
hostedOn
hostedOn
DependsOn
RootNodeType : ApplicationRuntime (Composite Runtime Environment)
Definition
Implies a WebServer + one or more LangaugeRuntimes (e.g. PHP, Java, etc.)?
Requirements
name requirementType lowerbound upperbound constraints
Capabilities
name capabilityType lowerbound upperbound constraints
InstanceStates
state description
N/A -
Interfaces
name parms description
Runtimes Dictionary of language runtimes/versions? (e.g. “Java” “6.0”, “Python” “2.6”, etc.)
TBD
Properties
name type Prescription default description
TBD
<none>: RootRelationshipType
Abstract Interfaces
name parms description
preConfigure Optional TBD Nodes on either end of any relationship should support a “pre-configuration” operation (e.g. “preConnect”)
configure Optional TBD Nodes on either end of any relationship should support a “configuration” operation (e.g. “connect”)
postConfigure Optional TBD Nodes on either end of any relationship should support a “post-configuration” operation. (e.g. “postConnect”)
Properties
name type Prescription default description
Definition
The fundamental type that all TOSCA RelationshipTypes derive from.
InstanceStates
state description
N/A -
RootRelationshipType : HostedOn
ValidSource
typeRef description
ContainerRequirement RootRequirementType
ValidTarget
name description
ContainerCapability RootCapabilityType
Interfaces
name parms description
TBD
Properties
name type Prescription default description
TBD
Definition
Relationship that indicates a node can “host” or contain another node of a specified type. For example: • a Database node is “hostedOn” a DBMS (Database Management System) node• a WebServer node is “hostedOn” a n OperatingSystem node.
InstanceStates
state description
N/A -
RootRelationshipType : ConnectsTo
ValidSource
typeRef description
EndpointRequirement RootRequirementType
ValidTarget
name description
EndpointCapability RootCapabilityType
Interfaces
name parms description
TBD
Properties
name type Prescription default description
TBD
Definition
Relationship that indicates a node can “connect” to another node of a specified type. For example: • A WebApplication node “connectsTo” a Database node.
Known Subclasses
IPEndpointRequreiment, HTTPEndpointRequirement, IPEndpointCapability, HTTPEndpointCapabilityCan we not flatten??? Using properties such as “protocol” (or protocol list?)
InstanceStates
state description
N/A -
RootRelationshipType : DependsOn
ValidSource
typeRef description
FeatureRequirement RootRequirementType
ValidTarget
name description
FeatureCapability RootCapabilityType
Interfaces
name parms description
TBD
Properties
name type Prescription default description
TBD
Definition
Relationship that indicates a node is “dependent” on another node of a specified type. For example: • A PHP runtime “dependsOn”an Apache web server
InstanceStates
state description
N/A -
<none>: RootArtifactType
Definition
The fundamental type that all TOSCA Artifact Types derive from.
Known Subclasses• name="ScriptArtifact"
• PropertiesDefinition element="tns:ScriptArtifactProperties" • name="FileArtifact“
• None• name="ArchiveArtifact“
• PropertiesDefinition element="tns:ArchiveArtifactProperties" • name="OsPackageArtifact“
• PropertiesDefinition element="tns:OsPackageArtifactProperties“• name="UserContentArtifact“
• PropertiesDefinition element="tns:UserContentArtifactProperties“• name="RPMGroupArtifact“
• PropertiesDefinition element="tns:RPMGroupArtifactProperties"
WebTier
ScalableTier
ApacheVM
Compute
Apache
WebServer
SugarCRMApp
WebApplication
DBTier
Tier
MySqlVM
Server
MySQL
DBMS
SugarCRMDatabase
Database
ApacheLinuxOS
Operating System
MySqlLinuxOS
OperatingSystem
Advanced SugarCRM Scenario: SugarCRM with Networking
1..n 1
Public
Network
Private
Network
hostedOn
hostedOn
hostedOn
hostedOn
PHPModule
ApacheModule
DependsOn
DependsOn DependsOn
hostedOn
hostedOn
hostedOn
hostedOn
hostedOn
ConnectsTo
WebTier
ScalableTier
ApacheVM
Compute
Apache
WebServer
SugarCRMApp
WebApplication
DBTier
Tier
MySqlVM
Server
MySQL
DBMS
SugarCRMDatabase
Database
ApacheLinuxOS
Operating System
MySqlLinuxOS
OperatingSystem
Advanced SugarCRM Scenario: SugarCRM with Storage
1..n 1
Public
Storage
Private
Strorage
hostedOn
hostedOn
hostedOn
hostedOn
PHPModule
ApacheModule
DependsOn
DependsOn DependsOn
hostedOn
hostedOn
hostedOn
hostedOn
hostedOn
ConnectsTo
<ServiceTemplate id="...“ name="..."? ... substitutableNodeType="..."?>
<BoundaryDefinitions> <Properties> <PropertyMappings> ... </PropertyMappings/> ? </Properties> ? <PropertyConstraints> … </PropertyConstraints> ? <Requirements> <Requirement name=“…”? ref="...REF"/> + </Requirements> ? <Capabilities> <Capability name=“…” ref="...REF"/> + </Capabilities> ? <Policies> ... </Policies> ? <Interfaces> <Interface name=“…"> <Operation name="xs:NCName"> ... </Operation> + </Interface> + </Interfaces> ? </BoundaryDefinitions> ? <TopologyTemplate> ( <NodeTemplate id=“…" name=“…”? type=“…“ minInstances=""? maxInstances=“…"?> <Properties> XML fragment </Properties> ? <PropertyConstraints> … </PropertyConstraints> ? <Requirements> <Requirement id="..." name="..." type="..."> + <Properties> XML fragment <Properties> ? <PropertyConstraints> … </PropertyConstraints> ? </Requirement> </Requirements> ? <Capabilities> <Capability id="..." name="..." type="..."> + <Properties> XML fragment <Properties> ? <PropertyConstraints> ... </PropertyConstraints> ? </Capability> </Capabilities> ? <DeploymentArtifacts> <DeploymentArtifact name=“…" artifactType=“…“ artifactRef=“…"?> artifact specific content ? </DeploymentArtifact> + </DeploymentArtifacts> ? </NodeTemplate> | <RelationshipTemplate id=“…" name=“…"? type=“…"> … </RelationshipTemplate> ) + </TopologyTemplate> </ServiceTemplate>
TOSCA Service Template schema
<BoundaryDefinitions> <Properties> XML fragment <PropertyMappings> <PropertyMapping serviceTemplatePropertyRef="...“ targetObjectRef="...REF“ targetPropertyRef="..."/> + </PropertyMappings/> ? </Properties> ? <PropertyConstraints> <PropertyConstraint property="...“ constraintType="xs:anyURI"> + constraint ? </PropertyConstraint> </PropertyConstraints> ?
<Requirements> <Requirement name="..."? ref="...REF"/> + </Requirements> ?
<Capabilities> <Capability name="..."? ref="...REF"/> + </Capabilities> ?
<Policies> <Policy name="..."? policyType="...“ policyRef="..."?> policy specific content ? </Policy> + </Policies> ?
<Interfaces> <Interface name="xs:NCName"> <Operation name="xs:NCName"> ( <NodeOperation nodeRef="...REF“ interfaceName="xs:anyURI“ operationName="xs:NCName"/> | <RelationshipOperation relationshipRef="...REF“ interfaceName="xs:anyURI“ operationName="xs:NCName"/> | <Plan planRef="...REF"/> ) </Operation> + </Interface> + </Interfaces> ? </BoundaryDefinitions> ?
TOSCA Boundary Definitions Schema
<NodeType name="xs:NCName" targetNamespace="xs:anyURI"? abstract="yes|no"? final="yes|no"?> <Tags> <Tag name="..." value="..."/> + </Tags> ? <DerivedFrom typeRef="..."/> ? <PropertiesDefinition element="..."? type="..."?/> ? <RequirementDefinitions> <RequirementDefinition name="..." requirementType="..." lowerBound="xs:integer"? upperBound="xs:integer | ..."?> <Constraints> <Constraint constraintType="xs:anyURI"> constraint type specific content </Constraint> + </Constraints> ? </RequirementDefinition> + </RequirementDefinitions> ? <CapabilityDefinitions> <CapabilityDefinition name="..." capabilityType="..." lowerBound="xs:integer"? upperBound="xs:integer | ..."?> <Constraints> <Constraint constraintType="xs:anyURI"> constraint type specific content </Constraint> + </Constraints> ? </CapabilityDefinition> + </CapabilityDefinitions> <InstanceStates> <InstanceState state="xs:anyURI"> + </InstanceStates> ?
<Interfaces> <Interface name="xs:NCName | xs:anyURI"> <Operation name="xs:NCName"> <InputParameters> <InputParameter name="..." type="..." required="yes|no"?/> + </InputParameters> ? <OutputParameters> <OutputParameter name="..." type="..." required="yes|no"?/> + </OutputParameters> ? </Operation> + </Interface> + </Interfaces> ? </NodeType>
NodeType XML schema
<RelationshipType name="xs:NCName" targetNamespace="xs:anyURI"? abstract="yes|no"? final="yes|no"?> + <Tags> <Tag name="..." value="..."/> + </Tags> ? <DerivedFrom typeRef="..."/> ? <PropertiesDefinition element="..."? type="..."?/> ? <InstanceStates> <InstanceState state="xs:anyURI"> + </InstanceStates> ? <SourceInterfaces> <Interface name="xs:NCName | xs:anyURI"> ... </Interface> + </SourceInterfaces> ? <TargetInterfaces> <Interface name="xs:NCName | xs:anyURI"> ... </Interface> + </TargetInterfaces> ? <ValidSource typeRef="..."/> ? <ValidTarget typeRef="..."/> ?
<AbstractOperations> <Operation/> + </AbstractOperations> </RelationshipType>
RelationshipType
WebTier Service Template
DBTier Service Template
WebTier
ScalableTier
ApacheVM
Server
Apache
WebServer
SugarCRMApp
WebApplication
DBTier
Tier
MySqlVM
Server
MySQL
DBMS
SugarCRMDatabase
Database
ApacheLinuxOS
Operating System
MySqlLinuxOS
OperatingSystem
Advanced Scenarios: “Scalable SugarCRM Web Application”
ApacheLB
LoadBalancer“Tier” Node Types convey scalability
The “Web Application Tier” is declared Scalable with upper bounds “n” instances
Note: the “Database Tier” remains a single instance
A Load Balancer node is added to the previous template to route requests among “Web Application Tier” instances
Both tiers are packaged into their own service templates permitting Substitution
1..n 1
The range of instances would be a property of the “Tier” Node Type
Components grouped into composable service templates.
Scalability