Doc: Remove 'indices and tables' and correctly spell OpenStack-Ansible
This updates the use of OpenStack-Ansible in various docs to ensure that they are all correctly capitalised. This also removes 'indices and tables' from the Dev Docs as none of the links work. Change-Id: I30a16a2d6d6ac355c794de563afd4b3f661a9b32
This commit is contained in:
Jesse Pretorius
parent
c14d2eb78d
commit
57b2114d7d
@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python3
|
||||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# openstack-ansible documentation build configuration file, created by
|
||||
# OpenStack-Ansible Documentation build configuration file, created by
|
||||
# sphinx-quickstart on Mon Apr 13 20:42:26 2015.
|
||||
#
|
||||
# This file is execfile()d with the current directory set to its
|
||||
@ -49,9 +49,9 @@ source_suffix = '.rst'
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = 'openstack-ansible'
|
||||
copyright = '2015, openstack-ansible contributors'
|
||||
author = 'openstack-ansible contributors'
|
||||
project = 'OpenStack-Ansible'
|
||||
copyright = '2016, OpenStack-Ansible Contributors'
|
||||
author = 'OpenStack-Ansible Contributors'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
@ -226,8 +226,8 @@ latex_elements = {
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'openstack-ansible.tex',
|
||||
'openstack-ansible Documentation',
|
||||
'openstack-ansible contributors', 'manual'),
|
||||
'OpenStack-Ansible Documentation',
|
||||
'OpenStack-Ansible Contributors', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
@ -257,7 +257,7 @@ latex_documents = [
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'openstack-ansible',
|
||||
'openstack-ansible Documentation',
|
||||
'OpenStack-Ansible Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
@ -272,8 +272,9 @@ man_pages = [
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'openstack-ansible',
|
||||
'openstack-ansible Documentation',
|
||||
author, 'openstack-ansible', 'One line description of project.',
|
||||
'OpenStack-Ansible Documentation',
|
||||
author, 'OpenStack-Ansible',
|
||||
'OpenStack-Ansible deploys OpenStack environments using Ansible.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
||||
@ -45,7 +45,7 @@ Triaging bugs
|
||||
`````````````
|
||||
Reported bugs need prioritization, confirmation, and shouldn't go stale.
|
||||
If you care about OpenStack stability but aren't wanting to actively
|
||||
develop the roles and playbooks used within the "openstack-ansible"
|
||||
develop the roles and playbooks used within the OpenStack-Ansible
|
||||
project consider contributing in the area of bug triage, which helps
|
||||
immensely. The whole process is described in the upstream
|
||||
`Bug Triage Documentation`_.
|
||||
|
||||
@ -11,7 +11,7 @@ overriding existing variables.
|
||||
Using these extension points, deployers can provide a more 'opinionated'
|
||||
installation of OpenStack that may include their own software.
|
||||
|
||||
Including openstack-ansible in your project
|
||||
Including OpenStack-Ansible in your project
|
||||
-------------------------------------------
|
||||
|
||||
Including the openstack-ansible repository within another project can be
|
||||
@ -21,7 +21,7 @@ done in several ways.
|
||||
2. A script to automatically perform a git checkout of
|
||||
openstack-ansible
|
||||
|
||||
When including openstack-ansible in a project, consider using a parallel
|
||||
When including OpenStack-Ansible in a project, consider using a parallel
|
||||
directory structure as shown in the `ansible.cfg files`_ section.
|
||||
|
||||
Also note that copying files into directories such as `env.d`_ or
|
||||
@ -32,26 +32,26 @@ ansible.cfg files
|
||||
-----------------
|
||||
|
||||
You can create your own playbook, variable, and role structure while still
|
||||
including the openstack-ansible roles and libraries by putting an
|
||||
including the OpenStack-Ansible roles and libraries by putting an
|
||||
``ansible.cfg`` file in your ``playbooks`` directory.
|
||||
|
||||
The relevant options for Ansible 1.9 (included in openstack-ansible)
|
||||
The relevant options for Ansible 1.9 (included in OpenStack-Ansible)
|
||||
are as follows:
|
||||
|
||||
``library``
|
||||
This variable should point to
|
||||
``openstack-ansible/playbooks/library``. Doing so allows roles and
|
||||
playbooks to access openstack-ansible's included Ansible modules.
|
||||
playbooks to access OpenStack-Ansible's included Ansible modules.
|
||||
``roles_path``
|
||||
This variable should point to
|
||||
``openstack-ansible/playbooks/roles``. This allows Ansible to
|
||||
properly look up any openstack-ansible roles that extension roles
|
||||
properly look up any OpenStack-Ansible roles that extension roles
|
||||
may reference.
|
||||
``inventory``
|
||||
This variable should point to
|
||||
``openstack-ansible/playbooks/inventory``. With this setting,
|
||||
extensions have access to the same dynamic inventory that
|
||||
openstack-ansible uses.
|
||||
OpenStack-Ansible uses.
|
||||
|
||||
Note that the paths to the ``openstack-ansible`` top level directory can be
|
||||
relative in this file.
|
||||
@ -74,19 +74,19 @@ The variables in ``my_project/custom_stuff/playbooks/ansible.cfg`` would use
|
||||
env.d
|
||||
-----
|
||||
|
||||
The openstack-ansible default environment, including container and host
|
||||
The OpenStack-Ansible default environment, including container and host
|
||||
group mappings, resides in ``/etc/openstack_deploy/openstack_environment.yml``.
|
||||
|
||||
The ``/etc/openstack_deploy/env.d`` directory sources all YAML files into the
|
||||
deployed environment, allowing a deployer to define additional group mappings
|
||||
without having to edit the ``openstack_environment.yml`` file, which is
|
||||
controlled by the openstack-ansible project itself.
|
||||
controlled by the OpenStack-Ansible project itself.
|
||||
|
||||
conf.d
|
||||
------
|
||||
|
||||
Common OpenStack services and their configuration are defined by
|
||||
openstack-ansible in the
|
||||
OpenStack-Ansible in the
|
||||
``/etc/openstack_deploy/openstack_user_config.yml`` settings file.
|
||||
|
||||
Additional services should be defined with a YAML file in
|
||||
@ -101,7 +101,7 @@ sourced in any ``openstack-ansible`` command. Alternatively, the files can be
|
||||
sourced with the ``-e`` parameter of the ``ansible-playbook`` command.
|
||||
|
||||
``user_variables.yml`` and ``user_secrets.yml`` are used directly by
|
||||
openstack-ansible; adding custom values here is not recommended.
|
||||
OpenStack-Ansible; adding custom values here is not recommended.
|
||||
|
||||
``user_extras_variables.yml`` and ``users_extras_secrets.yml`` are provided
|
||||
and can contain deployer's custom values, but deployers can add any other
|
||||
|
||||
@ -2,7 +2,7 @@ Developer Documentation
|
||||
=======================
|
||||
|
||||
In this section, you will find documentation relevant to developing
|
||||
openstack-ansible.
|
||||
OpenStack-Ansible.
|
||||
|
||||
Contents:
|
||||
|
||||
@ -15,11 +15,3 @@ Contents:
|
||||
extending
|
||||
contribute
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ There are four main steps for running a customized AIO build:
|
||||
* Initial host bootstrap
|
||||
* Run playbooks
|
||||
|
||||
Start by cloning the openstack-ansible repository and changing into the
|
||||
Start by cloning the OpenStack-Ansible repository and changing into the
|
||||
repository root directory:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -17,7 +17,7 @@ AppArmor
|
||||
~~~~~~~~
|
||||
|
||||
The Linux kernel offers multiple `security modules`_ (LSMs) that that set
|
||||
`mandatory access controls`_ (MAC) on Linux systems. The openstack-ansible
|
||||
`mandatory access controls`_ (MAC) on Linux systems. The OpenStack-Ansible
|
||||
project configures `AppArmor`_, a Linux security module, to provide additional
|
||||
security on LXC container hosts. AppArmor allows administrators to set
|
||||
specific limits and policies around what resources a particular application
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user