openstack/kolla-ansible
Code Issues Proposed changes

doc: Start using openstackdoctheme's extlink extension

Browse Source 
This ensures we have version-specific references to other projects [1].
Note that this doesn't mean the URLs are actually valid - we need to do
more work (linkcheck?) here, but it's an improvement nonetheless.

[1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper

Change-Id: I118e4d211617c5df66ff04dc04e308a1d2fc67ad
This commit is contained in:
chenxing 2019-06-14 17:00:14 +08:00
parent cb0cb441c2
commit 31526d4c26
23 changed files with 70 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/source/conf.py
View File

@ -12,6 +12,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
from kolla_ansible.version import version_info as kolla_version
import os
import sys
@ -44,7 +45,6 @@ copyright = u'2013, OpenStack Foundation'
# built documents.
#
# The short X.Y version.
from kolla_ansible.version import version_info as kolla_version
# The full version, including alpha/beta/rc tags.
release = kolla_version.version_string_with_vcs()
# The short X.Y version.
@ -89,5 +89,19 @@ repository_name = 'openstack/kolla-ansible'
bug_project = 'kolla-ansible'
bug_tag = ''
openstack_projects = [
'bifrost',
'cinder',
'designate',
'glance',
'ironic',
'keystone',
'kolla',
'kolla-ansible',
'manila',
'networking-sfc',
'neutron-vpnaas',
'neutron',
'nova',
'oslotest',
'swift',
]

4
doc/source/contributor/ptl-guide.rst
View File

@ -2,5 +2,5 @@
PTL Guide
=========
The Kolla PTL is also PTL for Kolla Ansible. See the `Kolla PTL guide
<https://docs.openstack.org/kolla/latest/contributor/ptl-guide.html>`__.
The Kolla PTL is also PTL for Kolla Ansible. See the
:kolla-doc:`Kolla PTL guide <contributor/ptl-guide.html>`.

3
doc/source/contributor/release-management.rst
View File

@ -3,5 +3,4 @@ Release Management
==================
Release management for Kolla Ansible is very much linked to that of Kolla. See
`Kolla release management
<https://docs.openstack.org/kolla/latest/contributor/release-management.html>`__.
:kolla-doc:`Kolla release management <contributor/release-management.html>`.

5
doc/source/contributor/running-tests.rst
View File

@ -98,6 +98,5 @@ Then run ``tox`` with the debug environment as one of the following:
tox -e debug
tox -e debug test_file_name.TestClass.test_name
For more information, see the `oslotest documentation
<https://docs.openstack.org/oslotest/latest/user/features.html#debugging-with-oslo-debug-helper>`_.
For more information, see the :oslotest-doc:`oslotest documentation
<user/features.html#debugging-with-oslo-debug-helper>`.

6
doc/source/contributor/vagrant-dev-env.rst
View File

@ -1,5 +1,3 @@
.. vagrant-dev-env:
====================================
Development Environment with Vagrant
====================================
@ -203,8 +201,8 @@ Once logged on the **operator** VM call the ``kolla-build`` utility:
kolla-build
``kolla-build`` accept arguments as documented in `Building Container Images
<https://docs.openstack.org/kolla/latest/admin/image-building.html>`_.
``kolla-build`` accept arguments as documented in
:kolla-doc:`Building Container Images <admin/image-building.html>`.
It builds Docker images and pushes them to the local registry if the **push**
option is enabled (in Vagrant this is the default behaviour).

4
doc/source/reference/bare-metal/ironic-guide.rst
View File

@ -186,8 +186,8 @@ requests may not be hitting various pieces of the process:
Configuring the Web Console
---------------------------
Configuration based off upstream `Node web console
<https://docs.openstack.org/ironic/latest/admin/console.html#node-web-console>`__.
Configuration based off upstream :ironic-doc:`Node web console
<admin/console.html#node-web-console>`.
Serial speed must be the same as the serial configuration in the BIOS settings.
Default value: 115200bps, 8bit, non-parity.If you have different serial speed.

4
doc/source/reference/compute/hyperv-guide.rst
View File

@ -165,5 +165,5 @@ OpenStack HyperV services can be inspected and managed from PowerShell:
PS C:\> Restart-Service neutron-hyperv-agent
For more information on OpenStack HyperV, see
`Hyper-V virtualization platform
<https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-hyper-v.html>`__.
:nova-doc:`Hyper-V virtualization platform
<admin/configuration/hypervisor-hyper-v.html>`.

4
doc/source/reference/compute/vmware-guide.rst
View File

@ -269,6 +269,6 @@ Then you should start :command:`kolla-ansible` deployment normally as
KVM/QEMU deployment.
For more information on OpenStack vSphere, see
`VMware vSphere
<https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-vmware.html>`__,
:nova-doc:`VMware vSphere
<admin/configuration/hypervisor-vmware.html>`,
`VMware-NSX package <https://github.com/openstack/vmware-nsx>`_.

11
doc/source/reference/compute/xenserver-guide.rst
View File

@ -85,18 +85,15 @@ You also need set the password for xenserver_username in
xenserver_password: "root_password"
Then you can start kolla-ansible deployment just following the general
deployment instructions [`Quick Start`_].
Then you can start kolla-ansible deployment just following the
:doc:`/user/quickstart`.
References
==========
For more information on XenAPI OpenStack, see:
XenAPI OpenStack: https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-xen-api.html
For more information on XenAPI OpenStack, see
:nova-doc:`XenAPI OpenStack <admin/configuration/hypervisor-xen-api.html>`
.. _RDO repos: https://www.rdoproject.org/what/repos/
.. _XenServer documents: https://docs.citrix.com/en-us/xenserver/current-release.html
.. _Quick Start: https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

4
doc/source/reference/deployment-and-bootstrapping/bifrost.rst
View File

@ -458,9 +458,9 @@ done remotely with :command:`ipmitool` and Serial Over LAN. For example
References
~~~~~~~~~~
* `Bifrost documentation <https://docs.openstack.org/bifrost/latest/>`__
* :bifrost-doc:`Bifrost documentation <>`
* `Bifrost troubleshooting guide <https://docs.openstack.org/bifrost/latest/user/troubleshooting.html>`__
* :bifrost-doc:`Bifrost troubleshooting guide <user/troubleshooting.html>`
* `Bifrost code repository <https://github.com/openstack/bifrost>`__

3
doc/source/reference/networking/designate-guide.rst
View File

@ -77,8 +77,7 @@ Configure Designate options in ``/etc/kolla/passwords.yml``
designate_infoblox_auth_password: "password"
For more information about how the Infoblox backend works, see
`Infoblox backend
<https://docs.openstack.org/designate/latest/admin/backends/infoblox.html>`__.
:designate-doc:`Infoblox backend <admin/backends/infoblox.html>`.
Neutron and Nova Integration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6
doc/source/reference/networking/neutron-extensions.rst
View File

@ -20,8 +20,8 @@ Verification
------------
For setting up a testbed environment and creating a port chain, please refer
to `networking-sfc documentation
<https://docs.openstack.org/networking-sfc/latest/contributor/system_design_and_workflow.html>`__.
to :networking-sfc-doc:`networking-sfc documentation
<contributor/system_design_and_workflow.html>`.
Neutron VPNaaS (VPN-as-a-Service)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -76,5 +76,5 @@ Two VMs can now be booted, one on vpn_east, the other on vpn_west, and
encrypted ping packets observed being sent from one to the other.
For more information on this and VPNaaS in Neutron refer to the
`Neutron VPNaaS Testing <https://docs.openstack.org/neutron-vpnaas/latest/contributor/index.html#testing>`__
:neutron-vpnaas-doc:`Neutron VPNaaS Testing <contributor/index.html#testing>`
and the `OpenStack wiki <https://wiki.openstack.org/wiki/Neutron/VPNaaS>`_.

8
doc/source/reference/networking/sriov.rst
View File

@ -165,8 +165,8 @@ dmesg on the compute node where the instance was placed.
[ 2896.850028] ixgbe 0000:05:00.0: Setting VLAN 1000, QOS 0x0 on VF 3
[ 2897.403367] vfio-pci 0000:05:10.4: enabling device (0000 -> 0002)
For more information see `OpenStack SRIOV documentation
<https://docs.openstack.org/neutron/latest/admin/config-sriov.html>`_.
For more information see :neutron-doc:`OpenStack SRIOV documentation
<admin/config-sriov.html>`.
Nova SRIOV
~~~~~~~~~~
@ -222,5 +222,5 @@ Start a new instance using the flavor:
Verify VF devices were created and the instance starts successfully as in
the Neutron SRIOV case.
For more information see `OpenStack PCI passthrough documentation
<https://docs.openstack.org/nova/latest/admin/pci-passthrough.html>`_.
For more information see :nova-doc:`OpenStack PCI passthrough documentation
<admin/pci-passthrough.html>`.

4
doc/source/reference/shared-services/glance-guide.rst
View File

@ -144,5 +144,5 @@ Glance cache is disabled by default, it can be enabled by:
Glance caches are not cleaned up automatically, the glance team recommends to
use a cron service to regularly clean cached images. In the future kolla will
deploy a cron container to manage such clean ups. Please refer to `Glance
image cache <https://docs.openstack.org/glance/latest/admin/cache.html>`__.
deploy a cron container to manage such clean ups. Please refer to
:glance-doc:`Glance image cache <admin/cache.html>`.

5
doc/source/reference/shared-services/keystone-guide.rst
View File

@ -38,6 +38,5 @@ a buffer key - three in total. If the rotation interval is set lower than the
sum of the token expiry and token allow expired window, more active keys will
be configured in Keystone as necessary.
Further infomation on Fernet tokens is available in the `Keystone
documentation
<https://docs.openstack.org/keystone/stein/admin/fernet-token-faq.html>`__.
Further infomation on Fernet tokens is available in the :keystone-doc:`Keystone
documentation <admin/fernet-token-faq.html>`.

4
doc/source/reference/storage/cinder-guide-hnas.rst
View File

@ -237,8 +237,8 @@ Verify Operation.
+--------------------------------------+---------------+----------------+------+-------------------------------------------+
For more information about how to manage volumes, see the
`Manage volumes
<https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html>`__.
:cinder-doc:`Manage volumes
<cli/cli-manage-volumes.html>`.
For more information about how HNAS driver works, see
`Hitachi NAS Platform iSCSI and NFS drives for OpenStack

4
doc/source/reference/storage/cinder-guide-quobyte.rst
View File

@ -23,7 +23,7 @@ registry and the Quobyte volume respectively.
Since ``Quobyte`` is proprietary software that requires a license, the use of
this backend requires the ``Quobyte`` Client software package to be installed
in the ``cinder-volume`` and ``nova-compute`` containers. To do this follow the
steps outlined in the `kolla image building guide
<https://docs.openstack.org/kolla/latest/admin/image-building.html>`__,
steps outlined in the :kolla-doc:`Building Container Images
<admin/image-building.html>`,
particularly the ``Package Customisation`` and ``Custom Repos`` sections. The
repository information is available in the ``Quobyte`` customer portal.

4
doc/source/reference/storage/external-ceph-guide.rst
View File

@ -282,5 +282,5 @@ in Ceph) into the same directory, for example:
For more details on the rest of the Manila setup, such as creating the share
type ``default_share_type``, please see :doc:`Manila in Kolla <manila-guide>`.
For more details on the CephFS Native driver, please see `CephFS driver
<https://docs.openstack.org/manila/latest/admin/cephfs_driver.html>`__.
For more details on the CephFS Native driver, please see
:manila-doc:`CephFS driver <admin/cephfs_driver.html>`.

