Replace git.openstack.org URLs with opendev.org URLs

Thorough replacement of git.openstack.org URLs with their opendev.org
counterparts.

Change-Id: Ifc446e00d7f69cb23411b3a50c8d880c719f1e73

TESTING.rst

@@ -518,7 +518,7 @@ environment variable to point at a local package repo.
 For example, to run against the 'master' branch of neutron-lib:
 
     cd $SRC
-    git clone https://git.openstack.org/openstack/neutron-lib
+    git clone https://opendev.org/openstack/neutron-lib
     cd $NEUTRON_DIR
     env TOX_ENV_SRC_MODULES=$SRC/neutron-lib tox -r -e pep8,py27
 
@@ -529,9 +529,9 @@ To run against a particular gerrit change of the lib (substituting the
 desired gerrit refs for this example):
 
     cd $SRC
-    git clone https://git.openstack.org/openstack/neutron-lib
+    git clone https://opendev.org/openstack/neutron-lib
     cd neutron-lib
-    git fetch https://git.openstack.org/openstack/neutron-lib refs/changes/13/635313/6 && git checkout FETCH_HEAD
+    git fetch https://opendev.org/openstack/neutron-lib refs/changes/13/635313/6 && git checkout FETCH_HEAD
     cd $NEUTRON_DIR
     env TOX_ENV_SRC_MODULES=$SRC/neutron-lib tox -r -e pep8,py27
 
@@ -562,7 +562,7 @@ script requires sudo privileges and it is recommended that the
 following commands be invoked only on a clean and disposable VM.
 A VM that has had DevStack previously installed on it is also fine. ::
 
-    git clone https://git.openstack.org/openstack-dev/devstack ../devstack
+    git clone https://opendev.org/openstack/devstack ../devstack
     ./tools/configure_for_func_testing.sh ../devstack -i
     tox -e dsvm-functional
 
@@ -675,9 +675,9 @@ doc/source/devref/testing_coverage.rst. You could also rely on Zuul
 logs, that are generated post-merge (not every project builds coverage
 results). To access them, do the following:
 
-* Check out the latest `merge commit <https://review.openstack.org/gitweb?p=openstack/neutron.git;a=search;s=Jenkins;st=author>`_
+* Check out the latest `merge commit <https://review.opendev.org/#/q/project:openstack/neutron+status:merged>`_
 * Go to: http://logs.openstack.org/<first-2-digits-of-sha1>/<sha1>/post/neutron-coverage/.
-* `Spec <https://review.openstack.org/#/c/221494/>`_ is a work in progress to
+* `Spec <https://review.opendev.org/#/c/221494/>`_ is a work in progress to
   provide a better landing page.
 
 Debugging

doc/source/admin/archives/config-agents.rst

@@ -433,7 +433,7 @@ correctly using these
    .. code-block:: console
 
       > cd C:\OpenStack\
-      > git clone https://git.openstack.org/openstack/neutron
+      > git clone https://opendev.org/openstack/neutron
 
 #. Install the OpenStack Networking Hyper-V Agent:
 

doc/source/admin/config-lbaas.rst

@@ -174,13 +174,13 @@ The Dashboard panels for managing LBaaS v2 are available starting with the
 Mitaka release.
 
 #.  Clone the `neutron-lbaas-dashboard repository
-    <https://git.openstack.org/cgit/openstack/neutron-lbaas-dashboard/>`__
+    <https://opendev.org/openstack/neutron-lbaas-dashboard/>`__
     and check out the release
     branch that matches the installed version of Dashboard:
 
     .. code-block:: console
 
-       $ git clone https://git.openstack.org/openstack/neutron-lbaas-dashboard
+       $ git clone https://opendev.org/openstack/neutron-lbaas-dashboard
        $ cd neutron-lbaas-dashboard
        $ git checkout OPENSTACK_RELEASE
 

doc/source/admin/config-qos-min-bw.rst

@@ -560,14 +560,14 @@ Links
 * Neutron spec: QoS minimum bandwidth allocation in Placement API
 
   * `on specs.openstack.org <https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html>`__
-  * `on review.openstack.org <https://review.openstack.org/508149>`__
+  * `on review.opendev.org <https://review.opendev.org/508149>`__
 
 * Nova spec: Network Bandwidth resource provider
 
   * `on specs.openstack.org
     <https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/bandwidth-resource-provider.html>`__
-  * `on review.openstack.org
+  * `on review.opendev.org
-    <https://review.openstack.org/502306>`__
+    <https://review.opendev.org/502306>`__
 
 * Relevant OpenStack Networking API references
 
@@ -584,8 +584,8 @@ Links
 
 * Implementation
 
-  * `on review.openstack.org
+  * `on review.opendev.org
-    <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placement-api+OR+topic:bp/bandwidth-resource-provider>`_
+    <https://review.opendev.org/#/q/topic:minimum-bandwidth-allocation-placement-api+OR+topic:bp/bandwidth-resource-provider>`_
 
 * Known Bugs
 

doc/source/admin/config-qos.rst

@@ -30,7 +30,7 @@ Supported QoS rule types
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 QoS supported rule types are now available as ``VALID_RULE_TYPES`` in `QoS rule types
-<https://git.openstack.org/cgit/openstack/neutron-lib/tree/neutron_lib/services/qos/constants.py>`_:
+<https://opendev.org/openstack/neutron-lib/tree/neutron_lib/services/qos/constants.py>`_:
 
 * bandwidth_limit: Bandwidth limitations on networks, ports or floating IPs.
 

doc/source/contributor/alembic_migrations.rst

@@ -491,7 +491,7 @@ When named release (liberty, mitaka, etc.) is done for neutron or a
 sub-project, the alembic revision scripts at the head of each branch for that
 release must be tagged. This is referred to as a milestone revision tag.
 
-For example, `here <https://review.openstack.org/228272>`_ is a patch that tags
+For example, `here <https://review.opendev.org/228272>`_ is a patch that tags
 the liberty milestone revisions for the neutron-fwaas sub-project. Note that
 each branch (expand and contract) is tagged.
 

doc/source/contributor/contribute.rst

@@ -63,7 +63,7 @@ In the Mitaka cycle we will **require** all third-party code to be moved out of
 the neutron tree completely.
 
 'Outside the tree' can be anything that is publicly available: it may be a repo
-on git.openstack.org for instance, a tarball, a pypi package, etc. A
+on opendev.org for instance, a tarball, a pypi package, etc. A
 plugin/drivers maintainer team self-governs in order to promote sharing, reuse,
 innovation, and release of the 'out-of-tree' deliverable. It should not be
 required for any member of the core team to be involved with this process,
@@ -103,7 +103,7 @@ participate in the principles of the Four Opens, meaning your design should be
 done in the open. Thus, it is encouraged to file documentation for changes in
 your own repository.
 
-If your code is hosted on git.openstack.org then the gerrit review system is
+If your code is hosted on opendev.org then the gerrit review system is
 automatically provided. Contributors should follow the review guidelines
 similar to those of Neutron. However, you as the maintainer have the
 flexibility to choose who can approve/merge changes in your own repo.
@@ -132,7 +132,7 @@ quickly their code can fall out of sync with the rapidly changing Neutron core
 code base.
 
 * You should run unit tests in your own external library (e.g. on
-  git.openstack.org where Jenkins setup is for free).
+  opendev.org where Jenkins setup is for free).
 
 * Your third-party CI should validate third-party integration with Neutron via
   functional testing. The third-party CI is a communication mechanism. The
@@ -152,7 +152,7 @@ code base.
     third-party CI jobs is likely to generate community goodwill.
 
   It is worth noting that if the plugin/driver repository is hosted on
-  git.openstack.org, due to current openstack-infra limitations, it is not
+  opendev.org, due to current openstack-infra limitations, it is not
   possible to have third-party CI systems participating in the gate pipeline
   for the repo. This means that the only validation provided during the merge
   process to the repo is through unit tests. Post-merge hooks can still be
@@ -266,12 +266,12 @@ third-party integration library, and it leads to the greatest level of
 flexibility when dealing with DevStack based dev/test deployments.
 
 One final consideration is worth making for third-party CI setups: if `Devstack
-Gate <https://git.openstack.org/cgit/openstack-infra/devstack-gate>`_ is used,
+Gate <https://opendev.org/openstack/devstack-gate>`_ is used,
 it does provide hook functions that can be executed at specific times of the
 devstack-gate-wrap script run.  For example, the `Neutron Functional job
-<https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/neutron.yaml>`_
+<https://opendev.org/openstack/project-config/tree/jenkins/jobs/neutron.yaml>`_
 uses them. For more details see `devstack-vm-gate-wrap.sh
-<https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh>`_.
+<https://opendev.org/openstack/devstack-gate/tree/devstack-vm-gate-wrap.sh>`_.
 
 
 Documentation
@@ -285,25 +285,25 @@ Project Initial Setup
 ---------------------
 
 The how-to below assumes that the third-party library will be hosted on
-git.openstack.org. This lets you tap in the entire OpenStack CI infrastructure
+opendev.org. This lets you tap in the entire OpenStack CI infrastructure
 and can be a great place to start from to contribute your new or existing
 driver/plugin. The list of steps below are summarized version of what you can
 find on http://docs.openstack.org/infra/manual/creators.html. They are meant to
 be the bare minimum you have to complete in order to get you off the ground.
 
