Merge "Reformat overlong lines"

This commit is contained in:
Jenkins 2014-08-14 08:00:50 +00:00 committed by Gerrit Code Review
commit 4cfb64daf4
10 changed files with 145 additions and 117 deletions
doc
admin-guide-cloud
cli-reference
config-reference
hot-guide/source
image-guide
install-guide
user-guide-admin
user-guide

@ -8,18 +8,21 @@ review up on review.openstack.org.
May 20, 2014 May 20, 2014
To do tasks: To do tasks:
- Add a chapter describing monitoring; deeper dive into Telemetry (ceilomter) - Add a chapter describing monitoring; deeper dive into Telemetry (ceilomter)
- Update networking information with the goal of starting a new Network Admin Guide* - Update networking information with the goal of starting a new
Network Admin Guide*
- Add more networking diagrams - Add more networking diagrams
- Add audience information; who is this book intended for - Add audience information; who is this book intended for
Ongoing tasks: Ongoing tasks:
- Ensure it meets conventions and standards - Ensure it meets conventions and standards
- Continually update with latest OpenStack dashboard (horizon) information - Continually update with latest OpenStack dashboard (horizon)
including great descriptions of fields and why you set a setting information including great descriptions of fields and why you set a
setting
- Continually add Python examples to SDK chapter - Continually add Python examples to SDK chapter
Wishlist tasks: Wishlist tasks:
- Replace all individual client commands (like keystone, nova) with openstack client - Replace all individual client commands (like keystone, nova) with
commands openstack client commands
* At Pycon Australia in August, a one-day "swarm" will focus on the Network Admin Guide * At Pycon Australia in August, a one-day "swarm" will focus on the
Network Admin Guide

@ -7,4 +7,3 @@ tool from the openstack-doc-tools package.
Do not change these files - change openstack-auto-commands and the Do not change these files - change openstack-auto-commands and the
python commands itself. python commands itself.

@ -12,7 +12,9 @@ To do tasks:
Ongoing tasks: Ongoing tasks:
- Ensure it meets conventions and standards - Ensure it meets conventions and standards
- Continually add CLI commands for integrated projects; but only when the release occurs - Continually add CLI commands for integrated projects; but only when
the release occurs
Wishlist tasks: Wishlist tasks:
- Add troubleshooting for clients - installation, environment variables. Can be common. - Add troubleshooting for clients - installation, environment
variables. Can be common.

@ -7,15 +7,17 @@ review up on review.openstack.org.
May 20, 2014 May 20, 2014
To do tasks: To do tasks:
- Add a chapter showing differences from release-to-release of renamed and removed options - Add a chapter showing differences from release-to-release of renamed
and removed options
- Add descriptions that describe why you would set a setting - Add descriptions that describe why you would set a setting
- Add information about additional options affected (in groups of settings) - Add information about additional options affected (in groups of settings)
- Add audience information; who is this book intended for - Add audience information; who is this book intended for
Ongoing tasks: Ongoing tasks:
- Ensure it meets conventions and standards - Ensure it meets conventions and standards
- Continually update with latest reference information including great descriptions - Continually update with latest reference information including great
of options and why you set a setting or groups of settings descriptions of options and why you set a setting or groups of
settings
Wishlist tasks: Wishlist tasks:
- Can distros like Ubuntu produce documented config files? - Can distros like Ubuntu produce documented config files?

