Merge "[ops-guide] Address sphinx-build error"

This commit is contained in:
Jenkins 2016-03-21 01:54:57 +00:00 committed by Gerrit Code Review
commit 97d5e1d95e
8 changed files with 34 additions and 33 deletions

View File

@ -267,7 +267,7 @@ tool. This tool tests database migration performance on copies of
real-world user databases.
These changes have facilitated the first proper OpenStack upgrade guide,
found in :doc:`ch_ops_upgrades`, and will continue to improve in the next
found in :doc:`ops_upgrades`, and will continue to improve in the next
release.
Deprecation of Nova Network

View File

@ -364,7 +364,7 @@ space, and so on, are associated with a project.
OpenStack Identity provides authentication decisions and user attribute
information, which is then used by the other OpenStack services to
perform authorization. The policy is set in the ``policy.json`` file.
For information on how to configure these, see :doc:`ch_ops_projects_users`
For information on how to configure these, see :doc:`ops_projects_users`
OpenStack Identity supports different plug-ins for authentication
decisions and identity storage. Examples of these plug-ins include:

View File

@ -302,7 +302,7 @@ particular use case.
Logging
~~~~~~~
Logging is detailed more fully in :doc:`ch_ops_log_monitor`. However,
Logging is detailed more fully in :doc:`ops_logging_monitoring`. However,
it is an important design consideration to take into account before
commencing operations of your cloud.
@ -315,7 +315,7 @@ Networking
~~~~~~~~~~
Networking in OpenStack is a complex, multifaceted challenge. See
:doc:`ch_arch_network_design`.
:doc:`arch_network_design`.
Conclusion
~~~~~~~~~~

View File

@ -250,10 +250,10 @@ Optional Extensions
You can extend this reference architecture aslegacy networking (nova)
optional extensions follows:
- Add additional cloud controllers (see :doc:`ch_ops_maintenance`).
- Add additional cloud controllers (see :doc:`ops_maintenance`).
- Add an OpenStack Storage service (see the Object Storage chapter in
the *OpenStack Installation Guide* for your distribution).
- Add additional OpenStack Block Storage hosts (see
:doc:`ch_ops_maintenance`).
:doc:`ops_maintenance`).

View File

@ -122,7 +122,7 @@ CPU performance (CPU/core).
.. note::
For a discussion of metric tracking, including how to extract
metrics from your cloud, see :doc:`ch_ops_log_monitor`.
metrics from your cloud, see :doc:`ops_logging_monitoring`.
Adding Cloud Controller Nodes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -155,7 +155,7 @@ the one machine.
Several options are available for MySQL load balancing, and the
supported AMQP brokers have built-in clustering support. Information
on how to configure these and many of the other services can be
found in :doc:`part_operations`.
found in :doc:`operations`.
Segregating Your Cloud
~~~~~~~~~~~~~~~~~~~~~~
@ -408,7 +408,7 @@ When adding object storage nodes, a weight should be specified that
reflects the capability of the node.
Monitoring the resource usage and user growth will enable you to know
when to procure. :doc:`ch_ops_log_monitor` details some useful metrics.
when to procure. :doc:`ops_logging_monitoring` details some useful metrics.
Burn-in Testing
---------------

View File

@ -95,7 +95,7 @@ The next best approach is to use a configuration-management tool, such
as Puppet, to automatically build a cloud controller. This should not
take more than 15 minutes if you have a spare server available. After
the controller rebuilds, restore any backups taken
(see :doc:`ch_ops_backup_recovery`).
(see :doc:`ops_backup_recovery`).
Also, in practice, the ``nova-compute`` services on the compute nodes do
not always reconnect cleanly to rabbitmq hosted on the controller when
@ -879,7 +879,7 @@ Terminal 2:
# nova list
Look for any errors or traces in the log file. For more information, see
:ref:`ch_ops_log_monitor`.
:doc:`ops_logging_monitoring`.
If the error indicates that the problem is with another component,
switch to tailing that component's log file. For example, if nova cannot

View File

@ -1846,7 +1846,8 @@ handles early initialization of a cloud instance that makes use of this
user data.
This user data can be put in a file on your local system and then passed
in at instance creation with the flag :option:`--user-data <user-data-file>`
in at instance creation with the flag
:option:`--user-data` ``<user-data-file>``.
For example
@ -1863,7 +1864,7 @@ File injection
--------------
Arbitrary local files can also be placed into the instance file system
at creation time by using the :option:`--file <dst-path=src-path>` option.
at creation time by using the :option:`--file` ``<dst-path=src-path>`` option.
You may store up to five files.
For example, let's say you have a special ``authorized_keys`` file named

