Presentation on theme: "TOSCA Normative Types Proposal Internal Working Draft v0.3 Submitter: Matt Rutkowski."— Presentation transcript:
TOSCA Normative Types Proposal Internal Working Draft v0.3 Submitter: Matt Rutkowski
2 + ? ? ? constraint type specific content + ? + ? constraint type specific content + ? + + ? + ? + ? + ? NodeType
: RootNodeType – Part 1 Properties nametypePrescription default description CompName (component name) stringoptionalComponent or service common name (e.g. “MySQL”); this is different than the Node’s “name” attribute or its “ID”. It is a property that can be matched via a requirement CompVersionstringoptionalComponent or service’s version Definition The fundamental type that all TOSCA NodeTypes derive from. InstanceStates statedescription creatingBeing created. (delete.) startingBeing started. (start, restart, stop, and delete) startedAvailable and ready for use. (stop, restart, pause, suspend, capture, restore, and delete) stoppingBeing stopped. (start, restart, stop, and delete) stoppedPowered off; no saved CPU or memory state. Allowable actions : start, restart, capture, restore, and delete. pausingBeing paused. Allowable actions : start, restart, and delete. pausedResources remain instantiated ; processing stopped; not enabled for tasks. Allowable actions: start, restart, backup, restore, delete. (sleep) suspendingMachine being suspended. Allowable actions when in this state are: start, restart, and delete. suspendedmachine and its virtual resources are stored on non-volatile storage. (hibernate) deletingCIMI Machine, CIMI Volume, CIMI Network errorCIMI Machine, CIMI Volume, CIMI Network capturingCIMI Volume (snapshot), could apply to VMs? availableCIMI Volume (perhaps use started instead?) Interfaces namedescription create (install)TBD configure- start- stop- delete (uninstall)TBD suspendCIMI, OpenStack pauseCIMI, OpenStack captureCIMI restoreCIMI Note: If lifecycle operations are sequential (i.e. rely upon script completion) then perhaps allowing operations for “transitional” states do not make sense.
RootNodeType: 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. Requirements namerequirementTypelowerboundupperboundconstraints N/A---- Capabilities namecapabilityTypelowerboundupperboundconstraints nodesServerContainerCapability0unboundedTBD – It seems that “tiers” should capable of containing any type of nodes not just servers. InstanceStates statedescription N/A- Interfaces nameparmsdescription N/A-- Properties nametypePrescription default description minInstancesintegerRequired1Minimum number of instances for scaling tier (range 1 - N). maxInstancesintegerRequired1Maximum number of instances for scaling tier (range 1 - N).
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 nameparmsdescription N/A Requirements namerequirementTypelowerboundupperbounddescription containerServerContainerRequirement01Optional. Capabilities namecapabilityTypelowerboundupperbounddescription osOperatingSystemContainerCapability01Optional Runtime Capability VMCapability Properties (ServerProperties) nametypePrescription default descriptionrestriction NumCpusintegerRequired1Number 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 MemoryintegerRequiredN/A?Memory (in MB): Amount of memory (for the virtual machine) - DiskintegerRequiredDisk (in GB): Amount of disk space for the virtual machine- OSstringOptionalOpeerating System name (e.g. “Ubuntu”). Note: Still an option to to model OS independently. OSVersionstringOptionalOperationg System version (e.g. “12.04)”. Still an option al to model OS independently.
RootNodeType : OperatingSystem (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 Requirements namerequirementTypelowerboundupperboundconstraints containerOperatingSystemContainerRequirement11 Capabilities namecapabilityTypelowerboundupperboundconstraints softwareSoftwareContainerCapability0unbounded InstanceStates statedescription N/A- Interfaces nameparmsdescription N/A Properties nametypePrescription default description N/A
Application Runtime Types
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 namerequirementTypelowerboundupperboundconstraints containerSoftwareContainerRequirement11 Capabilities namecapabilityTypelowerboundupperboundconstraints webappsWebApplicationContainerCapability0unbounded InstanceStates statedescription N/A- Interfaces nameparmsdescription N/A Properties nametypePrescription default description N/A
RootNodeType : WebApplication Definition TBD – “Web” is unecessary, any “Application” with exported endpoints is valid, perhaps just use “Application” Requirements namerequirementTypelowerboundupperboundconstraints containerSoftwareContainerRequirement11 Capabilities namecapabilityTypelowerboundupperboundconstraints N/A InstanceStates statedescription N/A- Interfaces nameparmsdescription N/A Properties nametypePrescription default description N/A
: RootRelationshipType Abstract Interfaces nameparmsdescription preConfigureOptionalTBDNodes on either end of any relationship should support a “pre- configuration” operation (e.g. “preConnect”) configureOptionalTBDNodes on either end of any relationship should support a “configuration” operation (e.g. “connect”) postConfigureOptionalTBDNodes on either end of any relationship should support a “post- configuration” operation. (e.g. “postConnect”) Properties nametypePrescription default description Definition The fundamental type that all TOSCA RelationshipTypes derive from. InstanceStates statedescription N/A-
RootRelationshipType : HostedOn ValidSource typeRefdescription ContainerRequirementRootRequirementType ValidTarget namedescription ContainerCapabilityRootCapabilityType Interfaces nameparmsdescription TBD Properties nametypePrescription 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 statedescription N/A-
RootRelationshipType : ConnectsTo ValidSource typeRefdescription EndpointRequirementRootRequirementType ValidTarget namedescription EndpointCapabilityRootCapabilityType Interfaces nameparmsdescription TBD Properties nametypePrescription 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, HTTPEndpointCapability Can we not flatten??? Using properties such as “protocol” (or protocol list?) InstanceStates statedescription N/A-
RootRelationshipType : DependsOn ValidSource typeRefdescription FeatureRequirementRootRequirementType ValidTarget namedescription FeatureCapabilityRootCapabilityType Interfaces nameparmsdescription TBD Properties nametypePrescription 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 statedescription N/A-
28 WebTier Service Template WebTier Service Template DBTier Service Template DBTier Service Template WebTier ScalableTier WebTier ScalableTier ApacheVM Server ApacheVM Server Apache WebServer Apache WebServer SugarCRMApp Web Application SugarCRMApp Web Application DBTier Tier DBTier Tier MySqlVM Server MySqlVM Server MySQL DBMS MySQL DBMS SugarCRM Database SugarCRM Database ApacheLinuxOS Operating System ApacheLinuxOS Operating System MySqlLinuxOS Operating System MySqlLinuxOS Operating System Advanced Scenarios: “Scalable SugarCRM Web Application” ApacheLB LoadBalancer 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 1 The range of instances would be a property of the “Tier” Node Type Components grouped into composable service templates. Scalability