diff --git a/doc/source/conf.py b/doc/source/conf.py index f6e3480a34..0844b38dfa 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -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'), ] diff --git a/doc/source/developer-docs/contribute.rst b/doc/source/developer-docs/contribute.rst index a1dfc96bde..276dd36de8 100644 --- a/doc/source/developer-docs/contribute.rst +++ b/doc/source/developer-docs/contribute.rst @@ -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`_. diff --git a/doc/source/developer-docs/extending.rst b/doc/source/developer-docs/extending.rst index c39f279f11..315f1a6ce4 100644 --- a/doc/source/developer-docs/extending.rst +++ b/doc/source/developer-docs/extending.rst @@ -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 diff --git a/doc/source/developer-docs/index.rst b/doc/source/developer-docs/index.rst index c369f9b805..d3b4f585e0 100644 --- a/doc/source/developer-docs/index.rst +++ b/doc/source/developer-docs/index.rst @@ -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` - diff --git a/doc/source/developer-docs/quickstart-aio.rst b/doc/source/developer-docs/quickstart-aio.rst index 078a26e98e..f73b2cadff 100644 --- a/doc/source/developer-docs/quickstart-aio.rst +++ b/doc/source/developer-docs/quickstart-aio.rst @@ -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 diff --git a/doc/source/install-guide/overview-security.rst b/doc/source/install-guide/overview-security.rst index d3243b2d3a..0b2bbbc4e5 100644 --- a/doc/source/install-guide/overview-security.rst +++ b/doc/source/install-guide/overview-security.rst @@ -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