TOSCA Normative Types Proposal Internal Working Draft v
- Slides: 29
TOSCA Normative Types Proposal Internal Working Draft v 0. 3 Submitter: Matt Rutkowski
Node. Type <Node. Type name="xs: NCName" target. Namespace="xs: any. URI"? abstract="yes|no"? final="yes|no"? > <Tags> <Tag name="xs: string" value="xs: string"/> + </Tags> ? <Derived. From type. Ref="xs: QName"/> ? <Properties. Definition element="xs: QName"? type="xs: QName"? /> ? <Requirement. Definitions> <Requirement. Definition name="xs: string" requirement. Type="xs: QName" lower. Bound="xs: integer"? upper. Bound="xs: integer | xs: string"? > <Constraints> <Constraint constraint. Type="xs: any. URI"> constraint type specific content </Constraint> + </Constraints> ? </Requirement. Definition> + </Requirement. Definitions> ? <Capability. Definitions> <Capability. Definition name="xs: string" capability. Type="xs: QName" lower. Bound="xs: integer"? upper. Bound="xs: integer | xs: string"? > <Constraints> <Constraint constraint. Type="xs: any. URI"> constraint type specific content </Constraint> + </Constraints> ? </Capability. Definition> + </Capability. Definitions> <Instance. State state="xs: any. URI"> + </Instance. States> ? <Interfaces> <Interface name="xs: NCName | xs: any. URI"> <Operation name="xs: NCName"> <Input. Parameters> <Input. Parameter name="xs: string" type="xs: string" required="yes|no"? /> + </Input. Parameters> ? <Output. Parameters> <Output. Parameter name="xs: string" type="xs: string" required="yes|no"? /> + </Output. Parameters> ? </Operation> + </Interfaces> ? </Node. Type>
<none>: Root. Node. Type – Part 1 Definition The fundamental type that all TOSCA Node. Types derive from. Instance. States Interfaces name description state description create (install) TBD creating Being created. (delete. ) configure - starting Being started. (start, restart, stop, and delete) start - started Available and ready for use. (stop, restart, pause, suspend, capture, restore, and delete) stop - stopping Being stopped. (start, restart, stop, and delete) delete (uninstall) TBD stopped Powered off; no saved CPU or memory state. Allowable actions : start, restart, capture, restore, and delete. suspend CIMI, Open. Stack pausing Being paused. Allowable actions : start, restart, and delete. pause CIMI, Open. Stack paused capture CIMI Resources remain instantiated ; processing stopped; not enabled for tasks. Allowable actions: start, restart, backup, restore, delete. (sleep) restore CIMI 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) deleting CIMI Machine, CIMI Volume, CIMI Network error CIMI Machine, CIMI Volume, CIMI Network capturing CIMI Volume (snapshot), could apply to VMs? available CIMI Volume (perhaps use started instead? ) Note: If lifecycle operations are sequential (i. e. rely upon script completion) then perhaps allowing operations for “transitional” states do not make sense. Properties default name type Prescription description Comp. Name (component name) string optional Component or service common name (e. g. “My. SQL”); this is different than the Node’s “name” attribute or its “ID”. It is a property that can be matched via a requirement Comp. Version string optional Component or service’s version
<none>: Root. Node. Type – Part 2 Requirements name requirement. Type lowerbound upperbound constraints N/A - - name capability. Type lowerbound upperbound constraints N/A - - - Capabilities
Root. Node. Type: Tier 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. Interfaces Instance. States name parms description state description N/A - - N/A - Properties name type Prescription default description min. Instances integer Required 1 Minimum number of instances for scaling tier (range 1 - N). max. Instances integer Required 1 Maximum number of instances for scaling tier (range 1 - N). Requirements name requirement. Type lowerbound upperbound constraints N/A - - name capability. Type lowerbound upperbound constraints nodes Server. Container. Capability 0 unbounded TBD – It seems that “tiers” should capable of containing any type of nodes not just servers. Capabilities
Compute Types
Root. Node. Type : 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 Properties (Server. Properties) name type Prescription default description restriction Num. Cpus 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 1, 2, 4 Memory integer Required N/A? Memory (in MB): Amount of memory (for the virtual machine) - Disk integer Required Disk (in GB): Amount of disk space for the virtual machine - OS string Optional Opeerating System name (e. g. “Ubuntu”). Note: Still an option to to model OS independently. OSVersion string Optional Operationg System version (e. g. “ 12. 04)”. Still an option al to model OS independently. Requirements name requirement. Type lowerbound upperbound description container Server. Container. Requirement 0 1 Optional. name capability. Type lowerbound upperbound description os Operating. System. Container. Capability 0 1 Optional <or> Runtime Capability <or> VMCapability Capabilities
Root. Node. Type : Operating. System (Optionally merge as a property of VM) 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 Interfaces name Instance. States parms description N/A state description N/A - Properties name type Prescription default description N/A Requirements name requirement. Type lowerbound upperbound container Operating. System. Container. Requirement 1 1 name capability. Type lowerbound upperbound software Software. Container. Capability 0 unbounded constraints Capabilities constraints
Application Runtime Types
Root. Node. Type : Web. Server Definition TBD – Ideally, would like to move towards an “Application Runtime” (indicates additive APIs / language to the OS) since that is its primary purpose. Interfaces name Instance. States parms description N/A state description N/A - Properties name type Prescription default description N/A Requirements name requirement. Type lowerbound upperbound container Software. Container. Requirement 1 1 name capability. Type lowerbound upperbound webapps Web. Application. Container. Capability 0 unbounded constraints Capabilities constraints
Root. Node. Type : Web. Application Definition TBD – “Web” is unecessary, any “Application” with exported endpoints is valid, perhaps just use “Application” Interfaces name Instance. States parms description N/A state description N/A - Properties name type Prescription default description N/A Requirements name requirement. Type lowerbound upperbound container Software. Container. Requirement 1 1 capability. Type lowerbound upperbound constraints Capabilities name N/A constraints
Database Types
Root. Node. Type : DBMS Definition TBD Interfaces name Instance. States parms description N/A state description N/A - Properties name type Prescription default description N/A Requirements name requirement. Type lowerbound upperbound container Software. Container. Requirement 1 1 name capability. Type lowerbound upperbound databases Database. Container. Capability 0 unbounded constraints Capabilities constraints
Root. Node. Type : Database Definition TBD Interfaces name Instance. States parms description N/A state 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? Requirements name requirement. Type lowerbound upperbound container Database. Container. Requirement 1 1 name capability. Type lowerbound upperbound clients Database. Endpoint. Capability (Connection. Target? ) 0 unbounded constraints Capabilities constraints
Storage Types
Root. Node. Type : Storage Definition TBD Interfaces name Instance. States parms description N/A state description N/A - Properties name type Prescription default description TBD Requirements name requirement. Type lowerbound upperbound constraints capability. Type lowerbound upperbound constraints TBD Capabilities name TBD
Network Types
Root. Node. Type : Network Definition TBD Interfaces name Instance. States parms description N/A state description N/A - Properties name type logical. Name string Prescription default description Logical network name Requirements name requirement. Type lowerbound upperbound constraints capability. Type lowerbound upperbound constraints TBD Capabilities name TBD
Composite Node Types (Need mechanism for compositing)
Root. Node. Type : Application. Runtime (Composite Runtime Environment) Definition Implies a Web. Server + one or more Langauge. Runtimes (e. g. PHP, Java, etc. )? Interfaces name Instance. States parms Runtimes description state description Dictionary of language runtimes/versions? (e. g. “Java” “ 6. 0”, “Python” “ 2. 6”, etc. ) N/A - TBD Properties name type Prescription default description TBD Requirements name requirement. Type lowerbound upperbound constraints capability. Type lowerbound upperbound constraints Capabilities name
Relationship. Types
Relationship. Type <Relationship. Type name="xs: NCName" target. Namespace="xs: any. URI"? abstract="yes|no"? final="yes|no"? > + <Tags> <Tag name="xs: string" value="xs: string"/> + </Tags> ? <Derived. From type. Ref="xs: QName"/> ? <Properties. Definition element="xs: QName"? type="xs: QName"? /> ? <Instance. States> <Instance. State state="xs: any. URI"> + </Instance. States> ? <Source. Interfaces> <Interface name="xs: NCName | xs: any. URI">. . . </Interface> + </Source. Interfaces> ? <Target. Interfaces> <Interface name="xs: NCName | xs: any. URI">. . . </Interface> + </Target. Interfaces> ? <Valid. Source type. Ref="xs: QName"/> ? <Valid. Target type. Ref="xs: QName"/> ? <Abstract. Operations> <Operation/> + </Abstract. Operations> </Relationship. Type>
<none>: Root. Relationship. Type Definition The fundamental type that all TOSCA Relationship. Types derive from. Abstract Interfaces name parms description pre. Configure Optional TBD Nodes on either end of any relationship should support a “preconfiguration” operation (e. g. “pre. Connect”) configure Optional TBD Nodes on either end of any relationship should support a “configuration” operation (e. g. “connect”) post. Configure Optional TBD Nodes on either end of any relationship should support a “postconfiguration” operation. (e. g. “post. Connect”) Properties name type Instance. States state description N/A - Prescription default description
Root. Relationship. Type : Hosted. On Definition Relationship that indicates a node can “host” or contain another node of a specified type. For example: • a Database node is “hosted. On” a DBMS (Database Management System) node • a Web. Server node is “hosted. On” a n Operating. System node. Interfaces name parms description TBD Properties name type Prescription TBD Valid. Source type. Ref description Container. Requirement Root. Requirement. Type Valid. Target name description Container. Capability Root. Capability. Type Instance. States state description N/A - default description
Root. Relationship. Type : Connects. To Definition Relationship that indicates a node can “connect” to another node of a specified type. For example: • A Web. Application node “connects. To” a Database node. Known Subclasses IPEndpoint. Requreiment, HTTPEndpoint. Requirement, IPEndpoint. Capability, HTTPEndpoint. Capability Can we not flatten? ? ? Using properties such as “protocol” (or protocol list? ) Interfaces name parms description TBD Properties name type Prescription TBD Valid. Source type. Ref description Endpoint. Requirement Root. Requirement. Type Valid. Target name description Endpoint. Capability Root. Capability. Type Instance. States state description N/A - default description
Root. Relationship. Type : Depends. On Definition Relationship that indicates a node is “dependent” on another node of a specified type. For example: • A PHP runtime “depends. On”an Apache web server Interfaces name parms description TBD Properties name type Prescription TBD Valid. Source type. Ref description Feature. Requirement Root. Requirement. Type Valid. Target name description Feature. Capability Root. Capability. Type Instance. States state description N/A - default description
Backup Charts
Advanced Scenarios: “Scalable Sugar. CRM Web Application” Scalability “Tier” Node Types convey scalability DBTier Service Template Web. Tier Service Template Apache. LB Load. Balancer Sugar. CRMApp Sugar. CRM Database Web Application The “Web Application Tier” is declared Scalable with upper bounds “n” instances § Note: the “Database Tier” Database Apache My. SQL Web. Server DBMS 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 The range of instances would be a property of the “Tier” Node Type Apache. Linux. OS My. Sql. Linux. OS Operating System Apache. VM My. Sql. VM Server 1 1. . n Web. Tier DBTier Scalable. Tier Components grouped into composable service templates. 28
Base Node – Viewed as “layers”
- Relation between actual draft and mechanical draft
- Components of research proposal
- Example of justification in research
- Hyaluronase
- Draft for internal use only
- Smart vs hard working
- Hot principle
- Hot working and cold working difference
- Machining operations
- Pembentukan logam
- Democratic participant media theory
- "proposal mean" "research proposal"
- Internal audit working paper
- Why use headings for an external solicited proposal?
- Tosca studie
- Tosca workflow
- Database applications
- Tosca cloud orchestration
- Loops in tosca
- Tosca müller fu berlin
- Tosca workflow
- Tosca résumé
- Extension developer in tosca
- Tosca
- Natalie enright jerger
- Tosca demo
- Ibm cloud orchestrator
- Tosca cloud orchestration
- Tosca orchestration
- Oasis tosca