diff --git a/doc/hot-guide/source/hot_spec.rst b/doc/hot-guide/source/hot_spec.rst index de4d8618ce..708538c4e3 100644 --- a/doc/hot-guide/source/hot_spec.rst +++ b/doc/hot-guide/source/hot_spec.rst @@ -767,7 +767,7 @@ of the ``get_resource`` function is: The resource ID of the referenced resource is given as single parameter to the get_resource function. -For exemple: +For example: .. code-block:: yaml diff --git a/doc/user-guide/hot/section_basic_resources.xml b/doc/user-guide/hot/section_basic_resources.xml index 28b20d6c59..36b6351252 100644 --- a/doc/user-guide/hot/section_basic_resources.xml +++ b/doc/user-guide/hot/section_basic_resources.xml @@ -164,6 +164,34 @@ deployment to use these resources. Use the OS::Neutron::FloatingIP resource to create a floating IP, and the OS::Neutron::FloatingIPAssociation resource to associate the floating IP to a port: + parameters: + net: + description: name of network used to launch instance. + type: string + default: private + +resources: + inst1: + type: OS::Nova::Server + properties: + flavor: m1.small + image: ubuntu-trusty-x86_64 + networks: + - network: {get_param: net} + + floating_ip: + type: OS::Neutron::FloatingIP + properties: + floating_network: public + + association: + type: OS::Neutron::FloatingIPAssociation + properties: + floatingip_id: { get_resource: floating_ip } + port_id: {get_attr: [inst1, addresses, {get_param: net}, 0, port]} + You can also create an OS::Neutron::Port and associate that with the server and +the floating IP. However the approach mentioned above will work better +with stack updates. resources: instance_port: type: OS::Neutron::Port @@ -176,7 +204,6 @@ floating IP to a port: type: OS::Neutron::FloatingIP properties: floating_network: public - port_id: { get_resource: instance_port } association: type: OS::Neutron::FloatingIPAssociation diff --git a/doc/user-guide/hot/section_composition.xml b/doc/user-guide/hot/section_composition.xml index 0c275bdda2..6c970e43ec 100644 --- a/doc/user-guide/hot/section_composition.xml +++ b/doc/user-guide/hot/section_composition.xml @@ -34,7 +34,7 @@ properties. The following examples illustrate how you can use a custom template to define new types of resources. These examples use a custom template stored in a my_nova.yml file: - heat_template_version: 2013-05-23 + heat_template_version: 2014-10-16 parameters: key_name: @@ -53,7 +53,8 @@ resources: Use the template filename as type The following template defines the my_nova.yaml file as value for the type property of a resource: - heat_template_version: 2013-05-23 + heat_template_version: 2014-10-16 + resources: my_server: type: my_nova.yaml @@ -85,7 +86,7 @@ You can use any of the following forms:
Define a new resource type - You can associate a name to the my_noya.yaml template in an environment + You can associate a name to the my_nova.yaml template in an environment file. If the name is already known by the Orchestration module then your new resource will override the default one. In the following example a new OS::Nova::Server resource overrides the @@ -97,7 +98,9 @@ default resource of the same name. See for more detail about environment files. You can now use the new OS::Nova::Server in your new template: - resources: + heat_template_version: 2014-10-16 + +resources: my_server: type: OS::Nova::Server properties: @@ -105,4 +108,37 @@ default resource of the same name. To create the stack run: $ heat stack-create -f main.yaml -e env.yaml example-two
+
+ + Get access to nested attributes + There are implicit attributes of a template resource. These are +accessible as follows: + heat_template_version: 2014-10-16 + +resources: + my_server: + type: my_nova.yaml + +outputs: + test_out: + value: {get_attr: my_server, resource.server, first_address} +
+
+ + Making your template resource more "transparent" + If you wish to be able to return the ID of one of the inner resources +instead of the nested stack's identifier, you can add the special reserved +output "OS::stack_id" to your template resource. + heat_template_version: 2014-10-16 + +resources: + server: + type: OS::Nova::Server + +outputs: + OS::stack_id: + value: {get_resource: server} + Now when you use "get_resource" from the outer template heat +will use the nova server id and not the template resource identifier. +
diff --git a/doc/user-guide/hot/section_hello_world.xml b/doc/user-guide/hot/section_hello_world.xml index 71477ecb19..14859adc0e 100644 --- a/doc/user-guide/hot/section_hello_world.xml +++ b/doc/user-guide/hot/section_hello_world.xml @@ -113,7 +113,7 @@ following example defines a default value m1.small for the must define the value, otherwise the stack creation will fail. -
+
Hiding parameters values The values that a user provides when deploying a stack are available in the stack details and can be accessed by any user in the same tenant. To hide the diff --git a/doc/user-guide/hot/section_hot_spec.xml b/doc/user-guide/hot/section_hot_spec.xml index 4eb456ca5e..a09d77ec1a 100644 --- a/doc/user-guide/hot/section_hot_spec.xml +++ b/doc/user-guide/hot/section_hot_spec.xml @@ -203,7 +203,7 @@ if the parameter value doesn't comply to the constraints. - The following example shows a minimalist definition of two parameters: + The following example shows a minimalistic definition of two parameters: parameters: user_name: type: string diff --git a/doc/user-guide/hot/section_software_deployment.xml b/doc/user-guide/hot/section_software_deployment.xml index f7969c9561..c940d3a762 100644 --- a/doc/user-guide/hot/section_software_deployment.xml +++ b/doc/user-guide/hot/section_software_deployment.xml @@ -237,7 +237,7 @@ which builds a curl command with a valid token: # If you require control of the ID, you can pass it. # The ID should be unique, unless you intend for duplicate - # signals to overrite each other. The following two calls + # signals to overwrite each other. The following two calls # do the exact same thing, and will be treated as one signal # (You can prove this by changing count above to 7) wc_notify --data-binary '{"status": "SUCCESS", "id": "5"}'