Merge "[ops-guide] Address sphinx-build error"
This commit is contained in:
commit
97d5e1d95e
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
~~~~~~~~~~
|
||||
|
|
|
@ -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`).
|
||||
|
|
|
@ -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
|
||||
---------------
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue