Fix a TBD, broken links and markup
Change-Id: I839a593df2116264112a6060f1f306910cfba197
This commit is contained in:
Petr Kovar
parent
a737fce15f
commit
51bac7d227
@ -37,7 +37,7 @@ scheduler will be unable to match the capabilities correctly.
|
||||
profile matching ("compute", "control", etc).
|
||||
|
||||
Create an environment file with Scheduler Hints
|
||||
----------------------------------------------
|
||||
-----------------------------------------------
|
||||
|
||||
The next step is simply to create a heat environment file, which matches the
|
||||
per-node capabilities created for each node above::
|
||||
|
||||
@ -3,12 +3,14 @@ Deploying with OVS DPDK Support
|
||||
|
||||
TripleO can deploy Overcloud nodes with OVS DPDK support. The following
|
||||
changes are required:
|
||||
|
||||
- Environment File
|
||||
- Parameters
|
||||
- Network Config
|
||||
|
||||
Environment File
|
||||
----------------
|
||||
|
||||
Deploy command should include the OVS DPDK environment file to override the
|
||||
default neutron-ovs-agent service with neutron-ovs-dpdk-agent service. All the
|
||||
required parameters are specified in this environment file as commented. The
|
||||
|
||||
@ -15,9 +15,9 @@ the ``generate_service_certificate`` option in ``undercloud.conf`` to
|
||||
``True``. This will generate a certificate in ``/etc/pki/tls/certs`` with
|
||||
a file name that follows the following pattern::
|
||||
|
||||
undercloud-[undercloud_public_vip].pem
|
||||
undercloud-[undercloud_public_vip].pem
|
||||
|
||||
This will be a PEM file in a format that HAProxy can understand (See the
|
||||
This will be a PEM file in a format that HAProxy can understand (see the
|
||||
HAProxy documentation for more information on this).
|
||||
|
||||
This option for auto-generating certificates uses Certmonger to request
|
||||
@ -31,7 +31,7 @@ The default is to use Certmonger's ``local`` CA. So using this option has
|
||||
the side-effect of extracting Certmonger's local CA to a PEM file that is
|
||||
located in the following path::
|
||||
|
||||
``/etc/pki/ca-trust/source/anchors/cm-local-ca.pem``
|
||||
/etc/pki/ca-trust/source/anchors/cm-local-ca.pem
|
||||
|
||||
This certificate will then be added to the trusted CA chain, since this is
|
||||
needed to be able to use the undercloud's endpoints with that certificate.
|
||||
@ -299,7 +299,7 @@ Self-signed DNS-based certificate::
|
||||
:class: stable
|
||||
|
||||
In Mitaka and older releases, the EndpointMap was in enable-tls.yaml, so there
|
||||
is no need to pass a tls-endpoints-*.yaml file. However, this means that the
|
||||
is no need to pass a tls-endpoints-\*.yaml file. However, this means that the
|
||||
enable-tls.yaml file must be rebased when upgrading to reflect any new endpoints
|
||||
that may have been added. Examples of the necessary parameters for different
|
||||
scenarios follow.
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
How to Contribute
|
||||
=================
|
||||
|
||||
|project| source code is available. You can contribute code to individual
|
||||
projects, documentation, report bugs and vulnerabilities, request features.
|
||||
|
||||
|project| source code is publicly available. You can contribute code to
|
||||
individual projects, documentation, report bugs and vulnerabilities, request
|
||||
features.
|
||||
|
||||
Contributing Code
|
||||
-----------------
|
||||
@ -16,17 +16,16 @@ wiki/How_To_Contribute>`_.
|
||||
See :doc:`../introduction/components` to find out how to contribute into
|
||||
individual projects.
|
||||
|
||||
|
||||
Contributing to this Documentation
|
||||
-----------------------------------
|
||||
|
||||
|project| User Documentation lives on Github under |project|
|
||||
organization.
|
||||
|project| User Documentation lives on
|
||||
`git.openstack.org <http://git.openstack.org/cgit/openstack/tripleo-docs/>`_
|
||||
and is mirrored on
|
||||
`GitHub under the OpenStack organization <https://github.com/openstack/tripleo-docs>`_.
|
||||
|
||||
Learn `how to contribute into TripleO Docs
|
||||
<https://git.openstack.org/openstack/tripleo-docs>`_.
|
||||
|
||||
|
||||
<http://git.openstack.org/cgit/openstack/tripleo-docs/tree/README.rst>`_.
|
||||
|
||||
Reporting Bugs
|
||||
--------------
|
||||
@ -34,14 +33,14 @@ Reporting Bugs
|
||||
**OpenStack Upstream**: If you find bugs or vulnerabilities which affect
|
||||
upstream projects, please follow OpenStack's process of filing bugs.
|
||||
|
||||
* Learn `how to create Bugs in OpenStack
|
||||
* Learn `how to report bugs in OpenStack
|
||||
<https://wiki.openstack.org/wiki/Bugs>`_.
|
||||
|
||||
* If you want to file a bug against upstream project, you can find useful links
|
||||
in our list of :doc:`../introduction/components`.
|
||||
|
||||
|
||||
**|project|** If the bug impacts the |project| project as a whole, you can file a
|
||||
**TripleO** If the bug impacts the |project| project as a whole, you can file a
|
||||
bug in |bug_tracker|:
|
||||
|
||||
#. Go to |bug_tracker_url|
|
||||
@ -51,7 +50,6 @@ bug in |bug_tracker|:
|
||||
|
||||
#. Submit bug
|
||||
|
||||
|
||||
Requesting Features
|
||||
-------------------
|
||||
**OpenStack Upstream**: Since we are developing projects in OpenStack community,
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Updating tripleo-heat-templates
|
||||
---------------------------------
|
||||
-------------------------------
|
||||
|
||||
This section will describe the changes needed for tripleo-heat-templates.
|
||||
|
||||
@ -56,7 +56,7 @@ Step 1 - Updating puppet references
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Remove all puppet references for the composable service from the current
|
||||
manifests (*.pp). All the puppet logic will live in the puppet-tripleo
|
||||
manifests (\*.pp). All the puppet logic will live in the puppet-tripleo
|
||||
repository based on a configuration step, so it is mandatory to remove all the
|
||||
puppet references from tripleo-heat-templates.
|
||||
|
||||
@ -77,7 +77,7 @@ The updated .pp files for the NTP example were:
|
||||
|
||||
|
||||
Step 2 - overcloud-resource-registry-puppet.j2.yaml resource registry changes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The resource ``OS::TripleO::Services::Ntp`` must be defined in the resource
|
||||
registry (``overcloud-resource-registry-puppet.j2.yaml``)
|
||||
|
||||
@ -2,6 +2,7 @@ THT design patterns
|
||||
-------------------
|
||||
|
||||
.. _duplicated-parameters:
|
||||
|
||||
Duplicated parameters
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ The puppet manifests used to configure services on overcloud nodes currently
|
||||
reside in the tripleo-heat-templates repository, in the folder `puppet/manifests`_.
|
||||
In order to properly organize and structure the code, all
|
||||
manifests will be re-defined in the puppet-tripleo repository, and adapted to
|
||||
the `composable services architecture`_
|
||||
the `composable services architecture`_.
|
||||
|
||||
The use case for this example uses NTP as a service installed by default among
|
||||
the OpenStack deployment. In this particular case, NTP is installed and
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
Summary
|
||||
------
|
||||
-------
|
||||
|
||||
References:
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ Composable services tutorial
|
||||
|
||||
This guide will be a walkthrough related to how to add new services to a TripleO
|
||||
deployment through additions to the tripleo-heat-templates and puppet-tripleo
|
||||
repositories, using part of the architecture defined in the `composable services architecture`_
|
||||
repositories, using part of the architecture defined in the `composable services architecture`_.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
Baremetal Environment
|
||||
-----------------------------------
|
||||
---------------------
|
||||
|
||||
|project| can be used in an all baremetal environment. One machine will be
|
||||
used for Undercloud, the others will be used for your Overcloud.
|
||||
|
||||
|
||||
Minimum System Requirements
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To deploy a minimal TripleO cloud with |project| you need the following baremetal
|
||||
machines:
|
||||
|
||||
@ -36,7 +36,7 @@ TripleO is supporting only the following operating systems:
|
||||
|
||||
|
||||
Preparing the Baremetal Environment
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Networking
|
||||
^^^^^^^^^^
|
||||
@ -150,7 +150,7 @@ And run them one by one::
|
||||
|
||||
|
||||
Configuration Files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. _instackenv:
|
||||
|
||||
@ -238,7 +238,7 @@ For example::
|
||||
}
|
||||
|
||||
Ironic Drivers
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
Ironic drivers provide various level of support for different hardware.
|
||||
The most up-to-date information about Ironic drivers is at
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
be removed in a future release.
|
||||
|
||||
Virtual Environment
|
||||
-----------------------------------
|
||||
-------------------
|
||||
|
||||
|project| can be used in a virtual environment using virtual machines instead
|
||||
of actual baremetal. However, one baremetal machine is still
|
||||
@ -12,9 +12,9 @@ needed to act as the host for the virtual machines.
|
||||
purposes only. This method cannot be used for production-ready
|
||||
deployments.
|
||||
|
||||
|
||||
Minimum System Requirements
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By default, this setup creates 3 virtual machines:
|
||||
|
||||
* 1 Undercloud
|
||||
@ -44,7 +44,7 @@ The baremetal machine should meet the following minimum system requirements:
|
||||
.. _preparing_virtual_environment:
|
||||
|
||||
Preparing the Virtual Environment (Automated)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
#. Install RHEL 7.1 Server x86_64 or CentOS 7 x86_64 on your host machine.
|
||||
|
||||
@ -52,7 +52,7 @@ Preparing the Virtual Environment (Automated)
|
||||
.. admonition:: RHEL Portal Registration
|
||||
:class: portal
|
||||
|
||||
Register the host machine using Subscription Management.::
|
||||
Register the host machine using Subscription Management::
|
||||
|
||||
sudo subscription-manager register --username="[your username]" --password="[your password]"
|
||||
# Find this with `subscription-manager list --available`
|
||||
@ -109,6 +109,7 @@ Preparing the Virtual Environment (Automated)
|
||||
|
||||
.. We need to manually continue our list numbering here since the above
|
||||
"include" directive breaks the numbering.
|
||||
|
||||
5. Install instack-undercloud::
|
||||
|
||||
sudo yum install -y instack-undercloud
|
||||
@ -240,6 +241,7 @@ Preparing the Virtual Environment (Automated)
|
||||
change the target for an existing volume pool with this method, so if
|
||||
you already have a 'default' pool and cannot remove it, you should also
|
||||
specify a new pool name to be created.
|
||||
|
||||
::
|
||||
|
||||
instack-virt-setup
|
||||
|
||||
@ -194,8 +194,8 @@ virtual machines which act as bare metal nodes via special driver ``pxe_ssh``.
|
||||
**How to contribute**
|
||||
|
||||
Ironic uses `tox <https://tox.readthedocs.org/en/latest/>`_ to manage the
|
||||
development environment, see `OpenStack's Documentation
|
||||
<http://docs.openstack.org/developer/ironic/dev/contributing.html>`_,
|
||||
development environment, see the `Developer Quick-Start
|
||||
<http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html>`_,
|
||||
`Ironic Developer Guidelines
|
||||
<https://wiki.openstack.org/wiki/Ironic/Developer_guidelines>`_
|
||||
and `OpenStack Developer's Guide`_ for details.
|
||||
@ -300,7 +300,22 @@ are deployed via Heat.
|
||||
|
||||
nova
|
||||
^^^^
|
||||
TBD
|
||||
|
||||
nova provides a cloud computing fabric controller.
|
||||
|
||||
**How to contribute**
|
||||
|
||||
* Read the
|
||||
`Development Quickstart <http://docs.openstack.org/developer/nova/development.environment.html>`_
|
||||
to set up a development environment. Submit your changes via OpenStack
|
||||
Gerrit (see
|
||||
`OpenStack Developer's Guide <http://docs.openstack.org/infra/manual/developers.html>`_).
|
||||
|
||||
**Useful links**
|
||||
|
||||
* Git repository: https://git.openstack.org/cgit/openstack/nova
|
||||
* Bugs: https://bugs.launchpad.net/nova
|
||||
* Blueprints: https://blueprints.launchpad.net/nova
|
||||
|
||||
puppet-\*
|
||||
^^^^^^^^^
|
||||
|
||||
@ -22,7 +22,7 @@ When using the CLI, all of the TripleO workflows can be viewed with the
|
||||
command ``openstack workflow list``. All of the workflows provided by TripleO
|
||||
will have a name starting with ``tripleo.``
|
||||
|
||||
.. code-block:: plain
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack workflow list
|
||||
+--------------------------------------+-----------------------------------------+------------------------------+
|
||||
@ -37,7 +37,7 @@ accept use the ``openstack workflow show`` command. This command will also
|
||||
show the default values for input parameters. If no default is given, then it
|
||||
is required.
|
||||
|
||||
.. code-block:: plain
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack workflow show tripleo.plan_management.v1.create_default_deployment_plan
|
||||
+------------+-----------------------------------------------------------+
|
||||
@ -55,7 +55,7 @@ is required.
|
||||
This workflow can then be executed with the ``openstack workflow execution
|
||||
create`` command.
|
||||
|
||||
.. code-block:: plain
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack workflow execution create tripleo.plan_management.v1.create_default_deployment_plan \
|
||||
'{"container": "my_cloud"}'
|
||||
@ -108,7 +108,7 @@ environment.
|
||||
|
||||
The following command creates a plan called ``my_cloud``.
|
||||
|
||||
.. code-block:: plain
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack workflow execution create tripleo.plan_management.v1.create_default_deployment_plan \
|
||||
'{"container": "my_cloud"}'
|
||||
@ -279,7 +279,7 @@ successful. These required parameters will depend on the Heat templates that
|
||||
are being used. Parameters can be set with the Mistral Action
|
||||
``tripleo.parameters.update``.
|
||||
|
||||
.. node::
|
||||
.. note::
|
||||
|
||||
This action will merge the passed parameters with those already set on the
|
||||
plan. To set the parameters first use ``tripleo.parameters.reset`` to
|
||||
|
||||
@ -245,7 +245,7 @@ Upgrading the Overcloud
|
||||
**Explicitly disable sahara services if so desired:**
|
||||
As discussed at bug1630247_ sahara services are disabled by default
|
||||
in the Newton overcloud deployment. This special case is handled for
|
||||
the duration of the upgrade by defaulting to 'keep sahara-*'.
|
||||
the duration of the upgrade by defaulting to 'keep sahara-\*'.
|
||||
|
||||
That is by default sahara services are restarted after the mitaka to
|
||||
newton upgrade of controller nodes and sahara config is re-applied
|
||||
@ -310,7 +310,7 @@ Upgrading the Overcloud
|
||||
**Explicitly disable sahara services if so desired:**
|
||||
As discussed at bug1630247_ sahara services are disabled by default
|
||||
in the Newton overcloud deployment. This special case is handled for
|
||||
the duration of the upgrade by defaulting to 'keep sahara-*'.
|
||||
the duration of the upgrade by defaulting to 'keep sahara-\*'.
|
||||
|
||||
That is by default sahara services are restarted after the mitaka to
|
||||
newton upgrade of controller nodes and sahara config is re-applied
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
Troubleshooting a Failed Overcloud Deployment
|
||||
-----------------------------------
|
||||
---------------------------------------------
|
||||
|
||||
If an Overcloud deployment has failed, the OpenStack clients and service log
|
||||
files can be used to troubleshoot the failed deployment. The following commands
|
||||
are all run on the Undercloud and assume a stackrc file has been sourced.
|
||||
|
||||
Identifying Failed Component
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In most cases, Heat will show the failed overcloud stack when a deployment
|
||||
has failed::
|
||||
@ -82,7 +82,7 @@ in the resulting table.
|
||||
console (e.g. iDRAC for DELL) for bare metal machines.
|
||||
|
||||
Debugging Using Heat
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Identifying the failed Heat resource
|
||||
|
||||
@ -231,7 +231,7 @@ Debugging Using Heat
|
||||
.. _no-valid-host:
|
||||
|
||||
No Valid Host Found Error
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Sometimes ``/var/log/nova/nova-conductor.log`` contains the following error::
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Troubleshooting instack-virt-setup Failures
|
||||
-----------------------------------
|
||||
-------------------------------------------
|
||||
|
||||
Known Issues:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
* Due to a `bug in libvirt`_, it is possible for instack-virt-setup to fail
|
||||
with an error such as the following::
|
||||
|
||||
Loading…
Reference in New Issue
Block a user