diff --git a/TESTING.rst b/TESTING.rst index a8321a238bb..c0e58e6f9f2 100644 --- a/TESTING.rst +++ b/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 `_ +* Check out the latest `merge commit `_ * Go to: http://logs.openstack.org///post/neutron-coverage/. -* `Spec `_ is a work in progress to +* `Spec `_ is a work in progress to provide a better landing page. Debugging diff --git a/doc/source/admin/archives/config-agents.rst b/doc/source/admin/archives/config-agents.rst index 925547cb84b..2002ac2c3dc 100644 --- a/doc/source/admin/archives/config-agents.rst +++ b/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: diff --git a/doc/source/admin/config-lbaas.rst b/doc/source/admin/config-lbaas.rst index b29c31a1166..39a5ea2a786 100644 --- a/doc/source/admin/config-lbaas.rst +++ b/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 - `__ + `__ 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 diff --git a/doc/source/admin/config-qos-min-bw.rst b/doc/source/admin/config-qos-min-bw.rst index 05d9dd5f0b7..7901616f822 100644 --- a/doc/source/admin/config-qos-min-bw.rst +++ b/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 `__ - * `on review.openstack.org `__ + * `on review.opendev.org `__ * Nova spec: Network Bandwidth resource provider * `on specs.openstack.org `__ - * `on review.openstack.org - `__ + * `on review.opendev.org + `__ * Relevant OpenStack Networking API references @@ -584,8 +584,8 @@ Links * Implementation - * `on review.openstack.org - `_ + * `on review.opendev.org + `_ * Known Bugs diff --git a/doc/source/admin/config-qos.rst b/doc/source/admin/config-qos.rst index 92ac3edea14..f164cd6557a 100644 --- a/doc/source/admin/config-qos.rst +++ b/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 -`_: +`_: * bandwidth_limit: Bandwidth limitations on networks, ports or floating IPs. diff --git a/doc/source/contributor/alembic_migrations.rst b/doc/source/contributor/alembic_migrations.rst index 39017af359b..259135d4f18 100644 --- a/doc/source/contributor/alembic_migrations.rst +++ b/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 `_ is a patch that tags +For example, `here `_ is a patch that tags the liberty milestone revisions for the neutron-fwaas sub-project. Note that each branch (expand and contract) is tagged. diff --git a/doc/source/contributor/contribute.rst b/doc/source/contributor/contribute.rst index 151cc5d6891..fe01f34dbbd 100644 --- a/doc/source/contributor/contribute.rst +++ b/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 `_ is used, +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 -`_ +`_ uses them. For more details see `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 `_. * 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 - `_. + `_. * 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 - `_?). Armando and Akihiro to discuss. + `_?). 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 `_. diff --git a/doc/source/contributor/dashboards/index.rst b/doc/source/contributor/dashboards/index.rst index 483566e08fd..631b4224b33 100644 --- a/doc/source/contributor/dashboards/index.rst +++ b/doc/source/contributor/dashboards/index.rst @@ -4,10 +4,10 @@ CI Status Dashboards Gerrit Dashboards ----------------- -- `Neutron master branch reviews `_ -- `Neutron subproject reviews (master branch) `_ -- `Neutron stable branch reviews `_ -- `Neutron Infra reviews `_ +- `Neutron master branch reviews `_ +- `Neutron subproject reviews (master branch) `_ +- `Neutron stable branch reviews `_ +- `Neutron Infra reviews `_ These dashboard links can be generated by `Gerrit Dashboard Creator`_. Useful dashboard definitions are found in ``dashboards`` directory. diff --git a/doc/source/contributor/development_environment.rst b/doc/source/contributor/development_environment.rst index aa333e1a7d1..e8144344180 100644 --- a/doc/source/contributor/development_environment.rst +++ b/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 diff --git a/doc/source/contributor/effective_neutron.rst b/doc/source/contributor/effective_neutron.rst index 31dfbd849af..c7e91e08d06 100644 --- a/doc/source/contributor/effective_neutron.rst +++ b/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 `_ + but their strength is also a weakness, as they can introduce `unpredictable `_ behavior to the `MRO `_, amongst other issues. * In lieu of mixins, if you need to add behavior that is relevant for ML2, consider using the `extension manager `_. * 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 `_. + controller `backends `_. * If you make changes to the ML2 plugin or components used by the ML2 plugin, think about the `effect `_ 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 `_ at all. + with the server. Plugins may not rely on `agents `_ at all. * Be mindful of required capabilities when you develop plugin extensions. The `Extension description `_ 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 `_. For instance a joined relationship can - be very efficient over others (some examples include `router gateways `_ - or `network availability zones `_). + be very efficient over others (some examples include `router gateways `_ + or `network availability zones `_). * 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 `_ + performance. For example, see `patch 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 `_ which reduced a + `patch 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 `_ which changed the + `patch 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 `_, but + consider using `OpenFixture `_, but it is better not to mock open() at all. Documentation diff --git a/doc/source/contributor/internals/api_layer.rst b/doc/source/contributor/internals/api_layer.rst index dd23fb97533..fb8423b3627 100644 --- a/doc/source/contributor/internals/api_layer.rst +++ b/doc/source/contributor/internals/api_layer.rst @@ -33,14 +33,14 @@ Server Gateway Interface (WSGI) - defined in `PEP 333 `_ +Neutron's WSGI server is started from the `server module `_ 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/ diff --git a/doc/source/contributor/internals/db_models.rst b/doc/source/contributor/internals/db_models.rst index 5063202d990..edb112f662f 100644 --- a/doc/source/contributor/internals/db_models.rst +++ b/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/ -[3]. https://review.openstack.org/#/c/348757/ +[2]. https://review.opendev.org/#/c/348562/ +[3]. https://review.opendev.org/#/c/348757/ diff --git a/doc/source/contributor/internals/objects_usage.rst b/doc/source/contributor/internals/objects_usage.rst index 259d0470531..fca84fe7f4d 100644 --- a/doc/source/contributor/internals/objects_usage.rst +++ b/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://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 diff --git a/doc/source/contributor/internals/openvswitch_agent.rst b/doc/source/contributor/internals/openvswitch_agent.rst index de60f6b3360..1abd85310ce 100644 --- a/doc/source/contributor/internals/openvswitch_agent.rst +++ b/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 diff --git a/doc/source/contributor/internals/policy.rst b/doc/source/contributor/internals/policy.rst index 239d521d819..037352fcbeb 100644 --- a/doc/source/contributor/internals/policy.rst +++ b/doc/source/contributor/internals/policy.rst @@ -395,23 +395,23 @@ OpenStack projects. References ---------- -.. [#] `Oslo policy module `_ +.. [#] `Oslo policy module `_ .. [#] `Oslo policy developer `_ .. [#] 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 diff --git a/doc/source/contributor/internals/provisioning_blocks.rst b/doc/source/contributor/internals/provisioning_blocks.rst index ed8ef8df799..83c829e00df 100644 --- a/doc/source/contributor/internals/provisioning_blocks.rst +++ b/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 -`_ +`_ 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. diff --git a/doc/source/contributor/internals/quota.rst b/doc/source/contributor/internals/quota.rst index 1dc7db9848a..eebbc78d199 100644 --- a/doc/source/contributor/internals/quota.rst +++ b/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 -.. [#] 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 diff --git a/doc/source/contributor/internals/security_group_api.rst b/doc/source/contributor/internals/security_group_api.rst index 50cbb2e26c1..c0b1f264cc2 100644 --- a/doc/source/contributor/internals/security_group_api.rst +++ b/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 `_ +* `Plugin RPC classes `_ - * `SecurityGroupServerRpcMixin `_ - defines the RPC API that the plugin uses to communicate with the agents running on the compute nodes + * `SecurityGroupServerRpcMixin `_ - 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 `_ +* `Agent RPC classes `_ * 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. diff --git a/doc/source/contributor/internals/service_extensions.rst b/doc/source/contributor/internals/service_extensions.rst index c2b09696bdb..537bba22ed5 100644 --- a/doc/source/contributor/internals/service_extensions.rst +++ b/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://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 diff --git a/doc/source/contributor/internals/services_and_agents.rst b/doc/source/contributor/internals/services_and_agents.rst index a23a61aba64..b5056d0541a 100644 --- a/doc/source/contributor/internals/services_and_agents.rst +++ b/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 -`_). +`_). 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 `_. +corresponding cross-project spec `_. Connecting to the Database diff --git a/doc/source/contributor/internals/tag.rst b/doc/source/contributor/internals/tag.rst index 9e6673707e8..e213f52b6f0 100644 --- a/doc/source/contributor/internals/tag.rst +++ b/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 `_. +framework `_. diff --git a/doc/source/contributor/policies/blueprints.rst b/doc/source/contributor/policies/blueprints.rst index 15b02320cff..cda90a66df4 100644 --- a/doc/source/contributor/policies/blueprints.rst +++ b/doc/source/contributor/policies/blueprints.rst @@ -2,7 +2,7 @@ Blueprints and Specs ==================== The Neutron team uses the `neutron-specs -`_ repository for its +`_ repository for its specification reviews. Detailed information can be found on the `wiki `_. 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 -`_ +`_ 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 `_ +The `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 diff --git a/doc/source/contributor/policies/bugs.rst b/doc/source/contributor/policies/bugs.rst index f7c571a8527..f6bf9503ef5 100644 --- a/doc/source/contributor/policies/bugs.rst +++ b/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 -`_ gerrit group. +`_ 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 `_ - and `python-neutronclient `_ + check already verified bugs for `Neutron `_ + and `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 diff --git a/doc/source/contributor/policies/code-reviews.rst b/doc/source/contributor/policies/code-reviews.rst index a4be655b4e1..962f372209f 100644 --- a/doc/source/contributor/policies/code-reviews.rst +++ b/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 - `_ + `_ that would help interested parties to identify their platform limitation in timely manner. diff --git a/doc/source/contributor/policies/gate-failure-triage.rst b/doc/source/contributor/policies/gate-failure-triage.rst index b528062f84c..40c46c39a6f 100644 --- a/doc/source/contributor/policies/gate-failure-triage.rst +++ b/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 - ``_. + ``_. 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 diff --git a/doc/source/contributor/policies/neutron-teams.rst b/doc/source/contributor/policies/neutron-teams.rst index 870a393d116..27f7985f05f 100644 --- a/doc/source/contributor/policies/neutron-teams.rst +++ b/doc/source/contributor/policies/neutron-teams.rst @@ -1,7 +1,7 @@ Neutron Core Reviewers ====================== -The `Neutron Core Reviewer Team `_ +The `Neutron Core Reviewer Team `_ 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 `_ have +`Neutron core reviewers `_ have merge rights to the following git repositories: -* `openstack/neutron `_ -* `openstack/python-neutronclient `_ +* `openstack/neutron `_ +* `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 `_ +Neutron `specs core reviewers `_ have +2 rights to the following git repositories: -* `openstack/neutron-specs `_ +* `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 `_ is +The `drivers team `_ is the group of people who have full rights to the specs repo. This team, which matches `Launchpad Neutron Drivers team `_, 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 `_ is +The `release team `_ is a group of people with some additional gerrit permissions primarily aimed at allowing release management of Neutron sub-projects. These permissions include: diff --git a/doc/source/contributor/policies/release-checklist.rst b/doc/source/contributor/policies/release-checklist.rst index f4bcda861d9..2964a99e4d3 100644 --- a/doc/source/contributor/policies/release-checklist.rst +++ b/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: diff --git a/doc/source/contributor/policies/thirdparty-ci.rst b/doc/source/contributor/policies/thirdparty-ci.rst index b6faa3da99f..dfc5b7d25f5 100644 --- a/doc/source/contributor/policies/thirdparty-ci.rst +++ b/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 diff --git a/doc/source/contributor/stadium/governance.rst b/doc/source/contributor/stadium/governance.rst index da363297b4f..49fdef6d653 100644 --- a/doc/source/contributor/stadium/governance.rst +++ b/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 `_ -allowed projects to be `automatically `_ +acceptable for a small number of initiatives. When the proposed `arrangement `_ +allowed projects to be `automatically `_ 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 `_. +record of alignment with the Neutron `core project `_. 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 `_. @@ -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 `_. - * `Networking-OVN `_. - * `Networking-Midonet `_. + * `Neutron `_. + * `Networking-OVN `_. + * `Networking-Midonet `_. 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 `_ introduced such + `patch `_ 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 `_ you must contribute the API documentation into neutron-lib's api-ref - directory as done in the `WADL/REST transition patch `_. + directory as done in the `WADL/REST transition patch `_. Once this is done successfully, a link to the subproject API will show under the published `table of content `_. 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 `_ + The `neutron-lib patch `_ 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 `_ + The `neutron patch `_ 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 `_ to + `network `_ 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. diff --git a/doc/source/contributor/stadium/guidelines.rst b/doc/source/contributor/stadium/guidelines.rst index 080d17ad49b..13563fcdc2f 100644 --- a/doc/source/contributor/stadium/guidelines.rst +++ b/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 -`_. +`_. 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 `_. +team `_. More info on stable branch process can be found on `the following page `_. @@ -110,7 +110,7 @@ Stable merge requirements ------------------------- Merges into stable branches are handled by members of the `neutron-stable-maint -gerrit group `_. The +gerrit group `_. 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 -`_. The +`_. The `neutron-release team -`_ handles only the +`_ 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 - `_ a patch + `_ a patch to openstack/releases repository with the intended git hash. `The Neutron release liaison `_ should be added in Gerrit to the list of reviewers for the patch. diff --git a/doc/source/contributor/testing/template_model_sync_test.rst b/doc/source/contributor/testing/template_model_sync_test.rst index befc315220c..22fac3ed9d1 100644 --- a/doc/source/contributor/testing/template_model_sync_test.rst +++ b/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 `_ +Example implementation `in VPNaaS `_ diff --git a/neutron/agent/common/ovs_lib.py b/neutron/agent/common/ovs_lib.py index 360754610f9..0987ab78217 100644 --- a/neutron/agent/common/ovs_lib.py +++ b/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, diff --git a/neutron/db/l3_hamode_db.py b/neutron/db/l3_hamode_db.py index ef2ec10595c..a0c75d71424 100644 --- a/neutron/db/l3_hamode_db.py +++ b/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 diff --git a/neutron/extensions/_availability_zone_filter_lib.py b/neutron/extensions/_availability_zone_filter_lib.py index cf54b53bd25..0900ef954f7 100644 --- a/neutron/extensions/_availability_zone_filter_lib.py +++ b/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 diff --git a/neutron/extensions/_filter_validation_lib.py b/neutron/extensions/_filter_validation_lib.py index ba6fb4d1639..94f7c3b9540 100644 --- a/neutron/extensions/_filter_validation_lib.py +++ b/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. """ diff --git a/neutron/extensions/_standard_attr_segment_lib.py b/neutron/extensions/_standard_attr_segment_lib.py index f5b5fb7641f..cc39443d3c1 100644 --- a/neutron/extensions/_standard_attr_segment_lib.py +++ b/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. """ diff --git a/neutron/plugins/ml2/drivers/linuxbridge/agent/extension_drivers/qos_driver.py b/neutron/plugins/ml2/drivers/linuxbridge/agent/extension_drivers/qos_driver.py index 93825202720..37bbe8f1d47 100644 --- a/neutron/plugins/ml2/drivers/linuxbridge/agent/extension_drivers/qos_driver.py +++ b/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', diff --git a/neutron/plugins/ml2/drivers/macvtap/mech_driver/mech_macvtap.py b/neutron/plugins/ml2/drivers/macvtap/mech_driver/mech_macvtap.py index 77e9023e5a9..25df0b3ba80 100644 --- a/neutron/plugins/ml2/drivers/macvtap/mech_driver/mech_macvtap.py +++ b/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 diff --git a/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py b/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py index 23822d88df8..122aa9c0d3b 100644 --- a/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py +++ b/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() diff --git a/neutron/plugins/ml2/managers.py b/neutron/plugins/ml2/managers.py index d738323ebcd..78cefba5836 100644 --- a/neutron/plugins/ml2/managers.py +++ b/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 # diff --git a/neutron/plugins/ml2/plugin.py b/neutron/plugins/ml2/plugin.py index 6397826e002..c53577fb676 100644 --- a/neutron/plugins/ml2/plugin.py +++ b/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]): diff --git a/neutron/services/network_segment_range/plugin.py b/neutron/services/network_segment_range/plugin.py index 8dbd28e577f..b75a27526bb 100644 --- a/neutron/services/network_segment_range/plugin.py +++ b/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 diff --git a/neutron/services/placement_report/plugin.py b/neutron/services/placement_report/plugin.py index da0eb6f04b5..4fdbece44bc 100644 --- a/neutron/services/placement_report/plugin.py +++ b/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( diff --git a/neutron/services/qos/qos_plugin.py b/neutron/services/qos/qos_plugin.py index 9706c6e4a73..f8455db34e3 100644 --- a/neutron/services/qos/qos_plugin.py +++ b/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] diff --git a/neutron/tests/contrib/hooks/qos b/neutron/tests/contrib/hooks/qos index 21bb1ff4674..7e2798f4ef5 100644 --- a/neutron/tests/contrib/hooks/qos +++ b/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 diff --git a/neutron/tests/fullstack/agents/ovs_agent.py b/neutron/tests/fullstack/agents/ovs_agent.py index 32b440f0c0d..a4c7801f562 100755 --- a/neutron/tests/fullstack/agents/ovs_agent.py +++ b/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() diff --git a/neutron/tests/fullstack/test_l3_agent.py b/neutron/tests/fullstack/test_l3_agent.py index a98f1703f28..5f4257723cd 100644 --- a/neutron/tests/fullstack/test_l3_agent.py +++ b/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) diff --git a/neutron/tests/functional/agent/l3/framework.py b/neutron/tests/functional/agent/l3/framework.py index 67eac23dc1f..2bef7df3fb2 100644 --- a/neutron/tests/functional/agent/l3/framework.py +++ b/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) diff --git a/neutron/tests/functional/base.py b/neutron/tests/functional/base.py index 20a77bdd519..a2cfab036b9 100644 --- a/neutron/tests/functional/base.py +++ b/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( diff --git a/neutron/tests/functional/db/test_migrations.py b/neutron/tests/functional/db/test_migrations.py index 998baa06159..b5af64498f0 100644 --- a/neutron/tests/functional/db/test_migrations.py +++ b/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 diff --git a/neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_tun.py b/neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_tun.py index ee5bd9af26d..9e4cc168b9d 100644 --- a/neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/test_br_tun.py +++ b/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 diff --git a/roles/configure_functional_tests/README.rst b/roles/configure_functional_tests/README.rst index 0fb2f575289..c2e72b40536 100644 --- a/roles/configure_functional_tests/README.rst +++ b/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 diff --git a/tools/abandon_old_reviews.sh b/tools/abandon_old_reviews.sh index 7933de82105..eaf71dbc2cd 100755 --- a/tools/abandon_old_reviews.sh +++ b/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 # 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 < 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 < .gitreview <