View File

@ -125,7 +125,7 @@ your OpenStack cloud.
lot of background knowledge. However, if you are fairly new to cloud
computing, we recommend that you make use of the :doc:`common/glossary`
at the back of the book, as well as the online documentation for OpenStack
and additional resources mentioned in this book in :doc:`ch_ops_resources`.
and additional resources mentioned in this book in :doc:`app_resources`.
Further Reading
---------------
@ -196,38 +196,38 @@ OpenStack clouds.
**Part I:**
:doc:`ch_arch_examples`
:doc:`arch_examples`
Because of all the decisions the other chapters discuss, this
chapter describes the decisions made for this particular book and
much of the justification for the example architecture.
:doc:`ch_arch_provision`
:doc:`arch_provision`
While this book doesn't describe installation, we do recommend
automation for deployment and configuration, discussed in this
chapter.
:doc:`ch_arch_cloud_controller`
:doc:`arch_cloud_controller`
The cloud controller is an invention for the sake of consolidating
and describing which services run on which nodes. This chapter
discusses hardware and network considerations as well as how to
design the cloud controller for performance and separation of
services.
:doc:`ch_arch_compute_nodes`
:doc:`arch_compute_nodes`
This chapter describes the compute nodes, which are dedicated to
running virtual machines. Some hardware choices come into play here,
as well as logging and networking descriptions.
:doc:`ch_arch_scaling`
:doc:`arch_scaling`
This chapter discusses the growth of your cloud resources through
scaling and segregation considerations.
:doc:`ch_arch_storage`
:doc:`arch_storage`
As with other architecture decisions, storage concepts within
OpenStack offer many options. This chapter lays out the choices for
you.
:doc:`ch_arch_network_design`
:doc:`arch_network_design`
Your OpenStack cloud networking needs to fit into your existing
networks while also enabling the best design for your users and
administrators, and this chapter gives you in-depth information
@ -235,54 +235,54 @@ OpenStack clouds.
**Part II:**
:doc:`ch_ops_lay_of_land`
:doc:`ops_lay_of_the_land`
This chapter is written to let you get your hands wrapped around
your OpenStack cloud through command-line tools and understanding
what is already set up in your cloud.
:doc:`ch_ops_projects_users`
:doc:`ops_projects_users`
This chapter walks through user-enabling processes that all admins
must face to manage users, give them quotas to parcel out resources,
and so on.
:doc:`ch_ops_user_facing`
:doc:`ops_user_facing_operations`
This chapter shows you how to use OpenStack cloud resources and how
to train your users.
:doc:`ch_ops_maintenance`
:doc:`ops_maintenance`
This chapter goes into the common failures that the authors have
seen while running clouds in production, including troubleshooting.
:doc:`ch_ops_network_troubleshooting`
:doc:`ops_network_troubleshooting`
Because network troubleshooting is especially difficult with virtual
resources, this chapter is chock-full of helpful tips and tricks for
tracing network traffic, finding the root cause of networking
failures, and debugging related services, such as DHCP and DNS.
:doc:`ch_ops_log_monitor`
:doc:`ops_logging_monitoring`
This chapter shows you where OpenStack places logs and how to best
read and manage logs for monitoring purposes.
:doc:`ch_ops_backup_recovery`
:doc:`ops_backup_recovery`
This chapter describes what you need to back up within OpenStack as
well as best practices for recovering backups.
:doc:`ch_ops_customize`
:doc:`ops_customize`
For readers who need to get a specialized feature into OpenStack,
this chapter describes how to use DevStack to write custom
middleware or a custom scheduler to rebalance your resources.
:doc:`ch_ops_upstream`
:doc:`ops_upstream`
Because OpenStack is so, well, open, this chapter is dedicated to
helping you navigate the community and find out where you can help
and where you can get help.
:doc:`ch_ops_advanced_configuration`
:doc:`ops_advanced_configuration`
Much of OpenStack is driver-oriented, so you can plug in different
solutions to the base set of services. This chapter describes some
advanced configuration topics.
:doc:`ch_ops_upgrades`
:doc:`ops_upgrades`
This chapter provides upgrade information based on the architectures
used in this book.
@ -301,7 +301,7 @@ OpenStack clouds.
Read about how to track the OpenStack roadmap through the open and
transparent development processes.
:doc:`ch_ops_resources`
:doc:`app_resources`
So many OpenStack resources are available online because of the
fast-moving nature of the project, but there are also resources
listed here that the authors found helpful while learning