3
doc/source/reference/storage/manila-guide.rst
View File

@ -361,5 +361,4 @@ Use the :command:`manila migration-complete shareID` command to complete share
migration process.
For more information about how to manage shares, see the
`Manage shares
<https://docs.openstack.org/manila/latest/user/create-and-manage-shares.html>`__.
:manila-doc:`Manage shares <user/create-and-manage-shares.html>`.

7
doc/source/reference/storage/manila-hnas-guide.rst
View File

@ -323,9 +323,8 @@ Modify the file ``/etc/kolla/config/manila-share.conf`` and add the contents:
hitachi_hnas_file_system_name = FS-Manila2
For more information about how to manage shares, see the
`Manage shares
<https://docs.openstack.org/manila/latest/user/create-and-manage-shares.html>`__.
:manila-doc:`Manage shares <user/create-and-manage-shares.html>`.
For more information about how HNAS driver works, see
`Hitachi NAS Platform File Services Driver for OpenStack
<https://docs.openstack.org/manila/latest/admin/hitachi_hnas_driver.html>`__.
:manila-doc:`Hitachi NAS Platform File Services Driver for OpenStack
<admin/hitachi_hnas_driver.html>`.

10
doc/source/reference/storage/swift-guide.rst
View File

@ -94,9 +94,9 @@ table** example listed above. Please modify accordingly if your setup is
different.
If using a separate replication network it is necessary to add the replication
network IP addresses to the rings. See the `Swift documentation
<https://docs.openstack.org/swift/latest/replication_network.html#dedicated-replication-network>`__
for details on how to do that.
network IP addresses to the rings. See the :swift-doc:`Swift documentation
<replication_network.html#dedicated-replication-network>` for details on
how to do that.
Prepare for Rings generating
----------------------------
@ -203,8 +203,8 @@ To rebalance the ring files:
/etc/kolla/config/swift/${ring}.builder rebalance;
done
For more information, see `the Swift documentation
<https://docs.openstack.org/swift/latest/install/initial-rings.html>`__.
For more information, see :swift-doc:`the Swift documentation
<install/initial-rings.html>`.
Deploying
~~~~~~~~~

