openstack/neutron-dynamic-routing
Code Issues Proposed changes

Fix broken doc links

Browse Source 
This patch fixes broken doc links as follows:
- Removes the ref to generate the 'modindex' as this only
applies to source that provides module level documentation
with class refs. For example [1]. Today we don't have any such
module doc in this project; and thus this generates a dead link.
It can be added later (if needed) and the modindex ref can be
added back in.
- Fixes various internal links that are using '.rst'; this needs to be
'.html' in order to link to the generated doc html files.
- Fixes an incorrect link; missing a space and has an unneeded
leading underscore.

For more details please see the bug report associated with this
fix.

[1] https://github.com/openstack/neutron/blob/
master/neutron/neutron_plugin_base_v2.py#L19

Change-Id: I12e227ae1a3682a7268b75c844825d3f7464941b
Closes-Bug: #1656403
This commit is contained in:
Boden R 2017-01-30 07:06:38 -07:00
parent f74bc509bd
commit 9869b08da5
2 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
doc/source/functionality/bgp-speaker.rst
View File

@ -26,8 +26,8 @@ BGP Speaker
===========
BGP Speaker acts as a route server using BGP routing protocol. It advertises
routes to the BGP peers which are added to the BGP Speaker. Now there is a
framework that allows different `BGP drivers <../design/drivers.rst>`_
to be plugged into a `dynamic routing agent <./dynamic-routing-agent.rst>`_.
framework that allows different `BGP drivers <../design/drivers.html>`_
to be plugged into a `dynamic routing agent <../design/agent-scheduler.html>`_.
Currently, BGP Speaker only advertises routes for a network to which it is associated.
A BGP Speaker requires association with a "gateway" network to determine eligible routes.
@ -36,7 +36,7 @@ external network is best for being used as a gateway network. The association bu
list of all virtual routers with gateways on provider and self-service networks within
the same address scope. Hence, the BGP speaker advertises self-service network prefixes
with the corresponding router as the next-hop IP address.
For details refer to `Route advertisement <./route-advertisement.rst>`_.
For details refer to `Route advertisement <./route-advertisement.html>`_.
Address Scopes
--------------
@ -119,12 +119,12 @@ A Sample Quagga router configuration file forming BGP peering with Neutron:
BGP Speaker Architecture
------------------------
Dynamic routing project saves BGP Speaker configuration as per the defined
`_data model<https://git.openstack.org/cgit/openstack/neutron-dynamic-routing/tree/neutron_dynamic_routing/db/bgp_db.py#n85>`_.
`data model <https://git.openstack.org/cgit/openstack/neutron-dynamic-routing/tree/neutron_dynamic_routing/db/bgp_db.py#n85>`_.
and pass on the configuration request to the dynamic routing agent for further processing.
The implementation of a BGP Speaker is driver specific. During the driver interface
initialization process, needed configurations are read from the configuration file
and BGP Speaker object instance is created. For details refer to
`BGP drivers <../design/drivers.rst>`_.
`BGP drivers <../design/drivers.html>`_.
BGP Speaker Life Cycle
~~~~~~~~~~~~~~~~~~~~~~
@ -160,8 +160,8 @@ BGP Plugin just send rpc ``bgp_speaker_remove_end`` to the specific Dragent.
Advertisement
~~~~~~~~~~~~~
For details refer to `Route Advertisement <./route-advertisement.rst>`_.
For details refer to `Route Advertisement <./route-advertisement.html>`_.
How to work
-----------
For details refer to `Testing <../others/testing.rst>`_.
For details refer to `Testing <../others/testing.html>`_.

1
doc/source/index.rst
View File

@ -79,5 +79,4 @@ Indices and tables
==================
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`