openstack/neutron
Code Issues Proposed changes

Fix broken references in doc

Browse Source 
Change-Id: Iaaa8a064163500d1bd8a7249b2efcda2f10937b5
This commit is contained in:
Akihiro Motoki 2015-11-12 22:57:05 +09:00
parent abb73191ae
commit 4e5ee54af6
2 changed files with 12 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/source/devref/rpc_callbacks.rst
View File

@ -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:

17
doc/source/policies/thirdparty-ci.rst
View File

@ -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