@ -17,8 +17,9 @@
Heat Orchestration Template (HOT) Guide Heat Orchestration Template (HOT) Guide
======================================= =======================================
HOT is a new template format meant to replace the Heat CloudFormation-compatible HOT is a new template format meant to replace the Heat
format (CFN) as the native format supported by the Heat over time. CloudFormation-compatible format (CFN) as the native format supported
by the Heat over time.
This guide is targeted towards template authors and explains how to write This guide is targeted towards template authors and explains how to write
HOT templates based on examples. A detailed specification of HOT can be found HOT templates based on examples. A detailed specification of HOT can be found
at :ref:`hot_spec`. at :ref:`hot_spec`.
@ -27,10 +28,10 @@ at :ref:`hot_spec`.
Status Status
------ ------
HOT support is still under development and needs more work to provide access to HOT support is still under development and needs more work to provide
all functionality currently available via the CFN compatible template interface. access to all functionality currently available via the CFN compatible
This guide will be updated periodically whenever new features get implemented template interface. This guide will be updated periodically whenever
for HOT. new features get implemented for HOT.
---------------------------------- ----------------------------------
Writing a hello world HOT template Writing a hello world HOT template
@ -60,11 +61,12 @@ deploy a single compute instance.
image: F18-x86_64-cfntools image: F18-x86_64-cfntools
flavor: m1.small flavor: m1.small
Each HOT template has to include the *heat_template_version* key with value Each HOT template has to include the *heat_template_version* key with
'2013-05-23' (the current version of HOT). While the *description* is optional, value '2013-05-23' (the current version of HOT). While the
it is good practice to include some useful text that describes what users can do *description* is optional, it is good practice to include some useful
with the template. In case you want to provide a longer description that does text that describes what users can do with the template. In case you
not fit on a single line, you can provide multi-line text in YAML, for example: want to provide a longer description that does not fit on a single
line, you can provide multi-line text in YAML, for example:
:: ::
@ -76,20 +78,21 @@ The *resources* section is required and must contain at least one resource
definition. In the example above, a compute instance is defined with fixed definition. In the example above, a compute instance is defined with fixed
values for the 'key_name', 'image' and 'flavor' parameters. values for the 'key_name', 'image' and 'flavor' parameters.
Note that all those elements, i.e. a key-pair with the given name, the image and Note that all those elements, i.e. a key-pair with the given name, the
the flavor have to exist in the OpenStack environment where the template is image and the flavor have to exist in the OpenStack environment where
used. Typically a template is made more easily reusable, though, by defining a the template is used. Typically a template is made more easily
set of *input parameters* instead of hard-coding such values. reusable, though, by defining a set of *input parameters* instead of
hard-coding such values.
Template input parameters Template input parameters
------------------------- -------------------------
Input parameters defined in the *parameters* section of a HOT template (see also Input parameters defined in the *parameters* section of a HOT template
:ref:`hot_spec_parameters`) allow users to customize a template during (see also :ref:`hot_spec_parameters`) allow users to customize a
deployment. For example, this allows for providing custom key-pair names or template during deployment. For example, this allows for providing
image IDs to be used for a deployment. custom key-pair names or image IDs to be used for a deployment.
From a template author's perspective, this helps to make a template more easily From a template author's perspective, this helps to make a template
reusable by avoiding hardcoded assumptions. more easily reusable by avoiding hardcoded assumptions.
Sticking to the example used above, it makes sense to allow users to provide Sticking to the example used above, it makes sense to allow users to provide
their custom key-pairs, provide their own image, and to select a flavor for the their custom key-pairs, provide their own image, and to select a flavor for the
@ -130,10 +133,11 @@ resource properties have been replaced by references to the corresponding
input parameters by means of the *get_param* function (see also input parameters by means of the *get_param* function (see also
:ref:`hot_spec_intrinsic_functions`). :ref:`hot_spec_intrinsic_functions`).
You can also define default values for input parameters which will be used in You can also define default values for input parameters which will be
case the user does not provide the respective parameter during deployment. For used in case the user does not provide the respective parameter during
example, the following definition for the *instance_type* parameter would select deployment. For example, the following definition for the
the 'm1.small' flavor unless specified otherwise by the user. *instance_type* parameter would select the 'm1.small' flavor unless
specified otherwise by the user.
:: ::
@ -161,14 +165,15 @@ passwords as user input:
Restricting user input Restricting user input
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
In some cases you might want to restrict the values of input parameters that In some cases you might want to restrict the values of input
users can supply. For example, you might know that the software running in a parameters that users can supply. For example, you might know that the
compute instance needs a certain amount of resources so you might want to software running in a compute instance needs a certain amount of
restrict the *instance_type* parameter introduced above. Parameters in HOT resources so you might want to restrict the *instance_type* parameter
templates can be restricted by adding a *constraints* section (see also introduced above. Parameters in HOT templates can be restricted by
adding a *constraints* section (see also
:ref:`hot_spec_parameters_constraints`). :ref:`hot_spec_parameters_constraints`).
For example, the following would allow only three values to be provided as input For example, the following would allow only three values to be
for the *instance_type* parameter: provided as input for the *instance_type* parameter:
:: ::