-* Create a public repository: this can be a personal git.openstack.org repo or any
+* Create a public repository: this can be a personal opendev.org repo or any
   publicly available git repo, e.g. ``https://github.com/john-doe/foo.git``. This
-  would be a temporary buffer to be used to feed the one on git.openstack.org.
+  would be a temporary buffer to be used to feed the one on opendev.org.
 * Initialize the repository: if you are starting afresh, you may *optionally*
   want to use cookiecutter to get a skeleton project. You can learn how to use
-  cookiecutter on https://git.openstack.org/cgit/openstack-dev/cookiecutter.
+  cookiecutter on https://opendev.org/openstack-dev/cookiecutter.
   If you want to build the repository from an existing Neutron module, you may
   want to skip this step now, build the history first (next step), and come back
   here to initialize the remainder of the repository with other files being
   generated by the cookiecutter (like tox.ini, setup.cfg, setup.py, etc.).
-* Create a repository on git.openstack.org. For
+* Create a repository on opendev.org. For
   this you need the help of the OpenStack infra team. It is worth noting that
-  you only get one shot at creating the repository on git.openstack.org. This
+  you only get one shot at creating the repository on opendev.org. This
   is the time you get to choose whether you want to start from a clean slate,
   or you want to import the repo created during the previous step. In the
   latter case, you can do so by specifying the upstream section for your
@@ -314,12 +314,12 @@ be the bare minimum you have to complete in order to get you off the ground.
   documented in `this section
   <http://docs.openstack.org/infra/manual/creators.html#update-the-gerrit-group-members>`_.
 * Fix, fix, fix: at this point you have an external base to work on. You can
-  develop against the new git.openstack.org project, the same way you work with
+  develop against the new opendev.org project, the same way you work with
   any other OpenStack project: you have pep8, docs, and python27 CI jobs that
   validate your patches when posted to Gerrit. For instance, one thing you
   would need to do is to define an entry point for your plugin or driver in
   your own setup.cfg similarly as to how it is done in the `setup.cfg for ODL
-  <https://git.openstack.org/cgit/openstack/networking-odl/tree/setup.cfg#n31>`_.
+  <https://opendev.org/openstack/networking-odl/tree/setup.cfg#n31>`_.
 * Define an entry point for your plugin or driver in setup.cfg
 * Create third-party CI account: if you do not already have one, follow
   instructions for `third-party CI
@@ -367,7 +367,7 @@ You need to create or edit the following files to start translation support:
 * babel.cfg
 
 We have a good example for an oslo project at
-https://review.openstack.org/#/c/98248/.
+https://review.opendev.org/#/c/98248/.
 
 Add the following to ``setup.cfg``::
 
@@ -395,7 +395,7 @@ Enable Translation
 ~~~~~~~~~~~~~~~~~~
 
 To update and import translations, you need to make a change in project-config.
-A good example is found at https://review.openstack.org/#/c/224222/.
+A good example is found at https://review.opendev.org/#/c/224222/.
 After doing this, the necessary jobs will be run and push/pull a
 message catalog to/from the translation infrastructure.
 
@@ -579,7 +579,7 @@ the installer to configure this item in the ``[default]`` section. For example::
     to be registered by external interface drivers. For Nova, selecting the VIF
     driver can be done outside of
     Neutron (using the new `os-vif python library
-    <https://review.openstack.org/193668>`_?). Armando and Akihiro to discuss.
+    <https://review.opendev.org/193668>`_?). Armando and Akihiro to discuss.
 
 
 Rootwrap Filters
@@ -605,7 +605,7 @@ Extending python-neutronclient
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The maintainer of a third-party component may wish to add extensions to the
-Neutron CLI client. Thanks to https://review.openstack.org/148318 this can now
+Neutron CLI client. Thanks to https://review.opendev.org/148318 this can now
 be accomplished. See `Client Command Extensions
 <client_command_extensions.html>`_.
 

doc/source/contributor/dashboards/index.rst

@@ -4,10 +4,10 @@ CI Status Dashboards
 Gerrit Dashboards
 -----------------
 
-- `Neutron master branch reviews <https://review.openstack.org/#/dashboard/?title=Neutron+Review+Inbox+%28master+branch+only%29&foreach=%28project%3Aopenstack%2Fneutron+OR%0Aproject%3Aopenstack%2Fneutron%2Dlib+OR%0Aproject%3Aopenstack%2Fneutron%2Dtempest%2Dplugin+OR%0Aproject%3Aopenstack%2Fpython%2Dneutronclient+OR%0Aproject%3Aopenstack%2Fneutron%2Dspecs%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself+branch%3Amaster&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Passed+Zuul%2C+No+Negative+Core+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A2d>`_
+- `Neutron master branch reviews <https://review.opendev.org/#/dashboard/?title=Neutron+Review+Inbox+%28master+branch+only%29&foreach=%28project%3Aopenstack%2Fneutron+OR%0Aproject%3Aopenstack%2Fneutron%2Dlib+OR%0Aproject%3Aopenstack%2Fneutron%2Dtempest%2Dplugin+OR%0Aproject%3Aopenstack%2Fpython%2Dneutronclient+OR%0Aproject%3Aopenstack%2Fneutron%2Dspecs%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself+branch%3Amaster&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Passed+Zuul%2C+No+Negative+Core+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A2d>`_
-- `Neutron subproject reviews (master branch) <https://review.openstack.org/#/dashboard/?title=Neutron+Sub+Projects+Review+Inbox&foreach=%28%0Aproject%3Aopenstack%2Fnetworking%2Dbagpipe+OR%0Aproject%3Aopenstack%2Fnetworking%2Dbgpvpn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dmidonet+OR%0Aproject%3Aopenstack%2Fnetworking%2Dodl+OR%0Aproject%3Aopenstack%2Fnetworking%2Dovn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dsfc+OR%0Aproject%3Aopenstack%2Fneutron%2Ddynamic%2Drouting+OR%0Aproject%3Aopenstack%2Fneutron%2Dfwaas+OR%0Aproject%3Aopenstack%2Fneutron%2Dvpnaas+OR%0Aproject%3Aopenstack%2Fovsdbapp%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself+branch%3Amaster&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Passed+Zuul%2C+No+Negative+Core+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A2d>`_
+- `Neutron subproject reviews (master branch) <https://review.opendev.org/#/dashboard/?title=Neutron+Sub+Projects+Review+Inbox&foreach=%28%0Aproject%3Aopenstack%2Fnetworking%2Dbagpipe+OR%0Aproject%3Aopenstack%2Fnetworking%2Dbgpvpn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dmidonet+OR%0Aproject%3Aopenstack%2Fnetworking%2Dodl+OR%0Aproject%3Aopenstack%2Fnetworking%2Dovn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dsfc+OR%0Aproject%3Aopenstack%2Fneutron%2Ddynamic%2Drouting+OR%0Aproject%3Aopenstack%2Fneutron%2Dfwaas+OR%0Aproject%3Aopenstack%2Fneutron%2Dvpnaas+OR%0Aproject%3Aopenstack%2Fovsdbapp%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself+branch%3Amaster&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Passed+Zuul%2C+No+Negative+Core+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dcore+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A2d>`_
-- `Neutron stable branch reviews <https://review.openstack.org/#/dashboard/?title=Neutron+Stable+Related+Projects+Review+Inbox&foreach=%28%0Aproject%3Aopenstack%2Fnetworking%2Dbagpipe+OR%0Aproject%3Aopenstack%2Fnetworking%2Dbgpvpn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dmidonet+OR%0Aproject%3Aopenstack%2Fnetworking%2Dodl+OR%0Aproject%3Aopenstack%2Fnetworking%2Dovn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dsfc+OR%0Aproject%3Aopenstack%2Fneutron+OR%0Aproject%3Aopenstack%2Fneutron%2Ddynamic%2Drouting+OR%0Aproject%3Aopenstack%2Fneutron%2Dfwaas+OR%0Aproject%3Aopenstack%2Fneutron%2Dvpnaas+OR%0Aproject%3Aopenstack%2Fneutron%2Dlib+OR%0Aproject%3Aopenstack%2Fovsdbapp+OR%0Aproject%3Aopenstack%2Fpython%2Dneutronclient%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself+branch%3A%5Estable%2F.%2A&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dstable%2Dmaint+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Passed+Zuul%2C+No+Negative+Core+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dstable%2Dmaint+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A2d>`_
+- `Neutron stable branch reviews <https://review.opendev.org/#/dashboard/?title=Neutron+Stable+Related+Projects+Review+Inbox&foreach=%28%0Aproject%3Aopenstack%2Fnetworking%2Dbagpipe+OR%0Aproject%3Aopenstack%2Fnetworking%2Dbgpvpn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dmidonet+OR%0Aproject%3Aopenstack%2Fnetworking%2Dodl+OR%0Aproject%3Aopenstack%2Fnetworking%2Dovn+OR%0Aproject%3Aopenstack%2Fnetworking%2Dsfc+OR%0Aproject%3Aopenstack%2Fneutron+OR%0Aproject%3Aopenstack%2Fneutron%2Ddynamic%2Drouting+OR%0Aproject%3Aopenstack%2Fneutron%2Dfwaas+OR%0Aproject%3Aopenstack%2Fneutron%2Dvpnaas+OR%0Aproject%3Aopenstack%2Fneutron%2Dlib+OR%0Aproject%3Aopenstack%2Fovsdbapp+OR%0Aproject%3Aopenstack%2Fpython%2Dneutronclient%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself+branch%3A%5Estable%2F.%2A&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself+reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dstable%2Dmaint+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Passed+Zuul%2C+No+Negative+Core+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT%28reviewerin%3Aneutron%2Dstable%2Dmaint+label%3ACode%2DReview%3C%3D%2D1%29+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D1+age%3A2d>`_
-- `Neutron Infra reviews <https://review.openstack.org/#/dashboard/?title=Neutron+Infra+Review+Inbox&foreach=%28project%3Aopenstack%2Dinfra%2Fproject%2Dconfig+OR+project%3Aopenstack%2Dinfra%2Fopenstack%2Dzuul%2Djobs+OR+project%3Aopenstack%2Dinfra%2Fdevstack%2Dgate%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself&Neutron+related+infra+reviews=%28message%3A%22neutron%22+OR+message%3A%22networking%2D%22+OR+message%3A%22n8g%2D%22+OR+message%3A%22ovsdbapp%22+OR+%28comment%3A%22neutron%22+%28comment%3A%22liaison%22+OR+comment%3A%22liason%22%29%29%29>`_
+- `Neutron Infra reviews <https://review.opendev.org/#/dashboard/?title=Neutron+Infra+Review+Inbox&foreach=%28project%3Aopenstack%2Dinfra%2Fproject%2Dconfig+OR+project%3Aopenstack%2Dinfra%2Fopenstack%2Dzuul%2Djobs+OR+project%3Aopenstack%2Dinfra%2Fdevstack%2Dgate%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Czuul+NOT+reviewedby%3Aself&Neutron+related+infra+reviews=%28message%3A%22neutron%22+OR+message%3A%22networking%2D%22+OR+message%3A%22n8g%2D%22+OR+message%3A%22ovsdbapp%22+OR+%28comment%3A%22neutron%22+%28comment%3A%22liaison%22+OR+comment%3A%22liason%22%29%29%29>`_
 
 These dashboard links can be generated by `Gerrit Dashboard Creator`_.
 Useful dashboard definitions are found in ``dashboards`` directory.