15
doc/source/user/quickstart.rst
View File

@ -367,8 +367,8 @@ There are a few options that are required to deploy Kolla-Ansible:
User has to specify images that are going to be used for our deployment.
In this guide `DockerHub <https://hub.docker.com/u/kolla/>`__ provided
pre-built images are going to be used. To learn more about building
mechanism, please refer `image building documentation
<https://docs.openstack.org/kolla/latest/admin/image-building.html>`_.
mechanism, please refer :kolla-doc:`Building Container Images
<admin/image-building.html>`.
Kolla provides choice of several Linux distributions in containers:
@ -444,8 +444,9 @@ There are a few options that are required to deploy Kolla-Ansible:
neutron_external_interface: "eth1"
To learn more about network configuration, refer `Network overview
<https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html#network-configuration>`_.
To learn more about network configuration, refer
:kolla-ansible-doc:`Network overview
<admin/production-architecture-guide.html#network-configuration>`.
Next we need to provide floating IP for management traffic. This IP will be
managed by keepalived to provide high availability, and should be set to be
@ -470,8 +471,8 @@ There are a few options that are required to deploy Kolla-Ansible:
`a list of available services
<https://github.com/openstack/kolla-ansible/blob/master/README.rst#openstack-services>`_.
For more information about service configuration, Please refer to the
`Services Reference Guide
<https://docs.openstack.org/kolla-ansible/latest/reference/index.html>`_.
:kolla-ansible-doc:`Services Reference Guide
<reference/index.html>`.
* Virtual environment
@ -535,7 +536,7 @@ accordingly.
When this playbook finishes, OpenStack should be up, running and functional!
If error occurs during execution, refer to
`troubleshooting guide <https://docs.openstack.org/kolla-ansible/latest/user/troubleshooting.html>`_.
:kolla-ansible-doc:`troubleshooting guide <user/troubleshooting.html>`.
Using OpenStack
~~~~~~~~~~~~~~~

3
specs/containerize-openstack.rst
View File

@ -194,8 +194,7 @@ A different motive for not using EXPOSE is the 20 microsecond penalty
applied to every packet forwarded and returned by docker-proxy.
If EXPOSE functionality is desired, it can be added back by
referencing the default list of OpenStack ports to each Dockerfile:
https://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html
`Firewalls and default ports <https://docs.openstack.org/install-guide/firewalls-default-ports.html>`__.
We will use the docker flag --restart=always to provide some measure of
high availability for the individual containers and ensure they operate