Fix broken references in doc

Change-Id: Iaaa8a064163500d1bd8a7249b2efcda2f10937b5

diff --git a/doc/source/devref/rpc_callbacks.rst b/doc/source/devref/rpc_callbacks.rst
index 97ca772aec44a1f7b2bc5b9eeacd25ccb8c32d5e..1438367437cf119d6d0f25e22b6f4b7a4da7a80e 100644 (file)
--- a/doc/source/devref/rpc_callbacks.rst
+++ b/doc/source/devref/rpc_callbacks.rst
@@ -24,7 +24,7 @@
 Neutron Messaging Callback System
 =================================
 
-Neutron already has a callback system [link-to: callbacks.rst] for
+Neutron already has a :doc:`callback system <callbacks>` for
 in-process resource callbacks where publishers and subscribers are able
 to publish and subscribe for resource events.
 
@@ -55,12 +55,12 @@ agent.
 This publishing/subscription mechanism is highly dependent on the format
 of the resources passed around. This is why the library only allows
 versioned objects to be published and subscribed. Oslo versioned objects
-allow object version down/up conversion. #[vo_mkcompat]_ #[vo_mkcptests]_
+allow object version down/up conversion. [#vo_mkcompat]_ [#vo_mkcptests]_
 
-For the VO's versioning schema look here: #[vo_versioning]_
+For the VO's versioning schema look here: [#vo_versioning]_
 
 versioned_objects serialization/deserialization with the
-obj_to_primitive(target_version=..) and primitive_to_obj() #[ov_serdes]_
+obj_to_primitive(target_version=..) and primitive_to_obj() [#ov_serdes]_
 methods is used internally to convert/retrieve objects before/after messaging.
 
 Considering rolling upgrades, there are several scenarios to look at:

diff --git a/doc/source/policies/thirdparty-ci.rst b/doc/source/policies/thirdparty-ci.rst
index 1e4ecc7bdb8eb0d0075e1b2a92eda4f2fbfb8563..637d364d76eeedbe18dc67ab739760b19d1ea028 100644 (file)
--- a/doc/source/policies/thirdparty-ci.rst
+++ b/doc/source/policies/thirdparty-ci.rst
@@ -9,25 +9,22 @@ but it is strongly encouraged, as internal neutron refactoring can break
 external plugins and drivers at any time.
 
 Neutron expects any Third Party CI system that interacts with gerrit to
-follow the requirements set by the Infrastructure team[1] as well as the
+follow the requirements set by the Infrastructure team [1]_ as well as the
 Neutron Third Party CI guidelines below. Please ping the PTL in
 #openstack-neutron or send an email to the openstack-dev ML (with subject
 [neutron]) with any questions. Be aware that the Infrastructure documentation
 as well as this document are living documents and undergo changes. Track
-changes to the infrastructure documentation using this url[2] (and please
+changes to the infrastructure documentation using this url [2]_ (and please
 review the patches) and check this doc on a regular basis for updates.
 
-[1] http://ci.openstack.org/third_party.html
-[2] https://review.openstack.org/#/q/status:open+project:openstack-infra/system-config+branch:master+topic:third-party,n,z
-
 What Changes to Run Against
 ---------------------------
 
 If your code is a neutron plugin or driver, you should run against every
 neutron change submitted, except for docs, tests, tools, and top-level
-setup files. You can see a programmatic example of the exceptions here[3].
-
-[3] https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L568
+setup files. You can skip your CI runs for such exceptions by using
+``skip-if`` and ``all-files-match-any`` directives in Zuul.
+You can see a programmatic example of the exceptions here [3]_.
 
 If your code is in a neutron-\*aas repo, you should run against the tests
 for that repo. You may also run against every neutron change, if your service
@@ -131,4 +128,6 @@ https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin_and_
 References
 ----------
 
-[1] https://review.openstack.org/#/c/187267
+.. [1] http://ci.openstack.org/third_party.html
+.. [2] https://review.openstack.org/#/q/status:open+project:openstack-infra/system-config+branch:master+topic:third-party,n,z
+.. [3] https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml