Merge "Reformat overlong lines"
This commit is contained in:
commit
4cfb64daf4
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
|
||||||
|
Loading…
x
Reference in New Issue
Block a user