Remove doc build errors

Gates only build deploy-guide docs, not every doc.
This change clean doc errors, only Line to long.

Also, removes doc/build folder in tox doc environment.
doc/build is folder where previus executions are stored
causing next execution to fail due rendered versions does
not follow doc style checks.

Change-Id: I623a7ee245729a06509f3a7039d5d5ed3813d977
This commit is contained in:
Eduardo Gonzalez 2017-07-13 15:04:19 +01:00
parent 003450a2c6
commit 66b91d8bd0
7 changed files with 42 additions and 28 deletions

View File

@ -66,8 +66,9 @@ Virtual Interface the following PowerShell may be used:
-AllowManagementOS option is set on True, otherwise you will lose connectivity to the Hyper-V node.
To prepare the Hyper-V node to be able to attach to volumes provided by cinder you must
first make sure the Windows iSCSI initiator service is running and started automatically.
To prepare the Hyper-V node to be able to attach to volumes provided by
cinder you must first make sure the Windows iSCSI initiator service is
running and started automatically.
.. code-block:: console
@ -94,15 +95,16 @@ Hyper-V options are also required in ``/etc/kolla/globals.yml``:
vswitch_name: <HyperV virtual switch name>
nova_msi_url: "https://www.cloudbase.it/downloads/HyperVNovaCompute_Beta.msi"
If tenant networks are to be built using VLAN add corresponding type in ``/etc/kolla/globals.yml``:
If tenant networks are to be built using VLAN add corresponding type in
``/etc/kolla/globals.yml``:
.. code-block:: console
neutron_tenant_network_types: 'flat,vlan'
The virtual switch is the same one created on the HyperV setup part.
For nova_msi_url, different Nova MSI (Mitaka/Newton/Ocata) versions can be found on
`Cloudbase website
For nova_msi_url, different Nova MSI (Mitaka/Newton/Ocata) versions can
be found on `Cloudbase website
<https://cloudbase.it/openstack-hyperv-driver/>`__.
@ -120,7 +122,8 @@ Add the Hyper-V node in ``ansible/inventory`` file:
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore
pywinrm package needs to be installed in order for Ansible to work on the HyperV node:
``pywinrm`` package needs to be installed in order for Ansible to work
on the HyperV node:
.. code-block:: console
@ -136,16 +139,18 @@ pywinrm package needs to be installed in order for Ansible to work on the HyperV
Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList <VLAN ID> -NativeVlanId 0 <VM name>
networking-hyperv mechanism driver is needed for neutron-server to communicate with
HyperV nova-compute. This can be built with source images by default. Manually it
can be intalled in neutron-server container with pip:
networking-hyperv mechanism driver is needed for neutron-server to
communicate with HyperV nova-compute. This can be built with source
images by default. Manually it can be intalled in neutron-server
container with pip:
.. code-block:: console
pip install "networking-hyperv>=4.0.0"
For neutron_extension_drivers, ``port_security`` and ``qos`` are currently supported by the networking-hyperv
mechanism driver. By default only ``port_security`` is set.
For neutron_extension_drivers, ``port_security`` and ``qos`` are
currently supported by the networking-hyperv mechanism driver.
By default only ``port_security`` is set.
Verify Operations

View File

@ -29,7 +29,8 @@ Enable Ironic role in ``/etc/kolla/globals.yml``:
enable_ironic: "yes"
Beside that an additional network type 'flat' has to be added to a list of tenant network types:
Beside that an additional network type 'flat' has to be added to a list of
tenant network types:
.. code-block:: console

View File

@ -22,7 +22,8 @@ Only source containers are supported.
Enabling Kolla "dev mode"
-------------------------
To enable dev mode for all supported services, set in ``/etc/kolla/globals.yml``:
To enable dev mode for all supported services, set in
``/etc/kolla/globals.yml``:
::

View File

@ -3,14 +3,17 @@
============================
Enabling Provider Networks
============================
Provider networks allow to connect compute instances directly to physical networks avoiding tunnels.
This is necessary for example for some performance critical applications. Only administrators of
OpenStack can create such networks. For provider networks compute hosts must have external bridge
created and configured by Ansible tasks like it is already done for tenant DVR mode networking.
Normal tenant non-DVR networking does not need external bridge on compute hosts and therefore
operators don't need additional dedicated network interface.
Provider networks allow to connect compute instances directly to physical
networks avoiding tunnels. This is necessary for example for some performance
critical applications. Only administrators of OpenStack can create such
networks. For provider networks compute hosts must have external bridge
created and configured by Ansible tasks like it is already done for tenant
DVR mode networking. Normal tenant non-DVR networking does not need external
bridge on compute hosts and therefore operators don't need additional
dedicated network interface.
To enable provider networks modify the configuration file ``/etc/kolla/globals.yml``:
To enable provider networks modify the configuration
file ``/etc/kolla/globals.yml``:
::

View File

@ -79,8 +79,8 @@ triggered on the Docker host when the neutron-agents containers are launched.
This can be useful when you want to do a new clean deployment, particularly one
changing the network topology.
``tools/cleanup-images --all`` is used to remove all Docker images built by Kolla
from the local Docker cache.
``tools/cleanup-images --all`` is used to remove all Docker images built by
Kolla from the local Docker cache.
``kolla-ansible -i INVENTORY deploy`` is used to deploy and start all Kolla
containers..
@ -103,13 +103,15 @@ tests.
.. note::
In order to do smoke tests, requires ``kolla_enable_sanity_checks=yes``.
``kolla-mergepwd --old OLD_PASSWORDS --new NEW_PASSWORDS --final FINAL_PASSWORDS``
is used to merge passwords from old installation with newly generated passwords
during upgrade of Kolla release. The workflow is:
``kolla-mergepwd --old OLD_PASSWDS --new NEW_PASSWDS --final FINAL_PASSWDS``
is used to merge passwords from old installation with newly generated
passwords during upgrade of Kolla release. The workflow is:
- save old passwords from ``/etc/kolla/passwords.yml`` into ``passwords.yml.old``
- generate new passwords via ``kolla-genpwd`` as ``passwords.yml.new``
- merge ``passwords.yml.old`` and ``passwords.yml.new`` into ``/etc/kolla/passwords.yml``
- Save old passwords from ``/etc/kolla/passwords.yml`` into
``passwords.yml.old``
- Generate new passwords via ``kolla-genpwd`` as ``passwords.yml.new``
- Merge ``passwords.yml.old`` and ``passwords.yml.new`` into
``/etc/kolla/passwords.yml``
For example::

View File

@ -54,6 +54,7 @@ setup-hooks =
all_files = 1
build-dir = doc/build
source-dir = doc
warning-is-error = 1
[build_releasenotes]
all_files = 1

View File

@ -44,6 +44,7 @@ commands = {posargs}
[testenv:docs]
commands =
rm -rf doc/build
doc8 doc
python setup.py build_sphinx