diff --git a/TESTING.rst b/TESTING.rst index dd2b6eae125..b0184d6504c 100644 --- a/TESTING.rst +++ b/TESTING.rst @@ -626,6 +626,4 @@ TBD: how to do this with tox. References ~~~~~~~~~~ -.. [#pudb] PUDB debugger: - https://pypi.python.org/pypi/pudb .. _file-based-sqlite: http://lists.openstack.org/pipermail/openstack-dev/2016-July/099861.html diff --git a/doc/source/devref/provisioning_blocks.rst b/doc/source/devref/provisioning_blocks.rst index e5f764c05d1..ed8ef8df799 100644 --- a/doc/source/devref/provisioning_blocks.rst +++ b/doc/source/devref/provisioning_blocks.rst @@ -32,8 +32,10 @@ When that entity has finishing provisioning, we just update the STATUS directly to active. However, there are resources in Neutron that require provisioning by multiple asynchronous entities before they are ready to be used so managing the transition to the ACTIVE status becomes more -complex. To handle these cases, Neutron has the provisioning_blocks -module to track the entities that are still provisioning a resource. +complex. To handle these cases, Neutron has `the provisioning_blocks +module +`_ +to track the entities that are still provisioning a resource. The main example of this is with ML2, the L2 agents and the DHCP agents. When a port is created and bound to a host, it's placed in the DOWN @@ -151,9 +153,3 @@ the port is deleted or it is successful. If an ML2 driver immediately places a bound port in the ACTIVE state (e.g. after calling a backend in update_port_postcommit), this patch will not have any impact on that process. - - -References ----------- - -.. [#] Provisioning Blocks Module: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/provisioning_blocks.py