doc/source/contributor/development_environment.rst

@@ -44,7 +44,7 @@ tests. If you want to be able to run Neutron in a full OpenStack environment,
 you can use the excellent `DevStack`_ project to do so. There is a wiki page
 that describes `setting up Neutron using DevStack`_.
 
-.. _DevStack: https://git.openstack.org/cgit/openstack-dev/devstack
+.. _DevStack: https://opendev.org/openstack/devstack
 .. _setting up Neutron using Devstack: https://wiki.openstack.org/wiki/NeutronDevstack
 
 Getting the code
@@ -52,7 +52,7 @@ Getting the code
 
 Grab the code::
 
-    git clone https://git.openstack.org/openstack/neutron.git
+    git clone https://opendev.org/openstack/neutron.git
     cd neutron
 
 About ignore files

doc/source/contributor/effective_neutron.rst

@@ -60,20 +60,20 @@ Plugin development
 Document common pitfalls as well as good practices done during plugin development.
 
 * Use mixin classes as last resort. They can be a powerful tool to add behavior
-  but their strength is also a weakness, as they can introduce `unpredictable <https://review.openstack.org/#/c/121290/>`_
+  but their strength is also a weakness, as they can introduce `unpredictable <https://review.opendev.org/#/c/121290/>`_
   behavior to the `MRO <https://www.python.org/download/releases/2.3/mro/>`_,
   amongst other issues.
 * In lieu of mixins, if you need to add behavior that is relevant for ML2,
   consider using the `extension manager <http://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-ml2-mechanismdriver-extensions.html>`_.
 * If you make changes to the DB class methods, like calling methods that can
   be inherited, think about what effect that may have to plugins that have
-  controller `backends <https://review.openstack.org/#/c/116924/>`_.
+  controller `backends <https://review.opendev.org/#/c/116924/>`_.
 * If you make changes to the ML2 plugin or components used by the ML2 plugin,
   think about the `effect <http://lists.openstack.org/pipermail/openstack-dev/2015-October/076134.html>`_
   that may have to other plugins.
 * When adding behavior to the L2 and L3 db base classes, do not assume that
   there is an agent on the other side of the message broker that interacts
-  with the server. Plugins may not rely on `agents <https://review.openstack.org/#/c/174020/>`_ at all.
+  with the server. Plugins may not rely on `agents <https://review.opendev.org/#/c/174020/>`_ at all.
 * Be mindful of required capabilities when you develop plugin extensions. The
   `Extension description <https://github.com/openstack/neutron/blob/b14c06b5/neutron/api/extensions.py#L122>`_ provides the ability to specify the list of required capabilities
   for the extension you are developing. By declaring this list, the server will
@@ -116,20 +116,20 @@ Document common pitfalls as well as good practices done during database developm
   can fit your use case.
 * When designing data models that are related to each other, be careful to how
   you model the relationships' loading `strategy <http://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html#using-loader-strategies-lazy-loading-eager-loading>`_. For instance a joined relationship can
-  be very efficient over others (some examples include `router gateways <https://review.openstack.org/#/c/88665/>`_
+  be very efficient over others (some examples include `router gateways <https://review.opendev.org/#/c/88665/>`_
-  or `network availability zones <https://review.openstack.org/#/c/257086/>`_).
+  or `network availability zones <https://review.opendev.org/#/c/257086/>`_).
 * If you add a relationship to a Neutron object that will be referenced in the
   majority of cases where the object is retrieved, be sure to use the
   lazy='joined' parameter to the relationship so the related objects are loaded
   as part of the same query. Otherwise, the default method is 'select', which
   emits a new DB query to retrieve each related object adversely impacting
-  performance. For example, see `patch 88665 <https://review.openstack.org/#/c/88665/>`_
+  performance. For example, see `patch 88665 <https://review.opendev.org/#/c/88665/>`_
   which resulted in a significant improvement since router retrieval functions
   always include the gateway interface.
 * Conversely, do not use lazy='joined' if the relationship is only used in
   corner cases because the JOIN statement comes at a cost that may be
   significant if the relationship contains many objects. For example, see
-  `patch 168214 <https://review.openstack.org/#/c/168214/>`_ which reduced a
+  `patch 168214 <https://review.opendev.org/#/c/168214/>`_ which reduced a
   subnet retrieval by ~90% by avoiding a join to the IP allocation table.
 * When writing extensions to existing objects (e.g. Networks), ensure that
   they are written in a way that the data on the object can be calculated
@@ -137,7 +137,7 @@ Document common pitfalls as well as good practices done during database developm
   is performed once in bulk during a list operation. Otherwise a list call
   for a 1000 objects will change from a constant small number of DB queries
   to 1000 DB queries. For example, see
-  `patch 257086 <https://review.openstack.org/#/c/257086/>`_ which changed the
+  `patch 257086 <https://review.opendev.org/#/c/257086/>`_ which changed the
   availability zone code from the incorrect style to a database friendly one.
 
 * Sometimes in code we use the following structures:
@@ -285,7 +285,7 @@ For anything more elaborate, please visit the testing section.
   In fact, when the built-in open method is mocked during tests, some
   utilities (like debtcollector) may still rely on the real thing, and may
   end up using the mock rather what they are really looking for. If you must,
-  consider using `OpenFixture <https://review.openstack.org/#/c/232716/>`_, but
+  consider using `OpenFixture <https://review.opendev.org/#/c/232716/>`_, but
   it is better not to mock open() at all.
 
 Documentation

doc/source/contributor/internals/api_layer.rst

@@ -33,14 +33,14 @@ Server Gateway Interface (WSGI) - defined in `PEP 333 <http://legacy.python.org/
 Startup
 -------
 
-Neutron's WSGI server is started from the `server module <http://git.openstack.org/cgit/openstack/neutron/tree/neutron/server/__init__.py>`_
+Neutron's WSGI server is started from the `server module <http://opendev.org/openstack/neutron/tree/neutron/server/__init__.py>`_
 and the entry point `serve_wsgi` is called to build an instance of the
 `NeutronApiService`_, which is then returned to the server module,
 which spawns a `Eventlet`_ `GreenPool`_ that will run the WSGI
 application and respond to requests from clients.
 
 
-.. _NeutronApiService: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/service.py
+.. _NeutronApiService: http://opendev.org/openstack/neutron/tree/neutron/service.py
 
 .. _Eventlet: http://eventlet.net/
 
@@ -62,11 +62,11 @@ Neutron, which contains several methods that map Neutron resources (such as
 Ports, Networks, Subnets) to URLs, and the controller for each resource.
 
 
-.. _config.py: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/common/config.py
+.. _config.py: http://opendev.org/openstack/neutron/tree/neutron/common/config.py
 
-.. _api-paste.ini: http://git.openstack.org/cgit/openstack/neutron/tree/etc/api-paste.ini
+.. _api-paste.ini: http://opendev.org/openstack/neutron/tree/etc/api-paste.ini
 
-.. _APIRouter: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/router.py
+.. _APIRouter: http://opendev.org/openstack/neutron/tree/neutron/api/v2/router.py
 
 .. _Paste: http://pythonpaste.org/
 

