[docs] Updating 404 links
Change-Id: I35445edd09f103d753469b8b4a5d3d3e549153c1 Partial-bug: #1652948
This commit is contained in:
Alexandra Settle
parent
4150b916b6
commit
cb6006a768
|
|
@ -98,11 +98,11 @@ Deploying the Role
|
|||
modifications being sure that group labels in ``env.d`` and ``conf.d``
|
||||
files are consistent.
|
||||
|
||||
#. Generate secrets, if any, `as described in the Install Guide`_. You can
|
||||
append your keys to an existing ``user_secrets.yml`` file or add a new file
|
||||
to the ``openstack_deploy`` directory to contain them. Provide overrides
|
||||
for any other variables you will need at this time as well, either in
|
||||
``user_variables.yml`` or another file. This is explained in more depth
|
||||
#. Generate secrets, if any, as described in the `Deployment Guide <http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/configure.html#configuring-service-credentials>`_.
|
||||
You can append your keys to an existing ``user_secrets.yml`` file or add a
|
||||
new file to the ``openstack_deploy`` directory to contain them. Provide
|
||||
overrides for any other variables you will need at this time as well, either
|
||||
in ``user_variables.yml`` or another file. This is explained in more depth
|
||||
under `Extending OpenStack-Ansible`_.
|
||||
#. If your service is installed from source or relies on python packages which
|
||||
need to be installed from source, specify a repository for the source
|
||||
|
|
@ -132,7 +132,6 @@ Deploying the Role
|
|||
.. _Adding Galaxy roles: extending.html#adding-galaxy-roles
|
||||
.. _env.d: extending.html#env-d
|
||||
.. _conf.d: extending.html#conf-d
|
||||
.. _as described in the Install Guide: ../install-guide/configure.html#configuring-service-credentials
|
||||
.. _Extending OpenStack-Ansible: extending.html#user-yml-files
|
||||
|
||||
Role development maturity
|
||||
|
|
@ -262,7 +261,8 @@ The development of a role will usually go through the following stages:
|
|||
|
||||
This is implemented into the dynamic inventory through the definition of
|
||||
content in an ``env.d`` file. A description of how these work can be
|
||||
found in `Appendix C`_ of the Installation Guide.
|
||||
found in `Appendix C <http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/app-custom-layouts.html>`_
|
||||
of the Deployment Guide.
|
||||
|
||||
* Load balancer configuration
|
||||
|
||||
|
|
@ -323,8 +323,6 @@ The development of a role will usually go through the following stages:
|
|||
required last step before a service can remove the experimental warning
|
||||
from the documentation.
|
||||
|
||||
.. _Appendix C: ../install-guide/app-custom-layouts.html
|
||||
|
||||
--------------
|
||||
|
||||
.. include:: navigation.txt
|
||||
|
|
|
|||
|
|
@ -197,11 +197,8 @@ OpenStack-Ansible has multiple forms of documentation with different intent.
|
|||
statements of intent. The work to fulfill the intent is ongoing. Any new
|
||||
documentation submissions should try to help this intent where possible.
|
||||
|
||||
The `install guide <../install-guide/>`_ intends to help deployers install
|
||||
OpenStack-Ansible for the first time. As such, the install guide is somewhat
|
||||
opinionated, focusing on ensuring that the deployer has to make very few
|
||||
decisions and implement the least amount of configuration possible to deploy
|
||||
a running OpenStack environment.
|
||||
The `Deployment Guide <http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/>`_
|
||||
intends to help deployers deploy OpenStack-Ansible for the first time.
|
||||
|
||||
The role documentation (for example, the `keystone role documentation`_)
|
||||
intends to explain all the options available for the role and how to implement
|
||||
|
|
|
|||
|
|
@ -71,22 +71,22 @@ including the OpenStack-Ansible roles and libraries by putting an
|
|||
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.
|
||||
``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
|
||||
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.
|
||||
``library``
|
||||
This variable should point to
|
||||
``openstack-ansible/playbooks/library``. Doing so allows roles and
|
||||
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
|
||||
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.
|
||||
|
||||
Note that the paths to the ``openstack-ansible`` top level directory can be
|
||||
The paths to the ``openstack-ansible`` top level directory can be
|
||||
relative in this file.
|
||||
|
||||
Consider this directory structure::
|
||||
|
|
@ -103,7 +103,6 @@ Consider this directory structure::
|
|||
The variables in ``my_project/custom_stuff/playbooks/ansible.cfg`` would use
|
||||
``../openstack-ansible/playbooks/<directory>``.
|
||||
|
||||
|
||||
env.d
|
||||
~~~~~
|
||||
|
||||
|
|
@ -113,9 +112,8 @@ deployed environment, allowing a deployer to define additional group mappings.
|
|||
This directory is used to extend the environment skeleton, or modify the
|
||||
defaults defined in the ``playbooks/inventory/env.d`` directory.
|
||||
|
||||
See also `Understanding Container Groups`_ in Appendix C.
|
||||
|
||||
.. _Understanding Container Groups: ../install-guide/app-custom-layouts.html#understanding-container-groups
|
||||
See also `Understanding Container Groups <http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/app-custom-layouts.html>`_
|
||||
in Appendix C of the Deployment Guide.
|
||||
|
||||
conf.d
|
||||
~~~~~~
|
||||
|
|
@ -127,9 +125,8 @@ OpenStack-Ansible in the
|
|||
Additional services should be defined with a YAML file in
|
||||
``/etc/openstack_deploy/conf.d``, in order to manage file size.
|
||||
|
||||
See also `Understanding Host Groups`_ in Appendix C.
|
||||
|
||||
.. _Understanding Host Groups: ../install-guide/app-custom-layouts.html#understanding-host-groups
|
||||
See also `Understanding Host Groups <http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/app-custom-layouts.html>`_
|
||||
in Appendix C of the Deployment Guide.
|
||||
|
||||
user_*.yml files
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
|
@ -174,11 +171,11 @@ preset template option. All OpenStack-Ansible roles allow for this
|
|||
functionality where applicable. Files available to receive overrides can be
|
||||
seen in the ``defaults/main.yml`` file as standard empty dictionaries (hashes).
|
||||
|
||||
Practical guidance for using this feature is available in the `Install Guide`_.
|
||||
Practical guidance for using this feature is available in the
|
||||
`Deployment Guide <http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/app-advanced-config-override.html>`_.
|
||||
|
||||
This module has been `submitted for consideration`_ into Ansible Core.
|
||||
|
||||
.. _Install Guide: ../install-guide/app-advanced-config-override.html
|
||||
.. _submitted for consideration: https://github.com/ansible/ansible/pull/12555
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Scaling your environment
|
|||
This is a draft environment scaling page for the proposed OpenStack-Ansible
|
||||
operations guide.
|
||||
|
||||
Add a new infrastructure node
|
||||
Add a new infrastructure host
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
While three infrastructure hosts are recommended, if further hosts are
|
||||
|
|
@ -82,7 +82,7 @@ Use the following procedure to add a compute host to an operational
|
|||
cluster.
|
||||
|
||||
#. Configure the host as a target host. See `Prepare target hosts
|
||||
<http://docs.openstack.org/developer/openstack-ansible/install-guide/targethosts.html>`_
|
||||
<http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/targethosts.html>`_
|
||||
for more information.
|
||||
|
||||
#. Edit the ``/etc/openstack_deploy/openstack_user_config.yml`` file and
|
||||
|
|
@ -153,7 +153,7 @@ To remove a compute host, follow the below procedure.
|
|||
OpenStack-Ansible configuration file in
|
||||
``/etc/openstack_deploy/openstack_user_config.yml``.
|
||||
|
||||
Recover a Compute node failure
|
||||
Recover a compute host failure
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following procedure addresses Compute node failure if shared storage
|
||||
|
|
@ -167,48 +167,48 @@ is used.
|
|||
performing the following procedure. Please note this method is
|
||||
not supported.
|
||||
|
||||
#. Re-launch all instances on the failed node.
|
||||
#. Re-launch all instances on the failed node.
|
||||
|
||||
#. Invoke the MySQL command line tool
|
||||
#. Invoke the MySQL command line tool
|
||||
|
||||
#. Generate a list of instance UUIDs hosted on the failed node:
|
||||
#. Generate a list of instance UUIDs hosted on the failed node:
|
||||
|
||||
.. code::
|
||||
.. code::
|
||||
|
||||
mysql> select uuid from instances where host = '${FAILED_NODE}' and deleted = 0;
|
||||
mysql> select uuid from instances where host = '${FAILED_NODE}' and deleted = 0;
|
||||
|
||||
#. Set instances on the failed node to be hosted on a different node:
|
||||
#. Set instances on the failed node to be hosted on a different node:
|
||||
|
||||
.. code::
|
||||
.. code::
|
||||
|
||||
mysql> update instances set host ='${RECEIVING_NODE}' where host = '${FAILED_NODE}' \
|
||||
and deleted = 0;
|
||||
mysql> update instances set host ='${RECEIVING_NODE}' where host = '${FAILED_NODE}' \
|
||||
and deleted = 0;
|
||||
|
||||
#. Reboot each instance on the failed node listed in the previous query
|
||||
to regenerate the XML files:
|
||||
#. Reboot each instance on the failed node listed in the previous query
|
||||
to regenerate the XML files:
|
||||
|
||||
.. code::
|
||||
.. code::
|
||||
|
||||
# nova reboot —hard $INSTANCE_UUID
|
||||
# nova reboot —hard $INSTANCE_UUID
|
||||
|
||||
#. Find the volumes to check the instance has successfully booted and is
|
||||
at the login :
|
||||
#. Find the volumes to check the instance has successfully booted and is
|
||||
at the login :
|
||||
|
||||
.. code::
|
||||
.. code::
|
||||
|
||||
mysql> select nova.instances.uuid as instance_uuid, cinder.volumes.id \
|
||||
as voume_uuid, cinder.volumes.status, cinder.volumes.attach_status, \
|
||||
cinder.volumes.mountpoint, cinder.volumes,display_name from \
|
||||
cinder.volumes inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid \
|
||||
where nova.instances.host = '${FAILED_NODE}';
|
||||
mysql> select nova.instances.uuid as instance_uuid, cinder.volumes.id \
|
||||
as voume_uuid, cinder.volumes.status, cinder.volumes.attach_status, \
|
||||
cinder.volumes.mountpoint, cinder.volumes,display_name from \
|
||||
cinder.volumes inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid \
|
||||
where nova.instances.host = '${FAILED_NODE}';
|
||||
|
||||
#. If rows are found, detach and re-attach the volumes using the values
|
||||
listed in the previous query:
|
||||
#. If rows are found, detach and re-attach the volumes using the values
|
||||
listed in the previous query:
|
||||
|
||||
.. code::
|
||||
.. code::
|
||||
|
||||
# nova volume-detach $INSTANCE_UUID $VOLUME_UUID && \
|
||||
nova volume-attach $INSTANCE_UUID $VOLUME_UUID $VOLUME_MOUNTPOINT
|
||||
# nova volume-detach $INSTANCE_UUID $VOLUME_UUID && \
|
||||
# nova volume-attach $INSTANCE_UUID $VOLUME_UUID $VOLUME_MOUNTPOINT
|
||||
|
||||
#. Rebuild or replace the failed node as described in `Adding a Compute
|
||||
node <compute-add-node.html>`_
|
||||
#. Rebuild or replace the failed node as described in `Adding a Compute
|
||||
host <scale-environment.html#add-a-compute-host>`_.
|
||||
|
|
|
|||
|
|
@ -35,9 +35,8 @@ Using an image, create a new instance via the Dashboard options.
|
|||
**Don't boot from a volume** for now.
|
||||
|
||||
For more information on attaching Block Storage volumes to
|
||||
instances for persistent storage, see `the
|
||||
“Managing volumes for persistent
|
||||
storage” section <manage-volumes-persistent-storage.html>`__.
|
||||
instances for persistent storage, see the
|
||||
*Managing volumes for persistent storage* section below.
|
||||
|
||||
#. Add customisation scripts, if needed, by clicking the
|
||||
**Post-Creation** tab. These run after the instance has been
|
||||
|
|
|
|||
Loading…
Reference in New Issue