@ -17,22 +17,23 @@
Heat Orchestration Template (HOT) Specification Heat Orchestration Template (HOT) Specification
=============================================== ===============================================
HOT is a new template format meant to replace the Heat CloudFormation-compatible HOT is a new template format meant to replace the Heat
format (CFN) as the native format supported by the Heat over time. CloudFormation-compatible format (CFN) as the native format supported
This specification explains in detail all elements of the HOT template format. by the Heat over time. This specification explains in detail all
An example driven guide to writing HOT templates can be found elements of the HOT template format. An example driven guide to
at :ref:`hot_guide`. writing HOT templates can be found at :ref:`hot_guide`.
------ ------
Status Status
------ ------
HOT is considered reliable, supported, and standardized as of our HOT is considered reliable, supported, and standardized as of our
Icehouse (April 2014) release. The Heat core team may make improvements Icehouse (April 2014) release. The Heat core team may make
to the standard, which very likely would be backward compatible. The template improvements to the standard, which very likely would be backward
format is also versioned. In our Juno release, Heat will support multiple compatible. The template format is also versioned. In our Juno
different versions of the HOT specification if there is a need driven by the release, Heat will support multiple different versions of the HOT
introduction of new features. specification if there is a need driven by the introduction of new
features.
------------------ ------------------
@ -74,9 +75,9 @@ parameter_groups
*optional* and can be omitted when necessary. *optional* and can be omitted when necessary.
parameters parameters
This section allows for specifying input parameters that have to be provided This section allows for specifying input parameters that have to
when instantiating the template. The section is *optional* and can be be provided when instantiating the template. The section is
omitted when no input is required. *optional* and can be omitted when no input is required.
resources resources
This section contains the declaration of the single resources of the This section contains the declaration of the single resources of the
@ -85,9 +86,9 @@ resources
instantiated. instantiated.
outputs outputs
This section allows for specifying output parameters available to users once This section allows for specifying output parameters available to
the template has been instantiated. This section is *optional* and can be users once the template has been instantiated. This section is
omitted when no output values are required. *optional* and can be omitted when no output values are required.
.. _hot_spec_parameter_groups: .. _hot_spec_parameter_groups:
@ -165,12 +166,12 @@ type
are *string*, *number*, *comma_delimited_list*, *json*, or *boolean*. are *string*, *number*, *comma_delimited_list*, *json*, or *boolean*.
label label
This *optional* attribute allows for giving a human readable name of the This *optional* attribute allows for giving a human readable name
parameter. of the parameter.
description description
This *optional* attribute allows for giving a human readable description of This *optional* attribute allows for giving a human readable
the parameter. description of the parameter.
default default
This *optional* attribute allows for defining a default value for the This *optional* attribute allows for defining a default value for the
@ -209,13 +210,13 @@ provide a useful description and label for each parameter.
Parameter Constraints Parameter Constraints
--------------------- ---------------------
The *constraints* block of a parameter definition allows for defining additional The *constraints* block of a parameter definition allows for defining
validation constraints that apply to the value of the parameter. At additional validation constraints that apply to the value of the
instantiation time of the template, user provided parameter values are validated parameter. At instantiation time of the template, user provided
against those constraints to make sure the provided values match expectations of parameter values are validated against those constraints to make sure
the template author. the provided values match expectations of the template author.
Constraints are defined in the form of a bulleted list according to the Constraints are defined in the form of a bulleted list according to
following syntax: the following syntax:
:: ::
@ -331,9 +332,9 @@ For example:
allowed_pattern allowed_pattern
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
The *allowed_pattern* constraint applies to parameters of type string and allows The *allowed_pattern* constraint applies to parameters of type string
for specifying a regular expression against which a user provided parameter and allows for specifying a regular expression against which a user
value must evaluate at deployment. provided parameter value must evaluate at deployment.
The syntax of the allowed_pattern constraint is: The syntax of the allowed_pattern constraint is:
:: ::
@ -399,11 +400,11 @@ via the `get_param`_ intrinsic function just like user-defined parameters.
Resources Section Resources Section
----------------- -----------------
In the *resources* section, the templates for actual resources that will make up In the *resources* section, the templates for actual resources that
a stack deployed from the HOT template (e.g. compute instances, networks, will make up a stack deployed from the HOT template (e.g. compute
storage volumes) are defined. instances, networks, storage volumes) are defined.
Each resource is defined as a separate block in the resources section according Each resource is defined as a separate block in the resources section
to the syntax below. according to the syntax below.
:: ::
@ -506,10 +507,10 @@ following example:
Outputs Section Outputs Section
--------------- ---------------
In the *outputs* section, any output parameters that should be available to the In the *outputs* section, any output parameters that should be
user can be defined. Typically, this would be, for example, parameters such as available to the user can be defined. Typically, this would be, for
IP addresses of deployed instances, or URLs of web applications deployed as part example, parameters such as IP addresses of deployed instances, or
of a stack. URLs of web applications deployed as part of a stack.
Each output parameter is defined as a separate block within the outputs section Each output parameter is defined as a separate block within the outputs section
according to the following syntax: according to the following syntax:
@ -522,8 +523,8 @@ according to the following syntax:
value: <parameter value> value: <parameter value>
parameter name parameter name
An output parameter block is headed by the output parameter name, which must An output parameter block is headed by the output parameter name,
be unique within the outputs section of a template. which must be unique within the outputs section of a template.
description description
This element gives a short description of the output parameter. This element gives a short description of the output parameter.
parameter value parameter value
@ -532,8 +533,8 @@ parameter value
of one of the stack's resources (see also of one of the stack's resources (see also
:ref:`hot_spec_intrinsic_functions`). :ref:`hot_spec_intrinsic_functions`).
The example below shows, how the IP address of a compute resource can be defined The example below shows, how the IP address of a compute resource can
as an output parameter. be defined as an output parameter.
:: ::
@ -556,9 +557,10 @@ below.
get_attr get_attr
-------- --------
The *get_attr* function allows referencing an attribute of a resource. At The *get_attr* function allows referencing an attribute of a
runtime, it will be resolved to the value of an attribute of a resource instance resource. At runtime, it will be resolved to the value of an attribute
created from the respective resource definition of the template. of a resource instance created from the respective resource definition
of the template.
The syntax of the get_attr function is as follows: The syntax of the get_attr function is as follows:
:: ::
@ -657,10 +659,10 @@ a *files* dictionary containing entries with keys
get_param get_param
--------- ---------
The *get_param* function allows for referencing an input parameter of a template The *get_param* function allows for referencing an input parameter of
from anywhere within a template. At runtime, it will be resolved to the value a template from anywhere within a template. At runtime, it will be
provided for this input parameter. The syntax of the get_param function is as resolved to the value provided for this input parameter. The syntax of
follows: the get_param function is as follows:
:: ::
@ -722,8 +724,8 @@ The syntax of the get_resource function is as follows:
get_resource: <resource ID> get_resource: <resource ID>
The *resource ID* of the referenced resources as used in the current template is The *resource ID* of the referenced resources as used in the current
given as single parameter to the get_resource function. template is given as single parameter to the get_resource function.
list_join list_join
@ -748,9 +750,14 @@ This would resolve to "one, two, and three".
resource_facade resource_facade
--------------- ---------------
The *resource_facade* function allows a provider template to retrieve data
about its resource facade in the parent template. (A provider template is used to provide a custom definition of a resource - the facade - in the form of a Heat template. The resource's properties are passed to the provider template as its parameters, but other resource data can be included using this function.) The *resource_facade* function allows a provider template to retrieve
The syntax of the *resource_facade* function is as follows:: data about its resource facade in the parent template. (A provider
template is used to provide a custom definition of a resource - the
facade - in the form of a Heat template. The resource's properties are
passed to the provider template as its parameters, but other resource
data can be included using this function.) The syntax of the
*resource_facade* function is as follows::
resource_facade: <data type> resource_facade: <data type>
@ -800,8 +807,9 @@ section of a template to build a URL for logging into a deployed application.
params: params:
host: { get_attr: [ my_instance, first_address ] } host: { get_attr: [ my_instance, first_address ] }
The str_replace function can also be used for constructing bigger chunks of text The str_replace function can also be used for constructing bigger
like scripts for initializing compute instances as shown in the example below: chunks of text like scripts for initializing compute instances as
shown in the example below:
:: ::

@ -7,12 +7,13 @@ review up on review.openstack.org.
May 21, 2014 May 21, 2014
To do tasks: To do tasks:
- Add a chapter describing how to make an image for Database as a Service (trove) - Add a chapter describing how to make an image for Database as a
Service (trove)
- Add audience information; who is this book intended for - Add audience information; who is this book intended for
Ongoing tasks: Ongoing tasks:
- Ensure it meets conventions and standards - Ensure it meets conventions and standards
Wishlist tasks: Wishlist tasks:
- Replace all individual client commands (like keystone, glance) with openstack client - Replace all individual client commands (like keystone, glance) with
commands openstack client commands

@ -15,8 +15,8 @@ To do tasks:
- Unify chapter and section names (such as Overview) - Unify chapter and section names (such as Overview)
- Add sample output of each command and highlight important parts - Add sample output of each command and highlight important parts
- Mention project as standard but tenant must be used for CLI params - Mention project as standard but tenant must be used for CLI params
- Refer to generic SQL database and update for MariaDB (RHEL), MySQL, and - Refer to generic SQL database and update for MariaDB (RHEL), MySQL,
PostgreSQL and PostgreSQL
- Provide sample configuration files for each node - Provide sample configuration files for each node
- Compute and network nodes should reference server on controller node - Compute and network nodes should reference server on controller node
- Update password list - Update password list
@ -27,4 +27,5 @@ Ongoing tasks:
- Continually update with latest release information relevant to install - Continually update with latest release information relevant to install
Wishlist tasks: Wishlist tasks:
- Replace all individual client commands (like keystone, nova) with openstack client commands - Replace all individual client commands (like keystone, nova) with
openstack client commands

@ -11,12 +11,16 @@ To do tasks:
Ongoing tasks: Ongoing tasks:
- Ensure it meets conventions and standards - Ensure it meets conventions and standards
- Continually update with latest OpenStack dashboard (horizon) information - Continually update with latest OpenStack dashboard (horizon)
including great descriptions of fields and why you set a setting information including great descriptions of fields and why you set a
setting
Wishlist tasks: Wishlist tasks:
- Get examples of common tasks from real admins and add to this guide as how-to: migration of VM from one host to another, quota management, targeting launch on a particular compute node - Get examples of common tasks from real admins and add to this guide
as how-to: migration of VM from one host to another, quota
management, targeting launch on a particular compute node
- Create flavor example - also refer to from Ops Guide (Anne Gentle todo) - Create flavor example - also refer to from Ops Guide (Anne Gentle todo)
- Migrations examples (Anne Gentle todo) - Migrations examples (Anne Gentle todo)
- Create tenant example with CLI - Create tenant example with CLI
- Replace all individual client commands (like keystone, nova) with openstack client commands - Replace all individual client commands (like keystone, nova) with
openstack client commands

@ -8,16 +8,19 @@ review up on review.openstack.org.
May 20, 2014 May 20, 2014
To do tasks: To do tasks:
- Add a chapter describing the HOT templates for Orchestration, how to use them - Add a chapter describing the HOT templates for Orchestration, how to use them
- Add reference information about HOT templates for Orchestration; attempt to automate - Add reference information about HOT templates for Orchestration;
attempt to automate
Ongoing tasks: Ongoing tasks:
- Ensure it meets conventions and standards - Ensure it meets conventions and standards
- Continually update with latest OpenStack dashboard (horizon) information - Continually update with latest OpenStack dashboard (horizon)
including great descriptions of fields and why you set a setting information including great descriptions of fields and why you set a
setting
- Continually add Python examples to SDK chapter - Continually add Python examples to SDK chapter
Wishlist tasks: Wishlist tasks:
- Investigate moving to simpler markup and still enabling translation - Investigate moving to simpler markup and still enabling translation
- Replace all individual client commands (like keystone, nova) with openstack client - Replace all individual client commands (like keystone, nova) with
commands openstack client commands
- Create a new security group, boot a VM, and then add the newly created security group to the running VM - Create a new security group, boot a VM, and then add the newly
created security group to the running VM