doc/source/contributor/internals/db_models.rst

@@ -45,5 +45,5 @@ References
 ~~~~~~~~~~
 
 [1]. https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg88910.html
-[2]. https://review.openstack.org/#/c/348562/
+[2]. https://review.opendev.org/#/c/348562/
-[3]. https://review.openstack.org/#/c/348757/
+[3]. https://review.opendev.org/#/c/348757/

doc/source/contributor/internals/objects_usage.rst

@@ -672,10 +672,10 @@ The :code:`convert_filters` method is available in
 
 References
 ----------
-.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n258
+.. [#] https://opendev.org/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n258
-.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/standard_attr.py?h=stable/ocata
+.. [#] https://opendev.org/openstack/neutron/tree/neutron/db/standard_attr.py?h=stable/ocata
-.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n516
+.. [#] https://opendev.org/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n516
-.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n542
+.. [#] https://opendev.org/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n542
 .. [#] https://docs.openstack.org/neutron/latest/contributor/internals/db_layer.html#the-standard-attribute-table
-.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/rbac_db.py?h=stable/ocata#n291
+.. [#] https://opendev.org/openstack/neutron/tree/neutron/objects/rbac_db.py?h=stable/ocata#n291
-.. [#] https://git.openstack.org/cgit/openstack/neutron-lib/tree/neutron_lib/objects/utils.py
+.. [#] https://opendev.org/openstack/neutron-lib/tree/neutron_lib/objects/utils.py

doc/source/contributor/internals/openvswitch_agent.rst

@@ -95,7 +95,7 @@ the integration bridge with the physical network bridge, with flow
 rules adding, modifying, or stripping VLAN tags as necessary, thus
 preserving backward compatibility with the way the OVS agent used
 to work prior to the tunneling capability (for more details, please
-look at https://review.openstack.org/#/c/4367).
+look at https://review.opendev.org/#/c/4367).
 
 Bear in mind, that this design decision may be overhauled in the
 future to support existing VLAN-tagged traffic (coming from NFV VMs

doc/source/contributor/internals/policy.rst

@@ -395,23 +395,23 @@ OpenStack projects.
 References
 ----------
 
-.. [#] `Oslo policy module <http://git.openstack.org/cgit/openstack/oslo.policy/>`_
+.. [#] `Oslo policy module <http://opendev.org/openstack/oslo.policy/>`_
 .. [#] `Oslo policy developer <https://docs.openstack.org/oslo.policy/latest/>`_
 .. [#] API controller item_ method
 
-.. _item: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/base.py?id=2015.1.1#n282
+.. _item: http://opendev.org/openstack/neutron/tree/neutron/api/v2/base.py?id=2015.1.1#n282
 
 .. [#] Policy engine's build_match_rule_ method
 
-.. _build_match_rule: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/policy.py?id=2015.1.1#n187
+.. _build_match_rule: http://opendev.org/openstack/neutron/tree/neutron/policy.py?id=2015.1.1#n187
 
 .. [#] exclude_attributes_by_policy_ method
 
-.. _exclude_attributes_by_policy: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/base.py?id=2015.1.1#n132
+.. _exclude_attributes_by_policy: http://opendev.org/openstack/neutron/tree/neutron/api/v2/base.py?id=2015.1.1#n132
 
 .. [#] Policy reset_ in neutron.api.v2.router
 
-.. _reset: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/router.py?id=2015.1.1#n122
+.. _reset: http://opendev.org/openstack/neutron/tree/neutron/api/v2/router.py?id=2015.1.1#n122
 
 .. [#] https://github.com/openstack/neutron/blob/051b6b40f3921b9db4f152a54f402c402cbf138c/neutron/pecan_wsgi/hooks/policy_enforcement.py#L173
 .. [#] https://github.com/openstack/neutron/blob/051b6b40f3921b9db4f152a54f402c402cbf138c/neutron/pecan_wsgi/hooks/policy_enforcement.py#L143

doc/source/contributor/internals/provisioning_blocks.rst

@@ -34,7 +34,7 @@ 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
-<http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/provisioning_blocks.py>`_
+<http://opendev.org/openstack/neutron/tree/neutron/db/provisioning_blocks.py>`_
 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.

doc/source/contributor/internals/quota.rst

@@ -345,9 +345,9 @@ Please be aware of the following limitations of the quota enforcement engine:
 References
 ----------
 
-.. [#] Subnet allocation extension: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/subnetallocation.py
+.. [#] Subnet allocation extension: http://opendev.org/openstack/neutron/tree/neutron/extensions/subnetallocation.py
-.. [#] DB Quota driver class: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/quota/driver.py#n30
+.. [#] DB Quota driver class: http://opendev.org/openstack/neutron/tree/neutron/db/quota/driver.py#n30
-.. [#] Quota API extension controller: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/quotasv2.py#n40
+.. [#] Quota API extension controller: http://opendev.org/openstack/neutron/tree/neutron/extensions/quotasv2.py#n40
-.. [#] Neutron resource attribute map: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/attributes.py#n639
+.. [#] Neutron resource attribute map: http://opendev.org/openstack/neutron/tree/neutron/api/v2/attributes.py#n639
-.. [#] Base controller class: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/base.py#n50
+.. [#] Base controller class: http://opendev.org/openstack/neutron/tree/neutron/api/v2/base.py#n50
 .. [#] http://lists.openstack.org/pipermail/openstack-dev/2015-February/057534.html

doc/source/contributor/internals/security_group_api.rst

@@ -33,7 +33,7 @@ API Extension
 The API extension is the 'front' end portion of the code, which handles defining a `REST-ful API`_, which is used by projects.
 
 
-.. _`REST-ful API`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/securitygroup.py
+.. _`REST-ful API`: https://opendev.org/openstack/neutron/tree/neutron/extensions/securitygroup.py
 
 
 Database API
@@ -41,7 +41,7 @@ Database API
 
 The Security Group API extension adds a number of `methods to the database layer`_ of Neutron
 
-.. _`methods to the database layer`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/securitygroups_db.py
+.. _`methods to the database layer`: https://opendev.org/openstack/neutron/tree/neutron/db/securitygroups_db.py
 
 Agent RPC
 ---------
@@ -50,12 +50,12 @@ This portion of the code handles processing requests from projects, after they h
 running on the compute nodes, and modifying the IPTables rules on each hypervisor.
 
 
-* `Plugin RPC classes <https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/securitygroups_rpc_base.py>`_
+* `Plugin RPC classes <https://opendev.org/openstack/neutron/tree/neutron/db/securitygroups_rpc_base.py>`_
 
-  * `SecurityGroupServerRpcMixin <https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/securitygroups_rpc_base.py>`_ - defines the RPC API that the plugin uses to communicate with the agents running on the compute nodes
+  * `SecurityGroupServerRpcMixin <https://opendev.org/openstack/neutron/tree/neutron/db/securitygroups_rpc_base.py>`_ - defines the RPC API that the plugin uses to communicate with the agents running on the compute nodes
   * SecurityGroupServerRpcMixin  -  Defines the API methods used to fetch data from the database, in order to return responses to agents via the RPC API
 
-* `Agent RPC classes <https://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/rpc/handlers/securitygroups_rpc.py>`_
+* `Agent RPC classes <https://opendev.org/openstack/neutron/tree/neutron/api/rpc/handlers/securitygroups_rpc.py>`_
 
   * The SecurityGroupServerRpcApi defines the API methods that can be called by agents, back to the plugin that runs on the Neutron controller
   * The SecurityGroupAgentRpcCallbackMixin defines methods that a plugin uses to call back to an agent after performing an action called by an agent.

doc/source/contributor/internals/service_extensions.rst

@@ -46,9 +46,9 @@ to have these loaded automatically at server startup. If you
 consider adding an entry to the dictionary, please be kind and
 reach out to your PTL or a member of the drivers team for approval.
 
-#. http://git.openstack.org/cgit/openstack/neutron-fwaas/
+#. http://opendev.org/openstack/neutron-fwaas/
-#. http://git.openstack.org/cgit/openstack/neutron-lbaas/
+#. http://opendev.org/openstack/neutron-lbaas/
-#. http://git.openstack.org/cgit/openstack/neutron-vpnaas/
+#. http://opendev.org/openstack/neutron-vpnaas/
 
 
 Calling the Core Plugin from Services

doc/source/contributor/internals/services_and_agents.rst

@@ -67,14 +67,14 @@ eventlet.monkey_patch() directly but instead maintain its entry point main()
 function under neutron/cmd/eventlet/... If that is the case, the standard
 Python library will be automatically patched for the service on entry point
 import (monkey patching is done inside `python package file
-<http://git.openstack.org/cgit/openstack/neutron/tree/neutron/cmd/eventlet/__init__.py>`_).
+<http://opendev.org/openstack/neutron/tree/neutron/cmd/eventlet/__init__.py>`_).
 
 Note: an entry point 'main()' function may just be an indirection to a real
 callable located elsewhere, as is done for reference services such as DHCP, L3
 and the neutron-server.
 
 For more info on the rationale behind the code tree setup, see `the
-corresponding cross-project spec <https://review.openstack.org/154642>`_.
+corresponding cross-project spec <https://review.opendev.org/154642>`_.
 
 
 Connecting to the Database

doc/source/contributor/internals/tag.rst

@@ -131,4 +131,4 @@ Remove all tags on a network ::
     DELETE /v2.0/networks/{network_id}/tags
 
 PUT and DELETE for collections are the motivation of `extending the API
-framework <https://review.openstack.org/#/c/284519/>`_.
+framework <https://review.opendev.org/#/c/284519/>`_.

doc/source/contributor/policies/blueprints.rst

@@ -2,7 +2,7 @@ Blueprints and Specs
 ====================
 
 The Neutron team uses the `neutron-specs
-<http://git.openstack.org/cgit/openstack/neutron-specs>`_ repository for its
+<http://opendev.org/openstack/neutron-specs>`_ repository for its
 specification reviews. Detailed information can be found on the `wiki
 <https://wiki.openstack.org/wiki/Blueprints>`_. Please also find
 additional information in the reviews.rst file.
@@ -14,7 +14,7 @@ assign these into milestones or move them to the backlog for selection into
 a future release.
 
 Please note that we use a `template
-<http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/template.rst>`_
+<http://opendev.org/openstack/neutron-specs/tree/specs/template.rst>`_
 for spec submissions. It is not required to fill out all sections in the
 template. Review of the spec may require filling in information left out by
 the submitter.
@@ -22,7 +22,7 @@ the submitter.
 Sub-Projects and Specs
 ----------------------
 
-The `neutron-specs <http://git.openstack.org/cgit/openstack/neutron-specs>`_
+The `neutron-specs <http://opendev.org/openstack/neutron-specs>`_
 repository is only meant for specs from Neutron itself, and the advanced
 services repositories as well. This includes FWaaS, LBaaS, and VPNaaS. Other
 sub-projects are encouraged to fold their specs into their own devref code

doc/source/contributor/policies/bugs.rst

@@ -16,7 +16,7 @@ is used to allow access to the projects above. Members of the above group
 have the ability to set bug priorities, target bugs to releases, and other
 administrative tasks around bugs. The administrators of this group are the
 members of the `neutron-drivers-core
-<https://review.openstack.org/#/admin/groups/464,members>`_ gerrit group.
+<https://review.opendev.org/#/admin/groups/464,members>`_ gerrit group.
 Non administrators of this group include anyone who is involved with the
 Neutron project and has a desire to assist with bug triage.
 
@@ -261,8 +261,8 @@ The process of bug triaging consists of the following steps:
 
 * Check if a similar bug was filed before. Rely on your memory if Launchpad
   is not clever enough to spot a duplicate upon submission.  You may also
-  check already verified bugs for `Neutron <https://review.openstack.org/#/q/status:open+label:Verified-2+project:openstack/neutron>`_
+  check already verified bugs for `Neutron <https://review.opendev.org/#/q/status:open+label:Verified-2+project:openstack/neutron>`_
-  and `python-neutronclient <https://review.openstack.org/#/q/status:open+label:Verified-2+project:openstack/python-neutronclient>`_
+  and `python-neutronclient <https://review.opendev.org/#/q/status:open+label:Verified-2+project:openstack/python-neutronclient>`_
   to see if the bug has been reported.  If so, mark it as a duplicate of the
   previous bug.
 * Check if the bug meets the requirements of a good bug report, by checking

doc/source/contributor/policies/code-reviews.rst

@@ -55,7 +55,7 @@ In addition to that, the following rules are to follow:
         the right to discontinue support for unresponsive platforms.
 
   #. The change should also include a new `sanity check
-     <https://git.openstack.org/cgit/openstack/neutron/tree/neutron/cmd/sanity/checks.py>`_
+     <https://opendev.org/openstack/neutron/tree/neutron/cmd/sanity/checks.py>`_
      that would help interested parties to identify their platform limitation
      in timely manner.
 

doc/source/contributor/policies/gate-failure-triage.rst

@@ -152,7 +152,7 @@ This can be done in two ways:
         RemotePdb session open at 172.99.68.50:44444, waiting for connection ...
 
    An example of such a ``Do not merge`` patch described above can be found at
-   `<https://review.openstack.org/#/c/558259/>`_.
+   `<https://review.opendev.org/#/c/558259/>`_.
 
    Please note that after adding new packages to the ``requirements.txt`` file,
    the ``requirements-check`` job for your test patch will fail, but it is not

doc/source/contributor/policies/neutron-teams.rst

@@ -1,7 +1,7 @@
 Neutron Core Reviewers
 ======================
 
-The `Neutron Core Reviewer Team <https://review.openstack.org/#/admin/groups/38,members>`_
+The `Neutron Core Reviewer Team <https://review.opendev.org/#/admin/groups/38,members>`_
 is responsible for many things related to Neutron. A lot of these things include mundane
 tasks such as the following:
 
@@ -163,11 +163,11 @@ responsibility over the areas of code listed below:
 
 Neutron Core Reviewer Team
 --------------------------
-`Neutron core reviewers <https://review.openstack.org/#/admin/groups/38,members>`_ have
+`Neutron core reviewers <https://review.opendev.org/#/admin/groups/38,members>`_ have
 merge rights to the following git repositories:
 
-* `openstack/neutron <https://git.openstack.org/cgit/openstack/neutron/>`_
+* `openstack/neutron <https://opendev.org/openstack/neutron/>`_
-* `openstack/python-neutronclient <https://git.openstack.org/cgit/openstack/python-neutronclient/>`_
+* `openstack/python-neutronclient <https://opendev.org/openstack/python-neutronclient/>`_
 
 Please note that as we adopt to the system above with core specialty in
 particular areas, we expect this broad core team to shrink as people naturally
@@ -191,10 +191,10 @@ arise.
 
 Neutron Specs Core Reviewer Team
 --------------------------------
-Neutron `specs core reviewers <https://review.openstack.org/#/admin/groups/314,members>`_
+Neutron `specs core reviewers <https://review.opendev.org/#/admin/groups/314,members>`_
 have +2 rights to the following git repositories:
 
-* `openstack/neutron-specs <https://git.openstack.org/cgit/openstack/neutron-specs/>`_
+* `openstack/neutron-specs <https://opendev.org/openstack/neutron-specs/>`_
 
 The Neutron specs core reviewer team is responsible for reviewing specs targeted to
 all Neutron git repositories (Neutron + Advanced Services). It is worth noting that
@@ -212,7 +212,7 @@ the group can be extended to other individuals, if required.
 Drivers Team
 ------------
 
-The `drivers team <https://review.openstack.org/#/admin/groups/464,members>`_ is
+The `drivers team <https://review.opendev.org/#/admin/groups/464,members>`_ is
 the group of people who have full rights to the specs repo. This team, which matches
 `Launchpad Neutron Drivers team <https://launchpad.net/~neutron-drivers>`_, is
 instituted to ensure a consistent architectural vision for the Neutron project, and
@@ -228,7 +228,7 @@ and/or read the meeting notes.
 Release Team
 ------------
 
-The `release team <https://review.openstack.org/#/admin/groups/150,members>`_ is
+The `release team <https://review.opendev.org/#/admin/groups/150,members>`_ is
 a group of people with some additional gerrit permissions primarily aimed at
 allowing release management of Neutron sub-projects.  These permissions include:
 

doc/source/contributor/policies/release-checklist.rst

@@ -25,7 +25,7 @@ Prior to major release,
    http://docs.openstack.org/project-team-guide/release-management.html);
 #. start collecting state for targeted features from the team. For example,
    propose a post-mortem patch for neutron-specs as in:
-   https://review.openstack.org/#/c/286413/
+   https://review.opendev.org/#/c/286413/
 #. revise deprecation warnings collected in latest Jenkins runs: some of them
    may indicate a problem that should be fixed prior to release (see
    deprecations.txt file in those log directories); also, check whether any
@@ -43,7 +43,7 @@ New major release process contains several phases:
    the release;
 #. once the team is ready to release the first release candidate (RC1), either
    PTL or one of release liaisons proposes a patch for openstack/releases repo.
-   For example, see: https://review.openstack.org/#/c/292445/
+   For example, see: https://review.opendev.org/#/c/292445/
 #. once the openstack/releases patch lands, release team creates a new stable
    branch using hash values specified in the patch;
 #. at this point, master branch is open for patches targeted to the next
@@ -64,7 +64,7 @@ The following technical steps should be taken before the final release is cut
 off:
 
 #. the latest alembic scripts are tagged with a milestone label. For example,
-   see: https://review.openstack.org/#/c/288212/
+   see: https://review.opendev.org/#/c/288212/
 
 In the new stable branch, you should make sure that:
 

doc/source/contributor/policies/thirdparty-ci.rst

@@ -38,7 +38,7 @@ What Tests To Run
 Network API tests (git link).
 Network scenario tests (The test_network_* tests here).
 Any tests written specifically for your setup.
-http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/network
+http://opendev.org/openstack/tempest/tree/tempest/api/network
 
 Run with the test filter: 'network'. This will include all neutron specific
 tests as well as any other tests that are tagged as requiring networking. An
@@ -129,5 +129,5 @@ References
 ----------
 
 .. [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
+.. [2] https://review.opendev.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/dev/zuul/layout.yaml

doc/source/contributor/stadium/governance.rst

@@ -39,8 +39,8 @@ These initiatives enabled the various individual teams in charge of the
 smaller projects the opportunity to iterate faster and reduce the time to
 feature. This has been due to the increased autonomy and implicit trust model
 that made the lack of oversight of the PTL and the Neutron drivers/core team
-acceptable for a small number of initiatives. When the proposed `arrangement <https://review.openstack.org/#/c/175952/>`_
+acceptable for a small number of initiatives. When the proposed `arrangement <https://review.opendev.org/#/c/175952/>`_
-allowed projects to be `automatically <http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d>`_
+allowed projects to be `automatically <http://opendev.org/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d>`_
 enlisted as a Neutron project based simply on description, and desire for
 affiliation, the number of projects included in the Stadium started to grow
 rapidly, which created a number of challenges for the PTL and the drivers
@@ -72,7 +72,7 @@ When is a project considered part of the Stadium?
 -------------------------------------------------
 
 In order to be considered part of the Stadium, a project must show a track
-record of alignment with the Neutron `core project <http://git.openstack.org/cgit/openstack/neutron>`_.
+record of alignment with the Neutron `core project <http://opendev.org/openstack/neutron>`_.
 This means showing proof of adoption of practices as led by the Neutron core
 team. Some of these practices are typically already followed by the most
 mature OpenStack projects:
@@ -93,9 +93,9 @@ mature OpenStack projects:
   DB logic errors due to schema/models mismatch. For more details, please
   look at the following resources:
 
-  * https://review.openstack.org/#/c/346091/
+  * https://review.opendev.org/#/c/346091/
-  * https://review.openstack.org/#/c/346272/
+  * https://review.opendev.org/#/c/346272/
-  * https://review.openstack.org/#/c/346083/
+  * https://review.opendev.org/#/c/346083/
 
   More Database related information can be found on:
 
@@ -190,9 +190,9 @@ Checklist
   This is a two step process that involves the following:
 
   * Build the artefacts: this can be done by following example
-    https://review.openstack.org/#/c/293399/.
+    https://review.opendev.org/#/c/293399/.
   * Publish the artefacts: this can be done by following example
-    https://review.openstack.org/#/c/216448/.
+    https://review.opendev.org/#/c/216448/.
 
   More information can also be found on the
   `project creator guide <http://docs.openstack.org/infra/manual/creators.html#add-link-to-your-developer-documentation>`_.
@@ -201,9 +201,9 @@ Checklist
   the ability to display historical series, like failure rates of
   OpenStack CI jobs. A few examples that added dashboards over time are:
 
-  * `Neutron <https://review.openstack.org/#/c/278832/>`_.
+  * `Neutron <https://review.opendev.org/#/c/278832/>`_.
-  * `Networking-OVN <https://review.openstack.org/#/c/335791>`_.
+  * `Networking-OVN <https://review.opendev.org/#/c/335791>`_.
-  * `Networking-Midonet <https://review.openstack.org/#/c/315033>`_.
+  * `Networking-Midonet <https://review.opendev.org/#/c/315033>`_.
 
   Any subproject must have a Grafana dashboard that shows failure
   rates for at least Gate and Check queues.
@@ -212,26 +212,26 @@ Checklist
   required to integrate with neutron-lib CI and adopt neutron-lib in
   general. One step is to validate that neutron-lib master is working
   with the master of a given project that uses neutron-lib. For example
-  `patch <https://review.openstack.org/#/c/338603/>`_ introduced such
+  `patch <https://review.opendev.org/#/c/338603/>`_ introduced such
   support for the Neutron project. Any subproject that wants to do the
   same would need to adopt the following few lines:
 
-  #. https://review.openstack.org/#/c/338603/4/jenkins/jobs/projects.yaml@4685
+  #. https://review.opendev.org/#/c/338603/4/jenkins/jobs/projects.yaml@4685
-  #. https://review.openstack.org/#/c/338603/3/zuul/layout.yaml@8501
+  #. https://review.opendev.org/#/c/338603/3/zuul/layout.yaml@8501
-  #. https://review.openstack.org/#/c/338603/4/grafana/neutron.yaml@39
+  #. https://review.opendev.org/#/c/338603/4/grafana/neutron.yaml@39
 
   Line 1 and 2 respectively add a job to the periodic queue for the
   project, whereas line 3 introduced the failure rate trend for the
   periodic job to spot failure spikes etc. Make sure your project has
   the following:
 
-  #. https://review.openstack.org/#/c/357086/
+  #. https://review.opendev.org/#/c/357086/
-  #. https://review.openstack.org/#/c/359143/
+  #. https://review.opendev.org/#/c/359143/
 
 * How to port api-ref over to neutron-lib: to publish the subproject
   API reference into the `Networking API guide <http://developer.openstack.org/api-ref/networking/>`_
   you must contribute the API documentation into neutron-lib's api-ref
-  directory as done in the `WADL/REST transition patch <https://review.openstack.org/#/c/327510/>`_.
+  directory as done in the `WADL/REST transition patch <https://review.opendev.org/#/c/327510/>`_.
   Once this is done successfully, a link to the subproject API will
   show under the published `table of content <https://github.com/openstack/neutron-lib/blob/master/api-ref/source/index.rst>`_.
   An RFE bug tracking this effort effectively initiates the request
@@ -242,15 +242,15 @@ Checklist
   steps to port API definitions over to neutron-lib are demonstrated
   in the following patches:
 
-  * https://review.openstack.org/#/c/353131/
+  * https://review.opendev.org/#/c/353131/
-  * https://review.openstack.org/#/c/353132/
+  * https://review.opendev.org/#/c/353132/
 
-  The `neutron-lib patch <https://review.openstack.org/#/c/353131/>`_
+  The `neutron-lib patch <https://review.opendev.org/#/c/353131/>`_
   introduces the elements that define the API, and testing coverage
   validates that the resource and actions maps use valid keywords.
   API reference documentation is provided alongside the definition to
   keep everything in one place.
-  The `neutron patch <https://review.openstack.org/#/c/353132/>`_
+  The `neutron patch <https://review.opendev.org/#/c/353132/>`_
   uses the Neutron extension framework to plug the API definition
   on top of the Neutron API backbone. The change can only merge when
   there is a released version of neutron-lib.
@@ -259,8 +259,8 @@ Checklist
   Stadium must have release notes. In order to set up release notes,
   please see the patches below for an example on how to set up reno:
 
-  * https://review.openstack.org/#/c/320904/
+  * https://review.opendev.org/#/c/320904/
-  * https://review.openstack.org/#/c/243085/
+  * https://review.opendev.org/#/c/243085/
 
   For release documentation related to Neutron, please check the
   :doc:`/contributor/policies/index`.
@@ -276,9 +276,9 @@ Checklist
   following example on how to contribute these two python-neutronclient
   according to the OSC framework and guidelines:
 
-  * https://review.openstack.org/#/c/340624/
+  * https://review.opendev.org/#/c/340624/
-  * https://review.openstack.org/#/c/340763/
+  * https://review.opendev.org/#/c/340763/
-  * https://review.openstack.org/#/c/352653/
+  * https://review.opendev.org/#/c/352653/
 
   More information on how to develop python-openstackclient plugins
   can be found on the following links:
@@ -287,7 +287,7 @@ Checklist
   * https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html
 
   It is worth prefixing the commands being added with the keyword
-  `network <https://review.openstack.org/#/c/340624/10/setup.cfg>`_ to
+  `network <https://review.opendev.org/#/c/340624/10/setup.cfg>`_ to
   avoid potential clash with other commands with similar names. This
   is only required if the command object name is highly likely to have
   an ambiguous meaning.

doc/source/contributor/stadium/guidelines.rst

@@ -82,7 +82,7 @@ requirements for you.
 
 Once a subproject opts in global requirements synchronization, it should enable
 check-requirements jobs in project-config. For example, see `this patch
-<https://review.openstack.org/#/c/215671/>`_.
+<https://review.opendev.org/#/c/215671/>`_.
 
 Stable branches
 ---------------
@@ -101,7 +101,7 @@ branches, you should make sure that your project is registered in
 openstack/requirements:projects.txt *for the branch in question*.
 
 Subproject stable branches are supervised by horizontal `neutron-stable-maint
-team <https://review.openstack.org/#/admin/groups/539,members>`_.
+team <https://review.opendev.org/#/admin/groups/539,members>`_.
 
 More info on stable branch process can be found on `the following page
 <http://docs.openstack.org/project-team-guide/stable-branches.html>`_.
@@ -110,7 +110,7 @@ Stable merge requirements
 -------------------------
 
 Merges into stable branches are handled by members of the `neutron-stable-maint
-gerrit group <https://review.openstack.org/#/admin/groups/539,members>`_. The
+gerrit group <https://review.opendev.org/#/admin/groups/539,members>`_. The
 reason for this is to ensure consistency among stable branches, and compliance
 with policies for stable backports.
 
@@ -135,9 +135,9 @@ Sub-Project Release Process
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 All subproject releases are managed by `global OpenStack Release Managers team
-<https://review.openstack.org/#/admin/groups/11,members>`_. The
+<https://review.opendev.org/#/admin/groups/11,members>`_. The
 `neutron-release team
-<https://review.openstack.org/#/admin/groups/150,members>`_ handles only the
+<https://review.opendev.org/#/admin/groups/150,members>`_ handles only the
 following operations:
 
 * Make stable branches end of life
@@ -152,7 +152,7 @@ To release a sub-project, follow the following steps:
   other Neutron projects. You can skip this step if you don't have a version in
   setup.cfg.
 * A sub-project owner `proposes
-  <https://git.openstack.org/cgit/openstack/releases/tree/README.rst>`_ a patch
+  <https://opendev.org/openstack/releases/tree/README.rst>`_ a patch
   to openstack/releases repository with the intended git hash. `The Neutron
   release liaison <https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management>`_
   should be added in Gerrit to the list of reviewers for the patch.

doc/source/contributor/testing/template_model_sync_test.rst

@@ -155,4 +155,4 @@ test execution.
  PyMySQL>=0.6.2  # MIT License
 
 
-Example implementation `in VPNaaS <https://review.openstack.org/209943>`_
+Example implementation `in VPNaaS <https://review.opendev.org/209943>`_

neutron/agent/common/ovs_lib.py

@@ -319,7 +319,7 @@ class OVSBridge(BaseOVS):
             # TODO(mangelajo): We could accept attr tuples for the Port too
             # but, that could potentially break usage of this function in
             # stable branches (where we need to backport).
-            # https://review.openstack.org/#/c/564825/4/neutron/agent/common/
+            # https://review.opendev.org/#/c/564825/4/neutron/agent/common/
             # ovs_lib.py@289
             if interface_attr_tuples:
                 txn.add(self.ovsdb.db_set('Interface', port_name,

neutron/db/l3_hamode_db.py

@@ -121,7 +121,7 @@ class L3_HA_NAT_db_mixin(l3_dvr_db.L3_NAT_with_dvr_db_mixin,
         network_id = ha_network.network_id
 
         # TODO(kevinbenton): let decorator handle duplicate retry
-        # like in review.openstack.org/#/c/367179/1/neutron/db/l3_hamode_db.py
+        # like in review.opendev.org/#/c/367179/1/neutron/db/l3_hamode_db.py
         for count in range(MAX_ALLOCATION_TRIES):
             try:
                 # NOTE(kevinbenton): we disallow subtransactions because the

neutron/extensions/_availability_zone_filter_lib.py

@@ -12,7 +12,7 @@
 
 """
 TODO(hongbin): This module should be deleted once neutron-lib containing
-https://review.openstack.org/#/c/577545/ change is released.
+https://review.opendev.org/#/c/577545/ change is released.
 """
 
 from neutron_lib.api.definitions import availability_zone as az

neutron/extensions/_filter_validation_lib.py

@@ -12,7 +12,7 @@
 
 """
 This module should be deleted once neutron-lib containing
-https://review.openstack.org/#/c/580190/ change is released.
+https://review.opendev.org/#/c/580190/ change is released.
 """
 
 

neutron/extensions/_standard_attr_segment_lib.py

@@ -12,7 +12,7 @@
 
 """
 TODO(hongbin): This module should be deleted once neutron-lib containing
-https://review.openstack.org/#/c/562331/ change is released.
+https://review.opendev.org/#/c/562331/ change is released.
 """
 
 

neutron/plugins/ml2/drivers/linuxbridge/agent/extension_drivers/qos_driver.py

@@ -32,7 +32,7 @@ class QosLinuxbridgeAgentDriver(qos.QosLinuxAgentDriver):
     #   - All driver calls should include the rule parameter, including
     #     the delete function, to have the 'direction' parameter. This QoS
     #     extension modification is going to be implemented in
-    #     https://review.openstack.org/#/c/341186/
+    #     https://review.opendev.org/#/c/341186/
     SUPPORTED_RULES = driver.SUPPORTED_RULES
 
     IPTABLES_DIRECTION = {const.INGRESS_DIRECTION: 'physdev-out',

neutron/plugins/ml2/drivers/macvtap/mech_driver/mech_macvtap.py

@@ -61,7 +61,7 @@ class MacvtapMechanismDriver(mech_agent.SimpleAgentMechanismDriverBase):
         # context.original['host_id'] is set to the failed host.
         # The only safe way to detect a migration is to look into the binding
         # profiles 'migrating_to' attribute, which is set by Nova since patch
-        # https://review.openstack.org/#/c/275073/.
+        # https://review.opendev.org/#/c/275073/.
         if not context.original:
             # new port
             return False

neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py

@@ -1417,7 +1417,7 @@ class OVSNeutronAgent(l2population_rpc.L2populationRpcCallBackTunnelMixin,
                                    if e['name'] != p]
 
         # TODO(rossella_s): scanning the ancillary bridge won't be needed
-        # anymore when https://review.openstack.org/#/c/203381 since the bridge
+        # anymore when https://review.opendev.org/#/c/203381 since the bridge
         # id stored in external_ids will be used to identify the bridge the
         # port belongs to
         cur_ancillary_ports = set()

neutron/plugins/ml2/managers.py

@@ -865,7 +865,7 @@ class MechanismManager(stevedore.named.NamedExtensionManager):
                         # level that represents the closest physical interface
                         # to the nova server." Link to spec:
                         #
-                        # https://review.openstack.org/#/c/508149/14/specs\
+                        # https://review.opendev.org/#/c/508149/14/specs\
                         #        /rocky/minimum-bandwidth-\
                         #        allocation-placement-api.rst@582
                         #

neutron/plugins/ml2/plugin.py

@@ -1625,7 +1625,7 @@ class Ml2Plugin(db_base_plugin_v2.NeutronDbPluginV2,
                         updated_port[psec.PORTSECURITY]):
                 need_port_update_notify = True
             # TODO(QoS): Move out to the extension framework somehow.
-            # Follow https://review.openstack.org/#/c/169223 for a solution.
+            # Follow https://review.opendev.org/#/c/169223 for a solution.
             if (qos_consts.QOS_POLICY_ID in attrs and
                     original_port[qos_consts.QOS_POLICY_ID] !=
                     updated_port[qos_consts.QOS_POLICY_ID]):

neutron/services/network_segment_range/plugin.py

@@ -122,7 +122,7 @@ class NetworkSegmentRangePlugin(ext_range.NetworkSegmentRangePluginBase):
                 network_type in const.NETWORK_SEGMENT_RANGE_TYPES):
             # TODO(kailun): To use
             #  range_exc.NetworkSegmentRangeNetTypeNotSupported when the
-            #  neutron-lib patch https://review.openstack.org/640777 is merged
+            #  neutron-lib patch https://review.opendev.org/640777 is merged
             #  and released.
             message = _("Network type %s does not support "
                         "network segment ranges.") % network_type
@@ -190,7 +190,7 @@ class NetworkSegmentRangePlugin(ext_range.NetworkSegmentRangePluginBase):
                                    sorts=None, limit=None, marker=None,
                                    page_reverse=False):
         # TODO(kailun): Based on the current spec:
-        #  https://review.openstack.org/599980, this method call may
+        #  https://review.opendev.org/599980, this method call may
         #  possibly return a large amount of data since ``available``
         #  segment list and ``used`` segment/project mapping will be also
         #  returned and they can be large sometimes. Considering that this
@@ -221,7 +221,7 @@ class NetworkSegmentRangePlugin(ext_range.NetworkSegmentRangePluginBase):
             if existing_range_data['default']:
                 # TODO(kailun): To use
                 #  range_exc.NetworkSegmentRangeDefaultReadOnly when the
-                #  neutron-lib patch https://review.openstack.org/640777 is
+                #  neutron-lib patch https://review.opendev.org/640777 is
                 #  merged and released.
                 message = _("Network Segment Range %s is a "
                             "default segment range which could not be "
@@ -235,7 +235,7 @@ class NetworkSegmentRangePlugin(ext_range.NetworkSegmentRangePluginBase):
                     updated_range=updated_range_data):
                 # TODO(kailun): To use
                 #  range_exc.NetworkSegmentRangeReferencedByProject when the
-                #  neutron-lib patch https://review.openstack.org/640777 is
+                #  neutron-lib patch https://review.opendev.org/640777 is
                 #  merged and released.
                 message = _("Network Segment Range %s is referenced by "
                             "one or more tenant networks.") % id
@@ -263,7 +263,7 @@ class NetworkSegmentRangePlugin(ext_range.NetworkSegmentRangePluginBase):
             if range_data['default']:
                 # TODO(kailun): To use
                 #  range_exc.NetworkSegmentRangeDefaultReadOnly when the
-                #  neutron-lib patch https://review.openstack.org/640777 is
+                #  neutron-lib patch https://review.opendev.org/640777 is
                 #  merged and released.
                 message = _("Network Segment Range %s is a "
                             "default segment range which could not be "
@@ -275,7 +275,7 @@ class NetworkSegmentRangePlugin(ext_range.NetworkSegmentRangePluginBase):
                     context, range_data):
                 # TODO(kailun): To use
                 #  range_exc.NetworkSegmentRangeReferencedByProject when the
-                #  neutron-lib patch https://review.openstack.org/640777 is
+                #  neutron-lib patch https://review.opendev.org/640777 is
                 #  merged and released.
                 message = _("Network Segment Range %s is referenced by "
                             "one or more tenant networks.") % id

neutron/services/placement_report/plugin.py

@@ -53,7 +53,7 @@ class PlacementReportPlugin(service_base.ServicePluginBase):
         self._core_plugin = directory.get_plugin()
         # NOTE(bence romsics): The following bug and fix may be relevant here.
         # https://bugs.launchpad.net/nova/+bug/1697825
-        # https://review.openstack.org/493536
+        # https://review.opendev.org/493536
         self._placement_client = place_client.PlacementAPIClient(cfg.CONF)
         self._agents = PlacementReporterAgents(self._core_plugin)
         self._batch_notifier = batch_notifier.BatchNotifier(

neutron/services/qos/qos_plugin.py

@@ -130,7 +130,7 @@ class QoSPlugin(qos.QoSPluginBase):
 
         # TODO(lajoskatona): Change to handle all segments when any traits
         # support will be available. See Placement spec:
-        # https://review.openstack.org/565730
+        # https://review.opendev.org/565730
         first_segment = network_object.NetworkSegment.get_objects(
             context.get_admin_context(),
             network_id=port_res['network_id'])[0]

neutron/tests/contrib/hooks/qos

@@ -1,2 +1,2 @@
-enable_plugin neutron https://git.openstack.org/openstack/neutron
+enable_plugin neutron https://opendev.org/openstack/neutron
 enable_service neutron-qos

neutron/tests/fullstack/agents/ovs_agent.py

@@ -48,7 +48,7 @@ def monkeypatch_qos():
 
 def main():
     # TODO(slaweq): this monkepatch will not be necessary when
-    # https://review.openstack.org/#/c/506722/ will be merged and ovsdb-server
+    # https://review.opendev.org/#/c/506722/ will be merged and ovsdb-server
     # ovs-vswitchd processes for each test will be isolated in separate
     # namespace
     monkeypatch_init_handler()

neutron/tests/fullstack/test_l3_agent.py

@@ -278,7 +278,7 @@ class TestHAL3Agent(TestL3Agent):
 
     def test_ha_router(self):
         # TODO(amuller): Test external connectivity before and after a
-        # failover, see: https://review.openstack.org/#/c/196393/
+        # failover, see: https://review.opendev.org/#/c/196393/
 
         tenant_id = uuidutils.generate_uuid()
         router = self.safe_client.create_router(tenant_id, ha=True)

neutron/tests/functional/agent/l3/framework.py

@@ -302,7 +302,7 @@ class L3AgentTestFramework(base.BaseSudoTestCase):
             # Note(SridharG): enable the assert_gateway for IPv6 once
             # keepalived on Ubuntu14.04 (i.e., check-neutron-dsvm-functional
             # platform) is updated to 1.2.10 (or above).
-            # For more details: https://review.openstack.org/#/c/151284/
+            # For more details: https://review.opendev.org/#/c/151284/
             self._assert_gateway(router, v6_ext_gw_with_sub)
             self.assertTrue(self.floating_ips_configured(router))
             self._assert_snat_chains(router)

neutron/tests/functional/base.py

@@ -89,7 +89,7 @@ class BaseSudoTestCase(BaseLoggingTestCase):
 
     @staticmethod
     def _override_default_config():
-        # NOTE(ralonsoh): once https://review.openstack.org/#/c/641681/ is
+        # NOTE(ralonsoh): once https://review.opendev.org/#/c/641681/ is
         # merged, we should increase the default value of those new parameters.
         ovs_agent_opts = [('ovsdb_timeout', 30, 'OVS')]
         ovs_agent_decorator = config_decorator(

neutron/tests/functional/db/test_migrations.py

@@ -617,7 +617,7 @@ class TestWalkMigrationsMysql(testlib_api.MySQLTestCaseMixin,
                               testlib_api.SqlTestCaseLight):
 
     # NOTE(slaweq): this workaround is taken from Manila patch:
-    # https://review.openstack.org/#/c/291397/
+    # https://review.opendev.org/#/c/291397/
     # Set 5 minutes timeout for case of running it on
     # very slow nodes/VMs. Note, that this test becomes slower with each
     # addition of new DB migration. On fast nodes it can take about 5-10

neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_tun.py

@@ -36,7 +36,7 @@ class OVSTunnelBridgeTest(ovs_bridge_test_base.OVSBridgeTestBase,
         conn_patcher.start()
         super(OVSTunnelBridgeTest, self).setUp()
         # NOTE(ivasilevskaya) The behaviour of oslotest.base.addCleanup()
-        # according to https://review.openstack.org/#/c/119201/4 guarantees
+        # according to https://review.opendev.org/#/c/119201/4 guarantees
         # that all started mocks will be stopped even without direct call to
         # patcher.stop().
         # If any individual mocks should be stopped by other than default

roles/configure_functional_tests/README.rst

@@ -6,13 +6,13 @@ Configure host to run on it Neutron functional/fullstack tests
    :default: {{ tox_envlist }}
 
 .. zuul:rolevar:: base_dir
-   :default: {{ ansible_user_dir }}/src/git.openstack.org
+   :default: {{ ansible_user_dir }}/src/opendev.org
 
 .. zuul:rolevar:: gate_dest_dir
    :default: {{ base_dir }}/openstack
 
 .. zuul:rolevar:: devstack_dir
-   :default: {{ base_dir }}/openstack-dev/devstack
+   :default: {{ base_dir }}/openstack/devstack
 
 .. zuul:rolevar:: neutron_dir
    :default: {{ gate_dest_dir }}/neutron

tools/abandon_old_reviews.sh

@@ -17,9 +17,9 @@
 # abandoning people's changes is a good thing, but must be done with care.
 #
 # before you run this modify your .ssh/config to create a
-# review.openstack.org entry:
+# review.opendev.org entry:
 #
-#   Host review.openstack.org
+#   Host review.opendev.org
 #   User <yourgerritusername>
 #   Port 29418
 #
@@ -70,20 +70,20 @@ function abandon_review {
     local gitid=$1
     shift
     local msg=$@
-    # echo ssh review.openstack.org gerrit review $gitid --abandon --message \"$msg\"
+    # echo ssh review.opendev.org gerrit review $gitid --abandon --message \"$msg\"
     unassign_and_new_bug $gitid
     if [ $DRY_RUN -eq 1 ]; then
         echo "Would abandon $gitid"
     else
         echo "Abandoning $gitid"
-        ssh review.openstack.org gerrit review $gitid --abandon --message \"$msg\"
+        ssh review.opendev.org gerrit review $gitid --abandon --message \"$msg\"
     fi
 }
 
 function unassign_and_new_bug {
     # unassign current assignee and set bug to 'new' status
     local gitid=$1
-    cm=$(ssh review.openstack.org "gerrit query $gitid --current-patch-set --format json" | jq .commitMessage)
+    cm=$(ssh review.opendev.org "gerrit query $gitid --current-patch-set --format json" | jq .commitMessage)
     for closes in $(echo -e $cm | grep -i "closes" | grep -i "bug" | grep -o -E '[0-9]+'); do
         if [ $DRY_RUN -eq 1 ]; then
             echo "Would unassign and tag 'timeout-abandon' $closes"
@@ -117,7 +117,7 @@ if [ "$PROJECTS" = "()" ]; then
     exit 1
 fi
 
-blocked_reviews=$(ssh review.openstack.org "gerrit query --current-patch-set --format json $PROJECTS status:open age:4w label:Code-Review<=-2" | jq .currentPatchSet.revision | grep -v null | sed 's/"//g')
+blocked_reviews=$(ssh review.opendev.org "gerrit query --current-patch-set --format json $PROJECTS status:open age:4w label:Code-Review<=-2" | jq .currentPatchSet.revision | grep -v null | sed 's/"//g')
 
 blocked_msg=$(cat <<EOF
 
@@ -135,14 +135,14 @@ EOF
 # blocked_reviews="b6c4218ae4d75b86c33fa3d37c27bc23b46b6f0f"
 
 for review in $blocked_reviews; do
-    # echo ssh review.openstack.org gerrit review $review --abandon --message \"$msg\"
+    # echo ssh review.opendev.org gerrit review $review --abandon --message \"$msg\"
     echo "Blocked review $review"
     abandon_review $review $blocked_msg
 done
 
 # then purge all the reviews that are > 4w with no changes and Jenkins has -1ed
 
-failing_reviews=$(ssh review.openstack.org "gerrit query  --current-patch-set --format json $PROJECTS status:open age:4w NOT label:Verified>=1,Zuul" | jq .currentPatchSet.revision | grep -v null | sed 's/"//g')
+failing_reviews=$(ssh review.opendev.org "gerrit query  --current-patch-set --format json $PROJECTS status:open age:4w NOT label:Verified>=1,Zuul" | jq .currentPatchSet.revision | grep -v null | sed 's/"//g')
 
 failing_msg=$(cat <<EOF
 

tools/split.sh

@@ -99,7 +99,7 @@ git filter-branch \
 echo "Generating new .gitreview file..."
 cat > .gitreview <<EOF
 [gerrit]
-host=review.openstack.org
+host=review.opendev.org
 port=29418
 project=stackforge/${project_name}.git
 EOF

tox.ini

@@ -14,7 +14,7 @@ usedevelop = True
 install_command =
   pip install {opts} {packages}
 deps =
-  -c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
+  -c{env:UPPER_CONSTRAINTS_FILE:https://opendev.org/openstack/requirements/raw/branch/master/upper-constraints.txt}
   -r{toxinidir}/requirements.txt
   -r{toxinidir}/test-requirements.txt
 whitelist_externals = sh