members: [ apache, server ] policies: - my_scaling_policy: # Specific policy definitions are considered domain specific and # are not included here The example first of all uses the concept of grouping to express which components (node templates) need to be scaled as a unit – i.e. the compute nodes and the software on-top of each compute node. This is done by defining the webserver_group in the groups section of the template and by adding both the apache node template and the server node template as a member to the group. Furthermore, a scaling policy is defined for the group to express that the group as a whole (i.e. pairs of server node and the apache component installed on top) should scale up or down under certain conditions. In where no explicit binding between software components and their hosting compute resources is defined in a template, but only requirements are defined as has been shown in section 11, a provider could decide to place software components on the same host if their hosting requirements match, or to place them onto different hosts. It is often desired, though, to influence placement at deployment time to make sure components get collocation or anti-collocated. This can be expressed via grouping and policies as shown in the example below. tosca_definitions_version: tosca_simple_yaml_1_0_0 description: Template hosting requirements and placement policy. inputs: # omitted here for sake of brevity node_templates: wordpress: type: properties: # omitted here for sake of brevity requirements: - host: tosca.nodes.Compute constraints: mem_size: { greater_or_equal: 2 } os_arch: x86_64 os_type: type:
get_input The get_input function is used to retrieve the values of properties declared within the inputs section of ervice emplate. Parameters Parameter Required Type Description <property_name> yes string The name of the property as defined in the inputs section of the service template. Examples inputs: cpus: type: integer node_templates: my_server: type: properties: num_cpus: { get_input: cpus } get_property The get_property function is used to retrieve property values between entities defined in the same service template. get_property: <_name>, <req_name>, <property_name> Parameters Parameter Required Type Description yes
as part of the schema declaration. WD02 WD02 - Decide how security/access control work with Nodes, update grammar, author descriptive text/examples WD02 WD02 - How do we provide constraints on properties declared as simple YAML lists (sets) WD02 WD02 - Are there IPv6 considerations (e.g., new properties) for tosca.capabilities.Endpoint WD02 WD02 - Can/how do we make a property defn. "final" or "read-only" WD02 WD02 - Provide prose describing how Feature matching is done by orchestrators Dependency on TOSCA-137, Future item, W03 or beyond. WD02 WD02 - Describe how not all interfaces need to supply scripts (artifacts), it is a no-op behavior WD02 WD02 - Need examples of using the "tosca.interfaces.relationship.Configure" interface WD02 WD02 - Need examples of using the built-in feature (Capability) and dependency (Requirement) of tosca.nodes.Root WD02 WD02 - Provide recognized values for tosca.nodes.compute properties: os_arch Could be WD03 item WD02 WD02 - Provide recognized values for store_fs_type Could be WD03 item WD02 WD02 - Do we need a restart lifecycle operation for WD02 WD02 - New use case / example: Selection/Replacement of web server type (e.g. Apache, NGinx, Lighttpd, etc.) Could be WD03 item WD02 WD02 - New use case / example: Web Server with (one or more) runtimes environments (e.g., PHP, Java, etc.) be WD03 item WD03 WD02 - New use case / example: Show abstract substitution of Compute node OS with different Node Type Impls. be WD03 item WD03 WD02 - New use case / example: Show how substitution of IaaS can be accomplished. be WD03 item
References Terminology The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [TOSCA-1.0]. Normative References [TOSCA-1.0] Topology and Orchestration Topology and Orchestration Specification for Cloud Applications (TOSCA) Version 1.0, an OASIS Standard, 25 November 2013, [YAML-1.2] YAML, Version 1.2, 3rd Edition, Patched at 2009-10-01, Oren Ben-Kiki, Clark Evans, Ingy döt Net [YAML-TS-1.1] Timestamp Language-Independent Type for YAML Version 1.1, Working Non-Normative References [AWS-CFN] Amazon Cloud Formation (CFN), [Chef] Chef, [OS-Heat] OpenStack Project Heat, [Puppet] Puppet, [WordPress] WordPress,