openstack/neutron
Code Issues Proposed changes

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

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

Change-Id: Ifc446e00d7f69cb23411b3a50c8d880c719f1e73
This commit is contained in:
ZhongShengping 2019-04-22 13:43:44 +08:00
parent 5d607a13ba
commit 161e6b80f0
55 changed files with 179 additions and 179 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
TESTING.rst
View File

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

2
doc/source/admin/archives/config-agents.rst
View File

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

4
doc/source/admin/config-lbaas.rst
View File

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

10
doc/source/admin/config-qos-min-bw.rst
View File

@ -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
<https://review.openstack.org/502306>`__
* `on review.opendev.org
<https://review.opendev.org/502306>`__
* Relevant OpenStack Networking API references
@ -584,8 +584,8 @@ Links
* Implementation
* `on review.openstack.org
<https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placement-api+OR+topic:bp/bandwidth-resource-provider>`_
* `on review.opendev.org
<https://review.opendev.org/#/q/topic:minimum-bandwidth-allocation-placement-api+OR+topic:bp/bandwidth-resource-provider>`_
* Known Bugs

2
doc/source/admin/config-qos.rst
View File

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

2
doc/source/contributor/alembic_migrations.rst
View File

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

38
doc/source/contributor/contribute.rst
View File

@ -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>`_.

8
doc/source/contributor/dashboards/index.rst
View File

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

4
doc/source/contributor/development_environment.rst
View File

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

18
doc/source/contributor/effective_neutron.rst
View File

@ -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/>`_
or `network availability zones <https://review.openstack.org/#/c/257086/>`_).
be very efficient over others (some examples include `router gateways <https://review.opendev.org/#/c/88665/>`_
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

10
doc/source/contributor/internals/api_layer.rst
View File

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

4
doc/source/contributor/internals/db_models.rst
View File

@ -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/
[3]. https://review.openstack.org/#/c/348757/
[2]. https://review.opendev.org/#/c/348562/
[3]. https://review.opendev.org/#/c/348757/

12
doc/source/contributor/internals/objects_usage.rst
View File

@ -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://git.openstack.org/cgit/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://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#n258
.. [#] https://opendev.org/openstack/neutron/tree/neutron/db/standard_attr.py?h=stable/ocata
.. [#] https://opendev.org/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n516
.. [#] 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://git.openstack.org/cgit/openstack/neutron-lib/tree/neutron_lib/objects/utils.py
.. [#] https://opendev.org/openstack/neutron/tree/neutron/objects/rbac_db.py?h=stable/ocata#n291
.. [#] https://opendev.org/openstack/neutron-lib/tree/neutron_lib/objects/utils.py

2
doc/source/contributor/internals/openvswitch_agent.rst
View File

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

10
doc/source/contributor/internals/policy.rst
View File

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

2
doc/source/contributor/internals/provisioning_blocks.rst
View File

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

10
doc/source/contributor/internals/quota.rst
View File

@ -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
.. [#] DB Quota driver class: http://git.openstack.org/cgit/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
.. [#] Neutron resource attribute map: http://git.openstack.org/cgit/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
.. [#] Subnet allocation extension: http://opendev.org/openstack/neutron/tree/neutron/extensions/subnetallocation.py
.. [#] DB Quota driver class: http://opendev.org/openstack/neutron/tree/neutron/db/quota/driver.py#n30
.. [#] Quota API extension controller: http://opendev.org/openstack/neutron/tree/neutron/extensions/quotasv2.py#n40
.. [#] Neutron resource attribute map: http://opendev.org/openstack/neutron/tree/neutron/api/v2/attributes.py#n639
.. [#] 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

10
doc/source/contributor/internals/security_group_api.rst
View File

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

6
doc/source/contributor/internals/service_extensions.rst
View File

@ -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://git.openstack.org/cgit/openstack/neutron-lbaas/
#. http://git.openstack.org/cgit/openstack/neutron-vpnaas/
#. http://opendev.org/openstack/neutron-fwaas/
#. http://opendev.org/openstack/neutron-lbaas/
#. http://opendev.org/openstack/neutron-vpnaas/
Calling the Core Plugin from Services

4
doc/source/contributor/internals/services_and_agents.rst
View File

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

2
doc/source/contributor/internals/tag.rst
View File

@ -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/>`_.

6
doc/source/contributor/policies/blueprints.rst
View File

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

6
doc/source/contributor/policies/bugs.rst
View File

@ -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>`_
and `python-neutronclient <https://review.openstack.org/#/q/status:open+label:Verified-2+project:openstack/python-neutronclient>`_
check already verified bugs for `Neutron <https://review.opendev.org/#/q/status:open+label:Verified-2+project:openstack/neutron>`_
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

2
doc/source/contributor/policies/code-reviews.rst
View File

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

2
doc/source/contributor/policies/gate-failure-triage.rst
View File

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

16
doc/source/contributor/policies/neutron-teams.rst
View File

@ -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/python-neutronclient <https://git.openstack.org/cgit/openstack/python-neutronclient/>`_
* `openstack/neutron <https://opendev.org/openstack/neutron/>`_
* `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:

6
doc/source/contributor/policies/release-checklist.rst
View File

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

4
doc/source/contributor/policies/thirdparty-ci.rst
View File

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

56
doc/source/contributor/stadium/governance.rst
View File

@ -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/>`_
allowed projects to be `automatically <http://git.openstack.org/cgit/openstack/governance/commit/?id=321a020cbcaada01976478ea9f677ebb4df7bd6d>`_
acceptable for a small number of initiatives. When the proposed `arrangement <https://review.opendev.org/#/c/175952/>`_
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.openstack.org/#/c/346272/
* https://review.openstack.org/#/c/346083/
* https://review.opendev.org/#/c/346091/
* https://review.opendev.org/#/c/346272/
* 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/>`_.
* `Networking-OVN <https://review.openstack.org/#/c/335791>`_.
* `Networking-Midonet <https://review.openstack.org/#/c/315033>`_.
* `Neutron <https://review.opendev.org/#/c/278832/>`_.
* `Networking-OVN <https://review.opendev.org/#/c/335791>`_.
* `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.openstack.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/jenkins/jobs/projects.yaml@4685
#. https://review.opendev.org/#/c/338603/3/zuul/layout.yaml@8501
#. 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.openstack.org/#/c/359143/
#. https://review.opendev.org/#/c/357086/
#. 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.openstack.org/#/c/353132/
* https://review.opendev.org/#/c/353131/
* 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.openstack.org/#/c/243085/
* https://review.opendev.org/#/c/320904/
* 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.openstack.org/#/c/340763/
* https://review.openstack.org/#/c/352653/
* https://review.opendev.org/#/c/340624/
* https://review.opendev.org/#/c/340763/
* 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.

12
doc/source/contributor/stadium/guidelines.rst
View File

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

2
doc/source/contributor/testing/template_model_sync_test.rst
View File

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

2
neutron/agent/common/ovs_lib.py
View File

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

2
neutron/db/l3_hamode_db.py
View File

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

2
neutron/extensions/_availability_zone_filter_lib.py
View File

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

2
neutron/extensions/_filter_validation_lib.py
View File

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

2
neutron/extensions/_standard_attr_segment_lib.py
View File

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

2
neutron/plugins/ml2/drivers/linuxbridge/agent/extension_drivers/qos_driver.py
View File

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

2
neutron/plugins/ml2/drivers/macvtap/mech_driver/mech_macvtap.py
View File

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

2
neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
View File

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

2
neutron/plugins/ml2/managers.py
View File

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

2
neutron/plugins/ml2/plugin.py
View File

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

12
neutron/services/network_segment_range/plugin.py
View File

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

2
neutron/services/placement_report/plugin.py
View File

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

2
neutron/services/qos/qos_plugin.py
View File

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

2
neutron/tests/contrib/hooks/qos
View File

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

2
neutron/tests/fullstack/agents/ovs_agent.py
View File

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

2
neutron/tests/fullstack/test_l3_agent.py
View File

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

2
neutron/tests/functional/agent/l3/framework.py
View File

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

2
neutron/tests/functional/base.py
View File

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

2
neutron/tests/functional/db/test_migrations.py
View File

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

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

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

4
roles/configure_functional_tests/README.rst
View File

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

16
tools/abandon_old_reviews.sh
View File

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

2
tools/split.sh
View File

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

2
tox.ini
View File

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