Update the user guide with the HOT content

This is mostly an automated build, with a typo correction.

Change-Id: I403639f8abccd56703372e8908c6f7bb43457d8e
This commit is contained in:
Gauvain Pocentek
2015-02-16 21:01:06 +01:00
parent 385ff7e5d9
commit 3c13731ed4
6 changed files with 72 additions and 9 deletions

View File

@@ -767,7 +767,7 @@ of the ``get_resource`` function is:
The resource ID of the referenced resource is given as single parameter to the The resource ID of the referenced resource is given as single parameter to the
get_resource function. get_resource function.
For exemple: For example:
.. code-block:: yaml .. code-block:: yaml

View File

@@ -164,6 +164,34 @@ deployment to use these resources.</para>
<para>Use the <literal><link xlink:href="http://docs.openstack.org/hot-reference/content/OS__Neutron__FloatingIP.html">OS::Neutron::FloatingIP</link></literal> resource to create a floating IP, and <para>Use the <literal><link xlink:href="http://docs.openstack.org/hot-reference/content/OS__Neutron__FloatingIP.html">OS::Neutron::FloatingIP</link></literal> resource to create a floating IP, and
the <literal><link xlink:href="http://docs.openstack.org/hot-reference/content/OS__Neutron__FloatingIPAssociation.html">OS::Neutron::FloatingIPAssociation</link></literal> resource to associate the the <literal><link xlink:href="http://docs.openstack.org/hot-reference/content/OS__Neutron__FloatingIPAssociation.html">OS::Neutron::FloatingIPAssociation</link></literal> resource to associate the
floating IP to a port:</para> floating IP to a port:</para>
<programlisting language="yaml">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]}</programlisting>
<para>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.</para>
<programlisting language="yaml">resources: <programlisting language="yaml">resources:
instance_port: instance_port:
type: OS::Neutron::Port type: OS::Neutron::Port
@@ -176,7 +204,6 @@ floating IP to a port:</para>
type: OS::Neutron::FloatingIP type: OS::Neutron::FloatingIP
properties: properties:
floating_network: public floating_network: public
port_id: { get_resource: instance_port }
association: association:
type: OS::Neutron::FloatingIPAssociation type: OS::Neutron::FloatingIPAssociation

View File

@@ -34,7 +34,7 @@ properties.</para>
<para>The following examples illustrate how you can use a custom template to define <para>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 new types of resources. These examples use a custom template stored in a
<literal>my_nova.yml</literal> file:</para> <literal>my_nova.yml</literal> file:</para>
<programlisting language="yaml">heat_template_version: 2013-05-23 <programlisting language="yaml">heat_template_version: 2014-10-16
parameters: parameters:
key_name: key_name:
@@ -53,7 +53,8 @@ resources:
<title>Use the template filename as type</title> <title>Use the template filename as type</title>
<para>The following template defines the <literal>my_nova.yaml</literal> file as value for the <para>The following template defines the <literal>my_nova.yaml</literal> file as value for the
<literal>type</literal> property of a resource:</para> <literal>type</literal> property of a resource:</para>
<programlisting language="yaml">heat_template_version: 2013-05-23 <programlisting language="yaml">heat_template_version: 2014-10-16
resources: resources:
my_server: my_server:
type: my_nova.yaml type: my_nova.yaml
@@ -85,7 +86,7 @@ You can use any of the following forms:</para>
<section xml:id="define-a-new-resource-type"> <section xml:id="define-a-new-resource-type">
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>Define a new resource type</title> <title>Define a new resource type</title>
<para>You can associate a name to the <literal>my_noya.yaml</literal> template in an environment <para>You can associate a name to the <literal>my_nova.yaml</literal> template in an environment
file. If the name is already known by the Orchestration module then your new file. If the name is already known by the Orchestration module then your new
resource will override the default one.</para> resource will override the default one.</para>
<para>In the following example a new <literal>OS::Nova::Server</literal> resource overrides the <para>In the following example a new <literal>OS::Nova::Server</literal> resource overrides the
@@ -97,7 +98,9 @@ default resource of the same name.</para>
<para>See <xref linkend="environments"/> for more detail about environment files.</para> <para>See <xref linkend="environments"/> for more detail about environment files.</para>
</note> </note>
<para>You can now use the new <literal>OS::Nova::Server</literal> in your new template:</para> <para>You can now use the new <literal>OS::Nova::Server</literal> in your new template:</para>
<programlisting language="yaml">resources: <programlisting language="yaml">heat_template_version: 2014-10-16
resources:
my_server: my_server:
type: OS::Nova::Server type: OS::Nova::Server
properties: properties:
@@ -105,4 +108,37 @@ default resource of the same name.</para>
<para>To create the stack run:</para> <para>To create the stack run:</para>
<programlisting language="console">$ heat stack-create -f main.yaml -e env.yaml example-two</programlisting> <programlisting language="console">$ heat stack-create -f main.yaml -e env.yaml example-two</programlisting>
</section> </section>
<section xml:id="get-access-to-nested-attributes">
<?dbhtml stop-chunking?>
<title>Get access to nested attributes</title>
<para>There are implicit attributes of a template resource. These are
accessible as follows:</para>
<programlisting language="yaml">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}</programlisting>
</section>
<section xml:id="making-your-template-resource-more-transparent">
<?dbhtml stop-chunking?>
<title>Making your template resource more "transparent"</title>
<para>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.</para>
<programlisting language="yaml">heat_template_version: 2014-10-16
resources:
server:
type: OS::Nova::Server
outputs:
OS::stack_id:
value: {get_resource: server}</programlisting>
<para>Now when you use "get_resource" from the outer template heat
will use the nova server id and not the template resource identifier.</para>
</section>
</section> </section>

View File

@@ -113,7 +113,7 @@ following example defines a default value <literal>m1.small</literal> for the
must define the value, otherwise the stack creation will fail.</para> must define the value, otherwise the stack creation will fail.</para>
</note> </note>
</section> </section>
<section xml:id="hidding-parameters-values"> <section xml:id="hiding-parameters-values">
<title>Hiding parameters values</title> <title>Hiding parameters values</title>
<para>The values that a user provides when deploying a stack are available in the <para>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 stack details and can be accessed by any user in the same tenant. To hide the

View File

@@ -203,7 +203,7 @@ if the parameter value doesn't comply to the constraints.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>The following example shows a minimalist definition of two parameters:</para> <para>The following example shows a minimalistic definition of two parameters:</para>
<programlisting language="yaml">parameters: <programlisting language="yaml">parameters:
user_name: user_name:
type: string type: string

View File

@@ -237,7 +237,7 @@ which builds a curl command with a valid token:</para>
# If you require control of the ID, you can pass it. # If you require control of the ID, you can pass it.
# The ID should be unique, unless you intend for duplicate # 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 # do the exact same thing, and will be treated as one signal
# (You can prove this by changing count above to 7) # (You can prove this by changing count above to 7)
wc_notify --data-binary '{"status": "SUCCESS", "id": "5"}' wc_notify --data-binary '{"status": "SUCCESS", "id": "5"}'