diff --git a/TESTING.rst b/TESTING.rst index 4568eaaac93..662b31c33f7 100644 --- a/TESTING.rst +++ b/TESTING.rst @@ -679,6 +679,4 @@ with pdb:: 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