From 06708191d6bfaf627f8f0a51f1c90cb06c20f2f4 Mon Sep 17 00:00:00 2001 From: Matt Thompson Date: Tue, 20 Oct 2015 12:07:04 +0100 Subject: [PATCH] Install Guide Cleanup This commit does the following: - sets all shell prompts in code-blocks to the root prompt - uses shell-session code-block since the shell prompt was being treated as a comment - links configure-aodh.rst in configure.rst (running tox was complaining that this file wasn't being linked anywhere) - other minor cleanup Change-Id: I9e3ac8bb0cabd1cc17952cfd765dbb0d8f7b6fa2 --- doc/source/install-guide/app-minorupgrade.rst | 134 +++++++++++------- doc/source/install-guide/app-tips.rst | 4 +- doc/source/install-guide/configure-aodh.rst | 46 +++--- .../install-guide/configure-ceilometer.rst | 46 +++--- .../install-guide/configure-cinder-az.rst | 8 +- .../install-guide/configure-cinder-backup.rst | 4 +- .../install-guide/configure-cinder-nfs.rst | 14 +- doc/source/install-guide/configure-cinder.rst | 20 +-- .../configure-configurationintegrity.rst | 4 +- doc/source/install-guide/configure-creds.rst | 7 +- .../configure-federation-mapping.rst | 4 +- .../configure-federation-wrapper.rst | 12 +- doc/source/install-guide/configure-glance.rst | 19 ++- .../install-guide/configure-networking.rst | 20 +-- .../configure-sslcertificates.rst | 8 +- .../install-guide/configure-swift-add.rst | 7 +- .../install-guide/configure-swift-config.rst | 6 +- .../install-guide/configure-swift-devices.rst | 58 ++++---- .../install-guide/configure-swift-glance.rst | 6 +- .../configure-swift-policies.rst | 7 +- doc/source/install-guide/configure-swift.rst | 4 +- doc/source/install-guide/configure.rst | 1 + .../install-guide/deploymenthost-add.rst | 3 +- .../install-guide/deploymenthost-osa.rst | 5 +- .../install-guide/install-foundation-run.rst | 18 +-- .../install-infrastructure-run.rst | 6 +- .../install-infrastructure-verify.rst | 12 +- .../install-guide/install-openstack-run.rst | 10 +- .../install-openstack-verify.rst | 17 ++- .../install-guide/ops-addcomputehost.rst | 6 +- .../install-guide/ops-galera-recovery.rst | 12 +- .../ops-galera-recoverycomplete.rst | 4 +- .../ops-galera-recoverycontainer.rst | 26 ++-- .../ops-galera-recoverymulti.rst | 15 +- .../ops-galera-recoverysingle.rst | 6 +- .../install-guide/ops-galera-remove.rst | 6 +- doc/source/install-guide/ops-galera-start.rst | 16 +-- ...ps-troubleshooting-containernetworking.rst | 6 +- doc/source/install-guide/overview-lxc.rst | 10 +- doc/source/install-guide/targethosts-add.rst | 5 +- .../install-guide/targethosts-configlvm.rst | 3 +- .../targethosts-networkrefarch.rst | 10 +- .../install-guide/targethosts-sshkeys.rst | 2 +- 43 files changed, 330 insertions(+), 307 deletions(-) diff --git a/doc/source/install-guide/app-minorupgrade.rst b/doc/source/install-guide/app-minorupgrade.rst index b47cc5a6c8..95a20c3aff 100644 --- a/doc/source/install-guide/app-minorupgrade.rst +++ b/doc/source/install-guide/app-minorupgrade.rst @@ -15,89 +15,127 @@ In order to facilitate this extra options may be passed to the python package installer to reinstall based on whatever version of the package is available in the repository. This is done by executing, for example: -.. code-block:: bash +.. code-block:: shell-session - openstack-ansible -e pip_install_options="--force-reinstall" \ + # openstack-ansible -e pip_install_options="--force-reinstall" \ setup-openstack.yml A minor upgrade will typically require the execution of the following: -.. code-block:: bash +1. Change directory into the repository clone root directory:: - # Change directory into the repository clone root directory - cd /opt/openstack-ansible + .. code-block:: shell-session - # Update the git remotes - git fetch --all + # cd /opt/openstack-ansible - # Checkout the latest tag (the below tag is an example) - git checkout 12.0.1 +2. Update the git remotes - # Change into the playbooks directory - cd playbooks + .. code-block:: shell-session - # Build the updated repository - openstack-ansible repo-install.yml + # git fetch --all - # Update RabbitMQ - openstack-ansible -e rabbitmq_upgrade=true \ - rabbitmq-install.yml +3. Checkout the latest tag (the below tag is an example) - # Update the Utility Container - openstack-ansible -e pip_install_options="--force-reinstall" \ - utility-install.yml + .. code-block:: shell-session - # Update all OpenStack Services - openstack-ansible -e pip_install_options="--force-reinstall" \ - setup-openstack.yml + # git checkout 12.0.1 + +4. Change into the playbooks directory + + .. code-block:: shell-session + + # cd playbooks + +5. Build the updated repository + + .. code-block:: shell-session + + # openstack-ansible repo-install.yml + +6. Update RabbitMQ + + .. code-block:: shell-session + + # openstack-ansible -e rabbitmq_upgrade=true \ + rabbitmq-install.yml + +7. Update the Utility Container + + .. code-block:: shell-session + + # openstack-ansible -e pip_install_options="--force-reinstall" \ + utility-install.yml + +8. Update all OpenStack Services + + .. code-block:: shell-session + + # openstack-ansible -e pip_install_options="--force-reinstall" \ + setup-openstack.yml Note that if you wish to scope the upgrades to specific OpenStack components then each of the component playbooks may be executed and scoped using groups. For example: -.. code-block:: bash +1. Update only the Compute Hosts - # Update only the Compute Hosts - openstack-ansible -e pip_install_options="--force-reinstall" \ - os-nova-install.yml --limit nova_compute + .. code-block:: shell-session - # Update only a single Compute Host - # Skipping the 'nova-key' tag is necessary as the keys on all compute - # hosts will not be gathered. - openstack-ansible -e pip_install_options="--force-reinstall" \ - os-nova-install.yml --limit --skip-tags 'nova-key' + # openstack-ansible -e pip_install_options="--force-reinstall" \ + os-nova-install.yml --limit nova_compute + +2. Update only a single Compute Host (skipping the 'nova-key' tag is necessary as the keys on all compute hosts will not be gathered) + + .. code-block:: shell-session + + # openstack-ansible -e pip_install_options="--force-reinstall" \ + os-nova-install.yml --limit --skip-tags 'nova-key' If you wish to see which hosts belong to which groups, the ``inventory-manage.py`` script will show all groups and their hosts. For example: -.. code-block:: bash +1. Change directory into the repository clone root directory - # Change directory into the repository clone root directory - cd /opt/openstack-ansible + .. code-block:: shell-session - # Show all groups and which hosts belong to them - ./scripts/inventory-manage.py -G + # cd /opt/openstack-ansible - # Show all hosts and which groups they belong to - ./scripts/inventory-manage.py -g +2. Show all groups and which hosts belong to them + + .. code-block:: shell-session + + # ./scripts/inventory-manage.py -G + +3. Show all hosts and which groups they belong to + + .. code-block:: shell-session + + # ./scripts/inventory-manage.py -g You may also see which hosts a playbook will execute against, and which tasks will be executed: -.. code-block:: bash +1. Change directory into the repository clone playbooks directory - # Change directory into the repository clone playbooks directory - cd /opt/openstack-ansible/playbooks + .. code-block:: shell-session - # See the hosts in the nova_compute group which a playbook will execute - # against - openstack-ansible os-nova-install.yml --limit nova_compute --list-hosts + # cd /opt/openstack-ansible/playbooks - # See the tasks which will be executed on hosts in the nova_compute group - openstack-ansible os-nova-install.yml --limit nova_compute \ - --skip-tags 'nova-key' \ - --list-tasks +2. See the hosts in the nova_compute group which a playbook will execute against + + .. code-block:: shell-session + + # openstack-ansible os-nova-install.yml --limit nova_compute \ + --list-hosts + +3. See the tasks which will be executed on hosts in the nova_compute group + + .. code-block:: shell-session + + # openstack-ansible os-nova-install.yml --limit nova_compute \ + --skip-tags 'nova-key' \ + --list-tasks -------------- diff --git a/doc/source/install-guide/app-tips.rst b/doc/source/install-guide/app-tips.rst index 0db32d7961..a3e0ec5df0 100644 --- a/doc/source/install-guide/app-tips.rst +++ b/doc/source/install-guide/app-tips.rst @@ -16,9 +16,9 @@ entry in ``ansible.cfg``, or for a particular playbook execution by using the ``--forks`` CLI parameter. For example, to execute the ``os-keystone-install.yml`` playbook using 10 forks: -.. code-block:: bash +.. code-block:: shell-session - openstack-ansible --forks 10 os-keystone-install.yml + # openstack-ansible --forks 10 os-keystone-install.yml .. _forks: http://docs.ansible.com/ansible/intro_configuration.html#forks diff --git a/doc/source/install-guide/configure-aodh.rst b/doc/source/install-guide/configure-aodh.rst index 78184a9d36..36f218f854 100644 --- a/doc/source/install-guide/configure-aodh.rst +++ b/doc/source/install-guide/configure-aodh.rst @@ -11,7 +11,7 @@ The Alarming services of the Telemetry perform the following functions: Aodh on OSA requires a monogodb backend to be configured prior to running the aodh playbooks. The connection data will then need to be given in the ``user_variables.yml`` -file(See section Configuring User Data below). +file (see section `Configuring the user data`_ below). Setting up a Mongodb database for Aodh @@ -19,51 +19,55 @@ Setting up a Mongodb database for Aodh 1. Install the MongoDB package: - .. code-block:: shell + .. code-block:: shell-session - apt-get install mongodb-server mongodb-clients python-pymongo + # apt-get install mongodb-server mongodb-clients python-pymongo 2. Edit the ``/etc/mongodb.conf`` file and change the bind_ip to the management interface of the node your running this on. - .. code-block:: shell + .. code-block:: shell-session bind_ip = 10.0.0.11 3. Edit the ``/etc/mongodb.conf`` file and enable smallfiles - .. code-block:: shell + .. code-block:: shell-session smallfiles = true 4. Restart the mongodb service - .. code-block:: shell + .. code-block:: shell-session - service mongodb restart + # service mongodb restart 5. Create the aodh database - .. code-block:: shell + .. code-block:: shell-session - # mongo --host controller --eval ' + # mongo --host controller --eval ' db = db.getSiblingDB("aodh"); db.addUser({user: "aodh", pwd: "AODH_DBPASS", roles: [ "readWrite", "dbAdmin" ]})' - MongoDB shell version: 2.4.x - connecting to: controller:27017/test - { - "user" : "aodh", - "pwd" : "72f25aeee7ad4be52437d7cd3fc60f6f", - "roles" : [ - "readWrite", - "dbAdmin" - ], - "_id" : ObjectId("5489c22270d7fad1ba631dc3") - } + This should return: -NOTE: The ``AODH_DBPASS`` must match the ``aodh_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This is how ansible knows how to configure the connection string within the aodh configuration files. + .. code-block:: shell-session + + MongoDB shell version: 2.4.x + connecting to: controller:27017/test + { + "user" : "aodh", + "pwd" : "72f25aeee7ad4be52437d7cd3fc60f6f", + "roles" : [ + "readWrite", + "dbAdmin" + ], + "_id" : ObjectId("5489c22270d7fad1ba631dc3") + } + + NOTE: The ``AODH_DBPASS`` must match the ``aodh_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This is how ansible knows how to configure the connection string within the aodh configuration files. Configuring the hosts ##################### diff --git a/doc/source/install-guide/configure-ceilometer.rst b/doc/source/install-guide/configure-ceilometer.rst index c937c23369..4427201fc5 100644 --- a/doc/source/install-guide/configure-ceilometer.rst +++ b/doc/source/install-guide/configure-ceilometer.rst @@ -19,7 +19,7 @@ The Telemetry module(Ceilometer) performs the following functions: Ceilometer on OSA requires a monogodb backend to be configured prior to running the ceilometer playbooks. The connection data will then need to be given in the ``user_variables.yml`` -file(See section Configuring User Data below). +file (see section `Configuring the user data`_ below). Setting up a Mongodb database for ceilometer @@ -27,51 +27,55 @@ Setting up a Mongodb database for ceilometer 1. Install the MongoDB package: - .. code-block:: shell + .. code-block:: shell-session - apt-get install mongodb-server mongodb-clients python-pymongo + # apt-get install mongodb-server mongodb-clients python-pymongo 2. Edit the ``/etc/mongodb.conf`` file and change the bind_ip to the management interface of the node your running this on. - .. code-block:: shell + .. code-block:: shell-session bind_ip = 10.0.0.11 3. Edit the ``/etc/mongodb.conf`` file and enable smallfiles - .. code-block:: shell + .. code-block:: shell-session smallfiles = true 4. Restart the mongodb service - .. code-block:: shell + .. code-block:: shell-session - service mongodb restart + # service mongodb restart 5. Create the ceilometer database - .. code-block:: shell + .. code-block:: shell-session - # mongo --host controller --eval ' + # mongo --host controller --eval ' db = db.getSiblingDB("ceilometer"); db.addUser({user: "ceilometer", pwd: "CEILOMETER_DBPASS", roles: [ "readWrite", "dbAdmin" ]})' - MongoDB shell version: 2.4.x - connecting to: controller:27017/test - { - "user" : "ceilometer", - "pwd" : "72f25aeee7ad4be52437d7cd3fc60f6f", - "roles" : [ - "readWrite", - "dbAdmin" - ], - "_id" : ObjectId("5489c22270d7fad1ba631dc3") - } + This should return: -NOTE: The ``CEILOMETER_DBPASS`` must match the ``ceilometer_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This is how ansible knows how to configure the connection string within the ceilometer configuration files. + .. code-block:: shell-session + + MongoDB shell version: 2.4.x + connecting to: controller:27017/test + { + "user" : "ceilometer", + "pwd" : "72f25aeee7ad4be52437d7cd3fc60f6f", + "roles" : [ + "readWrite", + "dbAdmin" + ], + "_id" : ObjectId("5489c22270d7fad1ba631dc3") + } + + NOTE: The ``CEILOMETER_DBPASS`` must match the ``ceilometer_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This is how ansible knows how to configure the connection string within the ceilometer configuration files. Configuring the hosts ##################### diff --git a/doc/source/install-guide/configure-cinder-az.rst b/doc/source/install-guide/configure-cinder-az.rst index c8769622f7..1eb3fc460f 100644 --- a/doc/source/install-guide/configure-cinder-az.rst +++ b/doc/source/install-guide/configure-cinder-az.rst @@ -16,8 +16,8 @@ availability zones. cinder_storage_availability_zone: CINDERAZ - Replace *``CINDERAZ``* with a suitable name. For example - *``cinderAZ_2``* + Replace ``CINDERAZ`` with a suitable name. For example + ``cinderAZ_2`` #. If more than one availability zone is created, configure the default availability zone for all the hosts by creating a @@ -28,8 +28,8 @@ availability zones. cinder_default_availability_zone: CINDERAZ_DEFAULT - Replace *``CINDERAZ_DEFAULT``* with a suitable name. For example, - *``cinderAZ_1``*. The default availability zone should be the same + Replace ``CINDERAZ_DEFAULT`` with a suitable name. For example, + ``cinderAZ_1``. The default availability zone should be the same for all cinder hosts. If the ``cinder_default_availability_zone`` is not defined, the diff --git a/doc/source/install-guide/configure-cinder-backup.rst b/doc/source/install-guide/configure-cinder-backup.rst index 98be9c8aa7..5976e7bdf2 100644 --- a/doc/source/install-guide/configure-cinder-backup.rst +++ b/doc/source/install-guide/configure-cinder-backup.rst @@ -14,7 +14,7 @@ back up to an external Object Storage installation. ``/etc/openstack_deploy/user_variables.yml`` file and set the value to ``True``: - .. code-block:: bash + .. code-block:: yaml cinder_service_backup_program_enabled: True @@ -27,7 +27,7 @@ back up to an external Object Storage installation. following variables to the ``/etc/openstack_deploy/user_variables.yml`` file: - .. code-block:: bash + .. code-block:: yaml ... cinder_service_backup_swift_auth: per_user diff --git a/doc/source/install-guide/configure-cinder-nfs.rst b/doc/source/install-guide/configure-cinder-nfs.rst index b2999ecfda..f1e3aa55a8 100644 --- a/doc/source/install-guide/configure-cinder-nfs.rst +++ b/doc/source/install-guide/configure-cinder-nfs.rst @@ -7,25 +7,25 @@ If the NetApp back end is configured to use an NFS storage protocol, edit ``/etc/openstack_deploy/openstack_user_config.yml``, and configure the NFS client on each storage node that will use it. -#. Add the *``cinder_backends``* stanza (which includes - *``cinder_nfs_client``*) under the *``container_vars``* stanza for +#. Add the ``cinder_backends`` stanza (which includes + ``cinder_nfs_client``) under the ``container_vars`` stanza for each storage node: .. code-block:: yaml container_vars: cinder_backends: - cinder_nfs_client: + cinder_nfs_client: #. Configure the location of the file that lists shares available to the block storage service. This configuration file must include - *``nfs_shares_config``*: + ``nfs_shares_config``: .. code-block:: yaml nfs_shares_config: SHARE_CONFIG - Replace *``SHARE_CONFIG``* with the location of the share + Replace ``SHARE_CONFIG`` with the location of the share configuration file. For example, ``/etc/cinder/nfs_shares``. #. Configure one or more NFS shares: @@ -35,8 +35,8 @@ the NFS client on each storage node that will use it. shares: - { ip: "NFS_HOST", share: "NFS_SHARE" } - Replace *``NFS_HOST``* with the IP address or hostname of the NFS - server, and the *``NFS_SHARE``* with the absolute path to an existing + Replace ``NFS_HOST`` with the IP address or hostname of the NFS + server, and the ``NFS_SHARE`` with the absolute path to an existing and accessible NFS share. -------------- diff --git a/doc/source/install-guide/configure-cinder.rst b/doc/source/install-guide/configure-cinder.rst index 77224735b8..a3c813d6c0 100644 --- a/doc/source/install-guide/configure-cinder.rst +++ b/doc/source/install-guide/configure-cinder.rst @@ -43,7 +43,7 @@ Ensure that the NAS Team enables httpd.admin.access. netapp_storage_family: STORAGE_FAMILY - Replace *``STORAGE_FAMILY``* with ``ontap_7mode`` for Data ONTAP + Replace ``STORAGE_FAMILY`` with ``ontap_7mode`` for Data ONTAP operating in 7-mode or ``ontap_cluster`` for Data ONTAP operating as a cluster. @@ -53,7 +53,7 @@ Ensure that the NAS Team enables httpd.admin.access. netapp_storage_protocol: STORAGE_PROTOCOL - Replace *``STORAGE_PROTOCOL``* with ``iscsi`` for iSCSI or ``nfs`` + Replace ``STORAGE_PROTOCOL`` with ``iscsi`` for iSCSI or ``nfs`` for NFS. For the NFS protocol, you must also specify the location of the @@ -64,7 +64,7 @@ Ensure that the NAS Team enables httpd.admin.access. nfs_shares_config: SHARE_CONFIG - Replace *``SHARE_CONFIG``* with the location of the share + Replace ``SHARE_CONFIG`` with the location of the share configuration file. For example, ``/etc/cinder/nfs_shares``. #. Configure the server: @@ -73,7 +73,7 @@ Ensure that the NAS Team enables httpd.admin.access. netapp_server_hostname: SERVER_HOSTNAME - Replace *``SERVER_HOSTNAME``* with the hostnames for both netapp + Replace ``SERVER_HOSTNAME`` with the hostnames for both netapp controllers. #. Configure the server API port: @@ -82,7 +82,7 @@ Ensure that the NAS Team enables httpd.admin.access. netapp_server_port: PORT_NUMBER - Replace *``PORT_NUMBER``* with 80 for HTTP or 443 for HTTPS. + Replace ``PORT_NUMBER`` with 80 for HTTP or 443 for HTTPS. #. Configure the server credentials: @@ -91,7 +91,7 @@ Ensure that the NAS Team enables httpd.admin.access. netapp_login: USER_NAME netapp_password: PASSWORD - Replace *``USER_NAME``* and *``PASSWORD``* with the appropriate + Replace ``USER_NAME`` and ``PASSWORD`` with the appropriate values. #. Select the NetApp driver: @@ -106,7 +106,7 @@ Ensure that the NAS Team enables httpd.admin.access. volume_backend_name: BACKEND_NAME - Replace *``BACKEND_NAME``* with a suitable value that provides a hint + Replace ``BACKEND_NAME`` with a suitable value that provides a hint for the Block Storage scheduler. For example, ``NETAPP_iSCSI``. #. Check that the ``openstack_user_config.yml`` configuration is @@ -130,10 +130,10 @@ Ensure that the NAS Team enables httpd.admin.access. volume_driver: cinder.volume.drivers.netapp.common.NetAppDriver volume_backend_name: NETAPP_NFS - For *``netapp_server_hostname``*, specify the IP address of the Data + For ``netapp_server_hostname``, specify the IP address of the Data ONTAP server. Include iSCSI or NFS for the - *``netapp_storage_family``* depending on the configuration. Add 80 if - using HTTP or 443 if using HTTPS for *``netapp_server_port``*. + ``netapp_storage_family`` depending on the configuration. Add 80 if + using HTTP or 443 if using HTTPS for ``netapp_server_port``. The ``cinder-volume.yml`` playbook will automatically install the ``nfs-common`` file across the hosts, transitioning from an LVM to a diff --git a/doc/source/install-guide/configure-configurationintegrity.rst b/doc/source/install-guide/configure-configurationintegrity.rst index 2c131b75bf..c080871f48 100644 --- a/doc/source/install-guide/configure-configurationintegrity.rst +++ b/doc/source/install-guide/configure-configurationintegrity.rst @@ -16,9 +16,9 @@ Here are a few steps to execute before running any playbook: #. Run your command with syntax-check, for example, in the playbooks directory: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible setup-infrastructure.yml --syntax-check + # openstack-ansible setup-infrastructure.yml --syntax-check #. Recheck that all indentation seems correct: the syntax of the configuration files can be correct while not being meaningful diff --git a/doc/source/install-guide/configure-creds.rst b/doc/source/install-guide/configure-creds.rst index 90a38592fc..cce54d64cc 100644 --- a/doc/source/install-guide/configure-creds.rst +++ b/doc/source/install-guide/configure-creds.rst @@ -23,11 +23,10 @@ interfaces: Recommended: Use the ``pw-token-gen.py`` script to generate random values for the variables in each file that contains service credentials: -.. code-block:: bash +.. code-block:: shell-session - $ cd /opt/openstack-ansible/scripts - $ python pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml - + # cd /opt/openstack-ansible/scripts + # python pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml To regenerate existing passwords, add the ``--regen`` flag. diff --git a/doc/source/install-guide/configure-federation-mapping.rst b/doc/source/install-guide/configure-federation-mapping.rst index 1337089eb2..e72d829c8f 100644 --- a/doc/source/install-guide/configure-federation-mapping.rst +++ b/doc/source/install-guide/configure-federation-mapping.rst @@ -34,7 +34,7 @@ Each IdP trusted by an SP must have the following configuration: With the above information, Ansible implements the equivalent of the following OpenStack CLI commands: -.. code-block:: shell +.. code-block:: shell-session # if the domain does not already exist openstack domain create Default @@ -112,7 +112,7 @@ The ``mapping`` dictionary is a yaml representation very similar to the keystone mapping property which Ansible uploads. The above mapping produces the following in keystone. -.. code-block:: shell +.. code-block:: shell-session root@aio1_keystone_container-783aa4c0:~# openstack mapping list +------------------+ diff --git a/doc/source/install-guide/configure-federation-wrapper.rst b/doc/source/install-guide/configure-federation-wrapper.rst index 1837bd0c1a..af04ccda6f 100644 --- a/doc/source/install-guide/configure-federation-wrapper.rst +++ b/doc/source/install-guide/configure-federation-wrapper.rst @@ -38,14 +38,14 @@ The K2K authentication flow involves the following steps: Identity Service to Identity Service federation authentication wrapper ---------------------------------------------------------------------- -Unfortunately, many of the steps above involve manually sending API requests. +Unfortunately, many of the steps above involve manually sending API requests. The infrastructure for the command line utilities to perform all these steps for the user does not yet exist. To simplify the task of obtaining access to a SP cloud, OpenStack Ansible provides a script that wraps the above steps. The script is called ``federated-login.sh`` and is used as follows:: - ./federated-login.sh -p project [-d domain] sp_id + # ./scripts/federated-login.sh -p project [-d domain] sp_id Where ``project`` is the project in the SP cloud that the user wants to access, ``domain`` is the domain in which the project lives (the default domain is @@ -59,13 +59,13 @@ and the scoped token provided by the SP. The endpoints and token can be used with the openstack command line client as follows:: - $ openstack --os-token= --os-url= [options] + # openstack --os-token= --os-url= [options] or alternatively:: - $ export OS_TOKEN= - $ export OS_URL= - $ openstack [options] + # export OS_TOKEN= + # export OS_URL= + # openstack [options] The user must select the appropriate endpoint for the desired operation. For example, if the user wants to work with servers, the ``OS_URL`` diff --git a/doc/source/install-guide/configure-glance.rst b/doc/source/install-guide/configure-glance.rst index f1e2de196c..91ff4ad948 100644 --- a/doc/source/install-guide/configure-glance.rst +++ b/doc/source/install-guide/configure-glance.rst @@ -5,7 +5,7 @@ Configuring the Image service In an all-in-one deployment with a single infrastructure node, the Image service uses the local file system on the target host to store images. -When deploying production clouds we recommend backing Glance with a +When deploying production clouds we recommend backing Glance with a swift backend or some form or another of shared storage. The following procedure describes how to modify the @@ -33,8 +33,8 @@ usage. glance_swift_store_user: GLANCE_SWIFT_TENANT:GLANCE_SWIFT_USER glance_swift_store_key: SWIFT_PASSWORD_OR_KEY -#. Change the *``glance_swift_store_endpoint_type``* from the default - *``internalURL``* settings to *``publicURL``* if needed. +#. Change the ``glance_swift_store_endpoint_type`` from the default + ``internalURL`` settings to ``publicURL`` if needed. .. code-block:: yaml @@ -46,7 +46,7 @@ usage. glance_swift_store_container: STORE_NAME - Replace *``STORE_NAME``* with the container name in swift to be + Replace ``STORE_NAME`` with the container name in swift to be used for storing images. If the container doesn't exist, it will be automatically created. @@ -56,14 +56,13 @@ usage. glance_swift_store_region: STORE_REGION - Replace *``STORE_REGION``* if needed. + Replace ``STORE_REGION`` if needed. #. (Optional) Set the paste deploy flavor: .. code-block:: yaml glance_flavor: GLANCE_FLAVOR - By default, the Image service uses caching and authenticates with the Identity service. The default maximum size of the image cache is 10 @@ -71,25 +70,25 @@ usage. configurations, the Image service might attempt to cache an image which exceeds the available disk space. If necessary, you can disable caching. For example, to use Identity without caching, replace - *``GLANCE_FLAVOR``* with ``keystone``: + ``GLANCE_FLAVOR`` with ``keystone``: .. code-block:: yaml glance_flavor: keystone Or, to disable both authentication and caching, set - *``GLANCE_FLAVOR``* to no value: + ``GLANCE_FLAVOR`` to no value: .. code-block:: yaml - glance_flavor: + glance_flavor: This option is set by default to use authentication and cache management in the ``playbooks/roles/os_glance/defaults/main.yml`` file. To override the default behavior, set ``glance_flavor`` to a different value in ``/etc/openstack_deploy/user_variables.yml``. - The possible values for *``GLANCE_FLAVOR``* are: + The possible values for ``GLANCE_FLAVOR`` are: - (Nothing) diff --git a/doc/source/install-guide/configure-networking.rst b/doc/source/install-guide/configure-networking.rst index 422940b38d..630c78aa25 100644 --- a/doc/source/install-guide/configure-networking.rst +++ b/doc/source/install-guide/configure-networking.rst @@ -20,13 +20,13 @@ configure target host networking. #Storage (same range as br-storage on the target hosts) storage: STORAGE_CIDR - Replace *``*_CIDR``* with the appropriate IP address range in CIDR + Replace ``*_CIDR`` with the appropriate IP address range in CIDR notation. For example, 203.0.113.0/24. Use the same IP address ranges as the underlying physical network interfaces or bridges configured in `the section called "Configuring the network" `_. For example, if the - container network uses 203.0.113.0/24, the *``CONTAINER_MGMT_CIDR``* + container network uses 203.0.113.0/24, the ``CONTAINER_MGMT_CIDR`` should also use 203.0.113.0/24. The default configuration includes the optional storage and service @@ -40,7 +40,7 @@ configure target host networking. used_ips: - EXISTING_IP_ADDRESSES - Replace *``EXISTING_IP_ADDRESSES``* with a list of existing IP + Replace ``EXISTING_IP_ADDRESSES`` with a list of existing IP addresses in the ranges defined in the previous step. This list should include all IP addresses manually configured on target hosts in the `the section called "Configuring the @@ -79,18 +79,18 @@ configure target host networking. # Tunnel network bridge device tunnel_bridge: "TUNNEL_BRIDGE" - Replace *``INTERNAL_LB_VIP_ADDRESS``* with the internal IP address of + Replace ``INTERNAL_LB_VIP_ADDRESS`` with the internal IP address of the load balancer. Infrastructure and OpenStack services use this IP address for internal communication. - Replace *``EXTERNAL_LB_VIP_ADDRESS``* with the external, public, or + Replace ``EXTERNAL_LB_VIP_ADDRESS`` with the external, public, or DMZ IP address of the load balancer. Users primarily use this IP address for external API and web interfaces access. - Replace *``MGMT_BRIDGE``* with the container bridge device name, + Replace ``MGMT_BRIDGE`` with the container bridge device name, typically ``br-mgmt``. - Replace *``TUNNEL_BRIDGE``* with the tunnel/overlay bridge device + Replace ``TUNNEL_BRIDGE`` with the tunnel/overlay bridge device name, typically ``br-vxlan``. #. Configure the management network in the ``provider_networks`` subsection: @@ -149,7 +149,7 @@ configure target host networking. range: "TUNNEL_ID_RANGE" net_name: "vxlan" - Replace *``TUNNEL_ID_RANGE``* with the tunnel ID range. For example, + Replace ``TUNNEL_ID_RANGE`` with the tunnel ID range. For example, 1:1000. #. Configure OpenStack Networking flat (untagged) and VLAN (tagged) networks @@ -177,7 +177,7 @@ configure target host networking. range: VLAN_ID_RANGE net_name: "vlan" - Replace *``VLAN_ID_RANGE``* with the VLAN ID range for each VLAN network. + Replace ``VLAN_ID_RANGE`` with the VLAN ID range for each VLAN network. For example, 1:1000. Supports more than one range of VLANs on a particular network. For example, 1:1000,2001:3000. Create a similar stanza for each additional network. @@ -210,7 +210,7 @@ configure target host networking. ``/etc/network/interfaces.d/eth2.cfg`` file in the appropriate containers: - .. code-block:: shell + .. code-block:: shell-session post-up ip route add 10.176.0.0/12 via 172.29.248.1 || true diff --git a/doc/source/install-guide/configure-sslcertificates.rst b/doc/source/install-guide/configure-sslcertificates.rst index 90ace67d51..86a1b612ef 100644 --- a/doc/source/install-guide/configure-sslcertificates.rst +++ b/doc/source/install-guide/configure-sslcertificates.rst @@ -70,9 +70,9 @@ certificates unless the user sets ``_ssl_self_signed_regen`` to To force a self-signed certificate to regenerate you can pass the variable to ``openstack-ansible`` on the command line: -.. code-block:: bash +.. code-block:: shell-session - openstack-ansible -e "horizon_ssl_self_signed_regen=true" os-horizon-install.yml + # openstack-ansible -e "horizon_ssl_self_signed_regen=true" os-horizon-install.yml To force a self-signed certificate to regenerate **with every playbook run**, simply set the appropriate regeneration option to ``true``. For example, if @@ -120,9 +120,9 @@ variables: Simply run the playbook to apply the certificates: -.. code-block:: bash +.. code-block:: shell-session - openstack-ansible rabbitmq-install.yml + # openstack-ansible rabbitmq-install.yml The playbook will deploy your user-provided SSL certificate, key, and CA certificate to each RabbitMQ container. diff --git a/doc/source/install-guide/configure-swift-add.rst b/doc/source/install-guide/configure-swift-add.rst index fc85425a5b..a8bc96e713 100644 --- a/doc/source/install-guide/configure-swift-add.rst +++ b/doc/source/install-guide/configure-swift-add.rst @@ -28,11 +28,10 @@ existing deployment. #. Run the Object Storage play: - .. code-block:: bash + .. code-block:: shell-session - $ cd /opt/openstack-ansible/playbooks - $ openstack-ansible os-swift-install.yml - + # cd /opt/openstack-ansible/playbooks + # openstack-ansible os-swift-install.yml -------------- diff --git a/doc/source/install-guide/configure-swift-config.rst b/doc/source/install-guide/configure-swift-config.rst index d943829585..ede4d040f5 100644 --- a/doc/source/install-guide/configure-swift-config.rst +++ b/doc/source/install-guide/configure-swift-config.rst @@ -9,10 +9,10 @@ file** #. Copy the ``/etc/openstack_deploy/conf.d/swift.yml.example`` file to ``/etc/openstack_deploy/conf.d/swift.yml``: - .. code-block:: bash + .. code-block:: shell-session - #cp /etc/openstack_deploy/conf.d/swift.yml.example \ - /etc/openstack_deploy/conf.d/swift.yml + # cp /etc/openstack_deploy/conf.d/swift.yml.example \ + /etc/openstack_deploy/conf.d/swift.yml #. Update the global override values: diff --git a/doc/source/install-guide/configure-swift-devices.rst b/doc/source/install-guide/configure-swift-devices.rst index b1ca245722..9f6f6ae0a7 100644 --- a/doc/source/install-guide/configure-swift-devices.rst +++ b/doc/source/install-guide/configure-swift-devices.rst @@ -26,53 +26,47 @@ through ``sdg``. For example, create the file systems on the devices using the **mkfs** command - .. code-block:: bash + .. code-block:: shell-session - $ apt-get install xfsprogs - - $ mkfs.xfs -f -i size=1024 -L sdc /dev/sdc - $ mkfs.xfs -f -i size=1024 -L sdd /dev/sdd - $ mkfs.xfs -f -i size=1024 -L sde /dev/sde - $ mkfs.xfs -f -i size=1024 -L sdf /dev/sdf - $ mkfs.xfs -f -i size=1024 -L sdg /dev/sdg + # apt-get install xfsprogs + # mkfs.xfs -f -i size=1024 -L sdc /dev/sdc + # mkfs.xfs -f -i size=1024 -L sdd /dev/sdd + # mkfs.xfs -f -i size=1024 -L sde /dev/sde + # mkfs.xfs -f -i size=1024 -L sdf /dev/sdf + # mkfs.xfs -f -i size=1024 -L sdg /dev/sdg #. Add the mount locations to the ``fstab`` file so that the storage devices are remounted on boot. The following example mount options are recommended when using XFS. - .. code-block:: bash + .. code-block:: shell-session - $ LABEL=sdc /srv/node/sdc xfs noatime,nodiratime, \ - nobarrier,logbufs=8,noauto 0 0 - $ LABEL=sdd /srv/node/sdd xfs noatime,nodiratime, \ - nobarrier,logbufs=8,noauto 0 0 - $ LABEL=sde /srv/node/sde xfs noatime,nodiratime, \ - nobarrier,logbufs=8,noauto 0 0 - $ LABEL=sdf /srv/node/sdf xfs noatime,nodiratime, \ - nobarrier,logbufs=8,noauto 0 0 - $ LABEL=sdg /srv/node/sdg xfs noatime,nodiratime, \ - nobarrier,logbufs=8,noauto 0 0 + LABEL=sdc /srv/node/sdc xfs noatime,nodiratime,nobarrier,logbufs=8,noauto 0 0 + LABEL=sdd /srv/node/sdd xfs noatime,nodiratime,nobarrier,logbufs=8,noauto 0 0 + LABEL=sde /srv/node/sde xfs noatime,nodiratime,nobarrier,logbufs=8,noauto 0 0 + LABEL=sdf /srv/node/sdf xfs noatime,nodiratime,nobarrier,logbufs=8,noauto 0 0 + LABEL=sdg /srv/node/sdg xfs noatime,nodiratime,nobarrier,logbufs=8,noauto 0 0 #. Create the mount points for the devices using the **mkdir** command. - .. code-block:: bash + .. code-block:: shell-session - $ mkdir -p /srv/node/sdc - $ mkdir -p /srv/node/sdd - $ mkdir -p /srv/node/sde - $ mkdir -p /srv/node/sdf - $ mkdir -p /srv/node/sdg + # mkdir -p /srv/node/sdc + # mkdir -p /srv/node/sdd + # mkdir -p /srv/node/sde + # mkdir -p /srv/node/sdf + # mkdir -p /srv/node/sdg - The mount point is referenced as the ``mount_point``\ parameter in + The mount point is referenced as the ``mount_point`` parameter in the ``swift.yml`` file (``/etc/rpc_deploy/conf.d/swift.yml``). - .. code-block:: bash + .. code-block:: shell-session - $ mount /srv/node/sdc - $ mount /srv/node/sdd - $ mount /srv/node/sde - $ mount /srv/node/sdf - $ mount /srv/node/sdg + # mount /srv/node/sdc + # mount /srv/node/sdd + # mount /srv/node/sde + # mount /srv/node/sdf + # mount /srv/node/sdg To view an annotated example of the ``swift.yml`` file, see `Appendix A, *OSA configuration files* `_. diff --git a/doc/source/install-guide/configure-swift-glance.rst b/doc/source/install-guide/configure-swift-glance.rst index 782827a31c..687443916b 100644 --- a/doc/source/install-guide/configure-swift-glance.rst +++ b/doc/source/install-guide/configure-swift-glance.rst @@ -60,10 +60,10 @@ This procedure requires the following: #. Run the Image Service (glance) playbook: - .. code-block:: bash + .. code-block:: shell-session - $ cd /opt/openstack-ansible/playbooks - $ openstack-ansible os-glance-install.yml --tags "glance-config" + # cd /opt/openstack-ansible/playbooks + # openstack-ansible os-glance-install.yml --tags "glance-config" -------------- diff --git a/doc/source/install-guide/configure-swift-policies.rst b/doc/source/install-guide/configure-swift-policies.rst index 130fae9e58..5715339828 100644 --- a/doc/source/install-guide/configure-swift-policies.rst +++ b/doc/source/install-guide/configure-swift-policies.rst @@ -38,10 +38,9 @@ cluster: policy groups) creates an empty ring for that storage policy. - A non-default storage policy is used only if specified when creating - a container, using the - ``X-Storage-Policy: `` header. After the - container is created, it uses the created storage policy. Other - containers continue using the default or another storage policy + a container, using the ``X-Storage-Policy: `` header. + After the container is created, it uses the created storage policy. + Other containers continue using the default or another storage policy specified when created. For more information about storage policies, see: `Storage diff --git a/doc/source/install-guide/configure-swift.rst b/doc/source/install-guide/configure-swift.rst index d1eafc6bf2..49ca261956 100644 --- a/doc/source/install-guide/configure-swift.rst +++ b/doc/source/install-guide/configure-swift.rst @@ -20,10 +20,10 @@ The following procedure describes how to set up storage devices and modify the Object Storage configuration files to enable Object Storage usage. -#. `the section called "Configure and mount storage +#. `The section called "Configure and mount storage devices" `_ -#. `the section called "Configure an Object Storage +#. `The section called "Configure an Object Storage deployment" `_ #. Optionally, allow all Identity users to use Object Storage by setting diff --git a/doc/source/install-guide/configure.rst b/doc/source/install-guide/configure.rst index 3f09893525..b68b67c5cf 100644 --- a/doc/source/install-guide/configure.rst +++ b/doc/source/install-guide/configure.rst @@ -17,6 +17,7 @@ Chapter 5. Deployment configuration configure-horizon.rst configure-rabbitmq.rst configure-ceilometer.rst + configure-aodh.rst configure-keystone.rst configure-openstack.rst configure-sslcertificates.rst diff --git a/doc/source/install-guide/deploymenthost-add.rst b/doc/source/install-guide/deploymenthost-add.rst index a1ee5dc9fd..88c61a7c74 100644 --- a/doc/source/install-guide/deploymenthost-add.rst +++ b/doc/source/install-guide/deploymenthost-add.rst @@ -8,11 +8,10 @@ Install additional software packages and configure NTP. #. Install additional software packages if not already installed during operating system installation: - .. code-block:: bash + .. code-block:: shell-session # apt-get install aptitude build-essential git ntp ntpdate \ openssh-server python-dev sudo - #. Configure NTP to synchronize with a suitable time source. diff --git a/doc/source/install-guide/deploymenthost-osa.rst b/doc/source/install-guide/deploymenthost-osa.rst index 6839f00233..e52256d183 100644 --- a/doc/source/install-guide/deploymenthost-osa.rst +++ b/doc/source/install-guide/deploymenthost-osa.rst @@ -8,17 +8,16 @@ Install the source and dependencies for the deployment host. #. Clone the OSA repository into the ``/opt/openstack-ansible`` directory: - .. code-block:: bash + .. code-block:: shell-session # git clone -b TAG https://github.com/openstack/openstack-ansible.git /opt/openstack-ansible - Replace *``TAG``* with the current stable release tag. #. Change to the ``/opt/openstack-ansible`` directory, and run the Ansible bootstrap script: - .. code-block:: bash + .. code-block:: shell-session # scripts/bootstrap-ansible.sh diff --git a/doc/source/install-guide/install-foundation-run.rst b/doc/source/install-guide/install-foundation-run.rst index 881d22d0cf..04d37c08dc 100644 --- a/doc/source/install-guide/install-foundation-run.rst +++ b/doc/source/install-guide/install-foundation-run.rst @@ -11,14 +11,14 @@ Running the foundation playbook #. Run the host setup playbook, which runs a series of sub-playbooks: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible setup-hosts.yml + # openstack-ansible setup-hosts.yml Confirm satisfactory completion with zero items unreachable or failed: - .. code-block:: bash + .. code-block:: shell-session PLAY RECAP ******************************************************************** ... @@ -33,21 +33,21 @@ Running the foundation playbook been downloaded during the bootstrap-ansible stage. If not, you should rerun the following command before running the haproxy playbook: - .. code-block:: shell + .. code-block:: shell-session - $ ../scripts/bootstrap-ansible.sh + # ../scripts/bootstrap-ansible.sh or - .. code-block:: shell + .. code-block:: shell-session - $ ansible-galaxy install -r ../ansible-role-requirements.yml + # ansible-galaxy install -r ../ansible-role-requirements.yml Run the playbook to deploy haproxy: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible haproxy-install.yml + # openstack-ansible haproxy-install.yml -------------- diff --git a/doc/source/install-guide/install-infrastructure-run.rst b/doc/source/install-guide/install-infrastructure-run.rst index 3d787ba41d..e1e00fac20 100644 --- a/doc/source/install-guide/install-infrastructure-run.rst +++ b/doc/source/install-guide/install-infrastructure-run.rst @@ -12,14 +12,14 @@ Running the infrastructure playbook #. Run the infrastructure setup playbook, which runs a series of sub-playbooks: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible setup-infrastructure.yml + # openstack-ansible setup-infrastructure.yml Confirm satisfactory completion with zero items unreachable or failed: - .. code-block:: bash + .. code-block:: shell-session PLAY RECAP ******************************************************************** ... diff --git a/doc/source/install-guide/install-infrastructure-verify.rst b/doc/source/install-guide/install-infrastructure-verify.rst index 556718bc10..e177cdf617 100644 --- a/doc/source/install-guide/install-infrastructure-verify.rst +++ b/doc/source/install-guide/install-infrastructure-verify.rst @@ -9,22 +9,22 @@ Verify the database cluster and Kibana web interface operation. #. Determine the Galera container name: - .. code-block:: bash + .. code-block:: shell-session - $ lxc-ls | grep galera + # lxc-ls | grep galera infra1_galera_container-4ed0d84a #. Access the Galera container: - .. code-block:: bash + .. code-block:: shell-session - $ lxc-attach -n infra1_galera_container-4ed0d84a + # lxc-attach -n infra1_galera_container-4ed0d84a #. Run the MariaDB client, show cluster status, and exit the client: - .. code-block:: bash + .. code-block:: shell-session - $ mysql -u root -p + # mysql -u root -p MariaDB> show status like 'wsrep_cluster%'; +--------------------------+--------------------------------------+ | Variable_name | Value | diff --git a/doc/source/install-guide/install-openstack-run.rst b/doc/source/install-guide/install-openstack-run.rst index 1bb6d67fb3..f080aa0056 100644 --- a/doc/source/install-guide/install-openstack-run.rst +++ b/doc/source/install-guide/install-openstack-run.rst @@ -8,9 +8,9 @@ Running the OpenStack playbook #. Run the OpenStack setup playbook, which runs a series of sub-playbooks: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible setup-openstack.yml + # openstack-ansible setup-openstack.yml The openstack-common.yml sub-playbook builds all OpenStack services from source and takes up to 30 minutes to complete. As the playbook @@ -18,7 +18,7 @@ Running the OpenStack playbook approach zero. If any operations take longer than 30 minutes to complete, the playbook will terminate with an error. - .. code-block:: bash + .. code-block:: shell-session changed: [target_host_glance_container-f2ebdc06] changed: [target_host_heat_engine_container-36022446] @@ -53,7 +53,7 @@ Running the OpenStack playbook approach zero. If any operations take longer than 30 minutes to complete, the playbook will terminate with an error. - .. code-block:: bash + .. code-block:: shell-session ok: [target_host_nova_conductor_container-2b495dc4] ok: [target_host_nova_api_metadata_container-600fe8b3] @@ -70,7 +70,7 @@ Running the OpenStack playbook Confirm satisfactory completion with zero items unreachable or failed: - .. code-block:: bash + .. code-block:: shell-session PLAY RECAP ********************************************************************** ... diff --git a/doc/source/install-guide/install-openstack-verify.rst b/doc/source/install-guide/install-openstack-verify.rst index 89e271c552..0d4d16924e 100644 --- a/doc/source/install-guide/install-openstack-verify.rst +++ b/doc/source/install-guide/install-openstack-verify.rst @@ -5,7 +5,6 @@ Verifying OpenStack operation Verify basic operation of the OpenStack API and dashboard. -  **Procedure 8.1. Verifying the API** @@ -14,28 +13,28 @@ configuration and testing. #. Determine the utility container name: - .. code-block:: bash + .. code-block:: shell-session - $ lxc-ls | grep utility + # lxc-ls | grep utility infra1_utility_container-161a4084 #. Access the utility container: - .. code-block:: bash + .. code-block:: shell-session - $ lxc-attach -n infra1_utility_container-161a4084 + # lxc-attach -n infra1_utility_container-161a4084 #. Source the ``admin`` tenant credentials: - .. code-block:: bash + .. code-block:: shell-session - $ source openrc + # source openrc #. Run an OpenStack command that uses one or more APIs. For example: - .. code-block:: bash + .. code-block:: shell-session - $ keystone user-list + # keystone user-list +----------------------------------+----------+---------+-------+ | id | name | enabled | email | +----------------------------------+----------+---------+-------+ diff --git a/doc/source/install-guide/ops-addcomputehost.rst b/doc/source/install-guide/ops-addcomputehost.rst index ce4436d828..2dab08573c 100644 --- a/doc/source/install-guide/ops-addcomputehost.rst +++ b/doc/source/install-guide/ops-addcomputehost.rst @@ -17,10 +17,10 @@ cluster. #. Run the following commands to add the host. Replace ``NEW_HOST_NAME`` with the name of the new host. - .. code-block:: bash + .. code-block:: shell-session - $ cd /opt/openstack-ansible/playbooks - $ openstack-ansible setup-everything.yml --limit NEW_HOST_NAME + # cd /opt/openstack-ansible/playbooks + # openstack-ansible setup-everything.yml --limit NEW_HOST_NAME -------------- diff --git a/doc/source/install-guide/ops-galera-recovery.rst b/doc/source/install-guide/ops-galera-recovery.rst index c251b9d33b..7290d50752 100644 --- a/doc/source/install-guide/ops-galera-recovery.rst +++ b/doc/source/install-guide/ops-galera-recovery.rst @@ -3,20 +3,20 @@ Galera cluster recovery ----------------------- -When one or all nodes fail within a galera cluster you may need to -re-bootstrap the environment. To make take advantage of the +When one or all nodes fail within a galera cluster you may need to +re-bootstrap the environment. To make take advantage of the automation Ansible provides simply execute the ``galera-install.yml`` -play using the **galera-bootstrap** to auto recover a node or an +play using the **galera-bootstrap** to auto recover a node or an entire environment. #. Run the following Ansible command to show the failed nodes: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible galera-install --tags galera-bootstrap + # openstack-ansible galera-install --tags galera-bootstrap -Upon completion of this command the cluster should be back online an in +Upon completion of this command the cluster should be back online an in a functional state. diff --git a/doc/source/install-guide/ops-galera-recoverycomplete.rst b/doc/source/install-guide/ops-galera-recoverycomplete.rst index fdfda9cff5..ab6d23b7ae 100644 --- a/doc/source/install-guide/ops-galera-recoverycomplete.rst +++ b/doc/source/install-guide/ops-galera-recoverycomplete.rst @@ -8,9 +8,9 @@ gracefully), then the integrity of the database can no longer be guaranteed and should be restored from backup. Run the following command to determine if all nodes in the cluster have failed: -.. code-block:: bash +.. code-block:: shell-session - $ ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat" + # ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat" node3_galera_container-3ea2cbd3 | success | rc=0 >> # GALERA saved state version: 2.1 diff --git a/doc/source/install-guide/ops-galera-recoverycontainer.rst b/doc/source/install-guide/ops-galera-recoverycontainer.rst index 7fbc7bc3ad..366294d54c 100644 --- a/doc/source/install-guide/ops-galera-recoverycontainer.rst +++ b/doc/source/install-guide/ops-galera-recoverycontainer.rst @@ -16,19 +16,18 @@ containers. MariaDB data stored outside of the container. In this example, node 3 failed. - .. code-block:: bash + .. code-block:: shell-session - $ lxc-stop -n node3_galera_container-3ea2cbd3 - $ lxc-destroy -n node3_galera_container-3ea2cbd3 - $ rm -rf /openstack/node3_galera_container-3ea2cbd3/* - + # lxc-stop -n node3_galera_container-3ea2cbd3 + # lxc-destroy -n node3_galera_container-3ea2cbd3 + # rm -rf /openstack/node3_galera_container-3ea2cbd3/* #. Run the host setup playbook to rebuild the container specifically on node 3: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible setup-hosts.yml -l node3 \ + # openstack-ansible setup-hosts.yml -l node3 \ -l node3_galera_container-3ea2cbd3 @@ -37,9 +36,9 @@ containers. #. Run the infrastructure playbook to configure the container specifically on node 3: - .. code-block:: bash + .. code-block:: shell-session - $ openstack-ansible infrastructure-setup.yml \ + # openstack-ansible infrastructure-setup.yml \ -l node3_galera_container-3ea2cbd3 @@ -47,9 +46,9 @@ containers. state because the environment contains more than one active database with potentially different data. - .. code-block:: bash + .. code-block:: shell-session - $ ansible galera_container -m shell -a "mysql \ + # ansible galera_container -m shell -a "mysql \ -h localhost -e 'show status like \"%wsrep_cluster_%\";'" node3_galera_container-3ea2cbd3 | success | rc=0 >> Variable_name Value @@ -71,14 +70,13 @@ containers. wsrep_cluster_size 2 wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1 wsrep_cluster_status Primary - #. Restart MariaDB in the new container and verify that it rejoins the cluster. - .. code-block:: bash + .. code-block:: shell-session - $ ansible galera_container -m shell -a "mysql \ + # ansible galera_container -m shell -a "mysql \ -h localhost -e 'show status like \"%wsrep_cluster_%\";'" node2_galera_container-49a47d25 | success | rc=0 >> Variable_name Value diff --git a/doc/source/install-guide/ops-galera-recoverymulti.rst b/doc/source/install-guide/ops-galera-recoverymulti.rst index d8b7da2402..a544583b36 100644 --- a/doc/source/install-guide/ops-galera-recoverymulti.rst +++ b/doc/source/install-guide/ops-galera-recoverymulti.rst @@ -9,9 +9,9 @@ recover cannot join the cluster because it no longer exists. #. Run the following Ansible command to show the failed nodes: - .. code-block:: bash + .. code-block:: shell-session - $ ansible galera_container -m shell -a "mysql \ + # ansible galera_container -m shell -a "mysql \ -h localhost -e 'show status like \"%wsrep_cluster_%\";'" node2_galera_container-49a47d25 | FAILED | rc=1 >> ERROR 2002 (HY000): Can't connect to local MySQL server @@ -27,7 +27,6 @@ recover cannot join the cluster because it no longer exists. wsrep_cluster_size 1 wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1 wsrep_cluster_status non-Primary - In this example, nodes 2 and 3 have failed. The remaining operational server indicates ``non-Primary`` because it cannot achieve quorum. @@ -36,9 +35,9 @@ recover cannot join the cluster because it no longer exists. `rebootstrap `_ the operational node into the cluster. - .. code-block:: bash + .. code-block:: shell-session - $ mysql -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=yes';" + # mysql -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=yes';" node4_galera_container-76275635 | success | rc=0 >> Variable_name Value wsrep_cluster_conf_id 15 @@ -53,7 +52,6 @@ recover cannot join the cluster because it no longer exists. node2_galera_container-49a47d25 | FAILED | rc=1 >> ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) - The remaining operational node becomes the primary node and begins processing SQL requests. @@ -61,9 +59,9 @@ recover cannot join the cluster because it no longer exists. #. Restart MariaDB on the failed nodes and verify that they rejoin the cluster. - .. code-block:: bash + .. code-block:: shell-session - $ ansible galera_container -m shell -a "mysql \ + # ansible galera_container -m shell -a "mysql \ -h localhost -e 'show status like \"%wsrep_cluster_%\";'" node3_galera_container-3ea2cbd3 | success | rc=0 >> Variable_name Value @@ -85,7 +83,6 @@ recover cannot join the cluster because it no longer exists. wsrep_cluster_size 3 wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1 wsrep_cluster_status Primary - #. If MariaDB fails to start on any of the failed nodes, run the **mysqld** command and perform further analysis on the output. As a diff --git a/doc/source/install-guide/ops-galera-recoverysingle.rst b/doc/source/install-guide/ops-galera-recoverysingle.rst index f0819666e7..d25bf85c1f 100644 --- a/doc/source/install-guide/ops-galera-recoverysingle.rst +++ b/doc/source/install-guide/ops-galera-recoverysingle.rst @@ -8,10 +8,10 @@ process SQL requests. #. Run the following Ansible command to determine the failed node: - .. code-block:: bash + .. code-block:: shell-session - $ ansible galera_container -m shell -a "mysql -h localhost\ - -e 'show status like \"%wsrep_cluster_%\";'" + # ansible galera_container -m shell -a "mysql -h localhost \ + -e 'show status like \"%wsrep_cluster_%\";'" node3_galera_container-3ea2cbd3 | FAILED | rc=1 >> ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) diff --git a/doc/source/install-guide/ops-galera-remove.rst b/doc/source/install-guide/ops-galera-remove.rst index f69b8fd64a..6bfaca9a81 100644 --- a/doc/source/install-guide/ops-galera-remove.rst +++ b/doc/source/install-guide/ops-galera-remove.rst @@ -5,10 +5,10 @@ Removing nodes In the following example, all but one node was shut down gracefully: -.. code-block:: bash +.. code-block:: shell-session - $ ansible galera_container -m shell -a "mysql -h localhost\ - -e 'show status like \"%wsrep_cluster_%\";'" + # ansible galera_container -m shell -a "mysql -h localhost \ + -e 'show status like \"%wsrep_cluster_%\";'" node3_galera_container-3ea2cbd3 | FAILED | rc=1 >> ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) diff --git a/doc/source/install-guide/ops-galera-start.rst b/doc/source/install-guide/ops-galera-start.rst index 573172110b..160e17c6c4 100644 --- a/doc/source/install-guide/ops-galera-start.rst +++ b/doc/source/install-guide/ops-galera-start.rst @@ -11,9 +11,9 @@ one of the nodes. following command to check the ``seqno`` value in the ``grastate.dat`` file on all of the nodes: - .. code-block:: bash + .. code-block:: shell-session - $ ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat" + # ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat" node2_galera_container-49a47d25 | success | rc=0 >> # GALERA saved state version: 2.1 uuid: 338b06b0-2948-11e4-9d06-bef42f6c52f1 @@ -31,23 +31,21 @@ one of the nodes. uuid: 338b06b0-2948-11e4-9d06-bef42f6c52f1 seqno: 31 cert_index: - In this example, all nodes in the cluster contain the same positive ``seqno`` values because they were synchronized just prior to graceful shutdown. If all ``seqno`` values are equal, any node can start the new cluster. - .. code-block:: bash + .. code-block:: shell-session - $ /etc/init.d/mysql start --wsrep-new-cluster - + # /etc/init.d/mysql start --wsrep-new-cluster This command results in a cluster containing a single node. The ``wsrep_cluster_size`` value shows the number of nodes in the cluster. - .. code-block:: bash + .. code-block:: shell-session node2_galera_container-49a47d25 | FAILED | rc=1 >> ERROR 2002 (HY000): Can't connect to local MySQL server @@ -63,12 +61,11 @@ one of the nodes. wsrep_cluster_size 1 wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1 wsrep_cluster_status Primary - #. Restart MariaDB on the other nodes and verify that they rejoin the cluster. - .. code-block:: bash + .. code-block:: shell-session node2_galera_container-49a47d25 | success | rc=0 >> Variable_name Value @@ -90,7 +87,6 @@ one of the nodes. wsrep_cluster_size 3 wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1 wsrep_cluster_status Primary - -------------- diff --git a/doc/source/install-guide/ops-troubleshooting-containernetworking.rst b/doc/source/install-guide/ops-troubleshooting-containernetworking.rst index 0876d39233..a311293a83 100644 --- a/doc/source/install-guide/ops-troubleshooting-containernetworking.rst +++ b/doc/source/install-guide/ops-troubleshooting-containernetworking.rst @@ -18,7 +18,7 @@ Predictable interface naming On the host, all virtual ethernet devices are named based on their container as well as the name of the interface inside the container: - .. code-block:: bash + .. code-block:: shell-session ${CONTAINER_UNIQUE_ID}_${NETWORK_DEVICE_NAME} @@ -29,9 +29,9 @@ network interfaces: `d13b7132_eth0` and `d13b7132_eth1`. Another option would be to use LXC's tools to retrieve information about the utility container: - .. code-block:: bash + .. code-block:: shell-session - $ lxc-info -n aio1_utility_container-d13b7132 + # lxc-info -n aio1_utility_container-d13b7132 Name: aio1_utility_container-d13b7132 State: RUNNING diff --git a/doc/source/install-guide/overview-lxc.rst b/doc/source/install-guide/overview-lxc.rst index 04b40ecb2a..e82962b81e 100644 --- a/doc/source/install-guide/overview-lxc.rst +++ b/doc/source/install-guide/overview-lxc.rst @@ -30,32 +30,32 @@ Useful commands: - List containers and summary information such as operational state and network configuration: - .. code-block:: bash + .. code-block:: shell-session # lxc-ls --fancy - Show container details including operational state, resource utilization, and ``veth`` pairs: - .. code-block:: bash + .. code-block:: shell-session # lxc-info --name container_name - Start a container: - .. code-block:: bash + .. code-block:: shell-session # lxc-start --name container_name - Attach to a container: - .. code-block:: bash + .. code-block:: shell-session # lxc-attach --name container_name - Stop a container: - .. code-block:: bash + .. code-block:: shell-session # lxc-stop --name container_name diff --git a/doc/source/install-guide/targethosts-add.rst b/doc/source/install-guide/targethosts-add.rst index 685ae94fe3..6999003ab1 100644 --- a/doc/source/install-guide/targethosts-add.rst +++ b/doc/source/install-guide/targethosts-add.rst @@ -12,16 +12,15 @@ configure NTP. #. Install additional software packages if not already installed during operating system installation: - .. code-block:: bash + .. code-block:: shell-session # apt-get install bridge-utils debootstrap ifenslave ifenslave-2.6 \ lsof lvm2 ntp ntpdate openssh-server sudo tcpdump vlan - #. Add the appropriate kernel modules to the ``/etc/modules`` file to enable VLAN and bond interfaces: - .. code-block:: bash + .. code-block:: shell-session # echo 'bonding' >> /etc/modules # echo '8021q' >> /etc/modules diff --git a/doc/source/install-guide/targethosts-configlvm.rst b/doc/source/install-guide/targethosts-configlvm.rst index 3e324b9db5..866d091465 100644 --- a/doc/source/install-guide/targethosts-configlvm.rst +++ b/doc/source/install-guide/targethosts-configlvm.rst @@ -8,11 +8,10 @@ Configuring LVM metadata size of 2048 must be specified during physical volume creation. For example: - .. code-block:: bash + .. code-block:: shell-session # pvcreate --metadatasize 2048 physical_volume_device_path # vgcreate cinder-volumes physical_volume_device_path - #. Optionally, create an LVM volume group named *lxc* for container file systems. If the lxc volume group does not exist, containers will be diff --git a/doc/source/install-guide/targethosts-networkrefarch.rst b/doc/source/install-guide/targethosts-networkrefarch.rst index 27545ee9be..09ed0fb93d 100644 --- a/doc/source/install-guide/targethosts-networkrefarch.rst +++ b/doc/source/install-guide/targethosts-networkrefarch.rst @@ -61,8 +61,8 @@ described in the following procedure. bond-downdelay 250 bond-updelay 250 - If not already complete, replace *``HOST_IP_ADDRESS``*, - *``HOST_NETMASK``*, *``HOST_GATEWAY``*, and *``HOST_DNS_SERVERS``* + If not already complete, replace ``HOST_IP_ADDRESS``, + ``HOST_NETMASK``, ``HOST_GATEWAY``, and ``HOST_DNS_SERVERS`` with the appropriate configuration for the host management network. #. Logical (VLAN) interfaces: @@ -81,7 +81,7 @@ described in the following procedure. iface bond0.STORAGE_VLAN_ID inet manual vlan-raw-device bond0 - Replace *``*_VLAN_ID``* with the appropriate configuration for the + Replace ``*_VLAN_ID`` with the appropriate configuration for the environment. #. Bridge devices: @@ -131,8 +131,8 @@ described in the following procedure. address STORAGE_BRIDGE_IP_ADDRESS netmask STORAGE_BRIDGE_NETMASK - Replace *``*_VLAN_ID``*, *``*_BRIDGE_IP_ADDRESS``*, and - *``*_BRIDGE_NETMASK``*, *``*_BRIDGE_DNS_SERVERS``* with the + Replace ``*_VLAN_ID``, ``*_BRIDGE_IP_ADDRESS``, and + ``*_BRIDGE_NETMASK``, ``*_BRIDGE_DNS_SERVERS`` with the appropriate configuration for the environment. -------------- diff --git a/doc/source/install-guide/targethosts-sshkeys.rst b/doc/source/install-guide/targethosts-sshkeys.rst index 08a106baab..326f7be575 100644 --- a/doc/source/install-guide/targethosts-sshkeys.rst +++ b/doc/source/install-guide/targethosts-sshkeys.rst @@ -7,7 +7,7 @@ Ansible uses Secure Shell (SSH) for connectivity between the deployment and target hosts. #. Copy the contents of the public key file on the deployment host to - the ``/root/.ssh/authorized_keys`` on each target host. + the ``/root/.ssh/authorized_keys`` file on each target host. #. Test public key authentication from the deployment host to each target host. SSH should provide a shell without asking for a