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:
parent
385ff7e5d9
commit
3c13731ed4
@ -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
|
||||
|
||||
|
@ -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
|
||||
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>
|
||||
<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:
|
||||
instance_port:
|
||||
type: OS::Neutron::Port
|
||||
@ -176,7 +204,6 @@ floating IP to a port:</para>
|
||||
type: OS::Neutron::FloatingIP
|
||||
properties:
|
||||
floating_network: public
|
||||
port_id: { get_resource: instance_port }
|
||||
|
||||
association:
|
||||
type: OS::Neutron::FloatingIPAssociation
|
||||
|
@ -34,7 +34,7 @@ properties.</para>
|
||||
<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
|
||||
<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:
|
||||
key_name:
|
||||
@ -53,7 +53,8 @@ resources:
|
||||
<title>Use the template filename as type</title>
|
||||
<para>The following template defines the <literal>my_nova.yaml</literal> file as value for the
|
||||
<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:
|
||||
my_server:
|
||||
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">
|
||||
<?dbhtml stop-chunking?>
|
||||
<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
|
||||
resource will override the default one.</para>
|
||||
<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>
|
||||
</note>
|
||||
<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:
|
||||
type: OS::Nova::Server
|
||||
properties:
|
||||
@ -105,4 +108,37 @@ default resource of the same name.</para>
|
||||
<para>To create the stack run:</para>
|
||||
<programlisting language="console">$ heat stack-create -f main.yaml -e env.yaml example-two</programlisting>
|
||||
</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>
|
||||
|
@ -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>
|
||||
</note>
|
||||
</section>
|
||||
<section xml:id="hidding-parameters-values">
|
||||
<section xml:id="hiding-parameters-values">
|
||||
<title>Hiding parameters values</title>
|
||||
<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
|
||||
|
@ -203,7 +203,7 @@ if the parameter value doesn't comply to the constraints.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</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:
|
||||
user_name:
|
||||
type: string
|
||||
|
@ -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.
|
||||
# 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"}'
|
||||
|
Loading…
Reference in New Issue
Block a user