Update the documentation link for doc migration

* Update the URLs affected by the doc-migration
  (/developer/<project>/ to <project>/latest/)
* Follow content rearrangement
* Convert links to local documents into :doc: or :ref:
* Use https instead of http for the updated links on docs.openstack.org.

Part of the doc-migration work.

Change-Id: I62e317d9198f175a43d73bbfd419b6878de90d5a
This commit is contained in:
Akihiro Motoki 2017-07-21 16:05:21 +09:00
parent fe6a43b5e3
commit d3c393ff6b
33 changed files with 88 additions and 77 deletions

View File

@ -1,7 +1,7 @@
If you would like to contribute to the development of OpenStack Networking, If you would like to contribute to the development of OpenStack Networking,
you must follow the steps documented at: you must follow the steps documented at:
http://docs.openstack.org/developer/neutron/policies/blueprints.html https://docs.openstack.org/neutron/latest/policies/blueprints.html
Pull requests submitted through GitHub will be ignored. Pull requests submitted through GitHub will be ignored.

View File

@ -2,14 +2,14 @@ Neutron Style Commandments
========================== ==========================
- Step 1: Read the OpenStack Style Commandments - Step 1: Read the OpenStack Style Commandments
http://docs.openstack.org/developer/hacking/ https://docs.openstack.org/hacking/latest/
- Step 2: Read on - Step 2: Read on
Neutron Specific Commandments Neutron Specific Commandments
----------------------------- -----------------------------
Some rules are enforced by `neutron-lib hacking factory Some rules are enforced by `neutron-lib hacking factory
<https://docs.openstack.org/developer/neutron-lib/usage.html#hacking-checks>`_ <https://docs.openstack.org/neutron-lib/latest/user/hacking.html>`_
while other rules are specific to Neutron repository. while other rules are specific to Neutron repository.
Below you can find a list of checks specific to this repository. Below you can find a list of checks specific to this repository.

View File

@ -381,7 +381,7 @@ Scenario Tests
Scenario tests (neutron/tests/tempest/scenario), like API tests, use the Scenario tests (neutron/tests/tempest/scenario), like API tests, use the
Tempest test infrastructure and have the same requirements. Guidelines for Tempest test infrastructure and have the same requirements. Guidelines for
writing a good scenario test may be found at the Tempest developer guide: writing a good scenario test may be found at the Tempest developer guide:
http://docs.openstack.org/developer/tempest/field_guide/scenario.html https://docs.openstack.org/tempest/latest/field_guide/scenario.html
Scenario tests, like API tests, are split between the Tempest and Neutron Scenario tests, like API tests, are split between the Tempest and Neutron
repositories according to the Neutron API the test is targeting. repositories according to the Neutron API the test is targeting.

View File

@ -33,7 +33,7 @@ Networking API call has a corresponding :command:`neutron` command.
The :command:`openstack` CLI is a common interface for all OpenStack The :command:`openstack` CLI is a common interface for all OpenStack
projects, however, not every API operation has been implemented. For the projects, however, not every API operation has been implemented. For the
list of available commands, see `Command List list of available commands, see `Command List
<https://docs.openstack.org/developer/python-openstackclient/command-list.html>`__. <https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html>`__.
The :command:`neutron` CLI includes a number of options. For details, see The :command:`neutron` CLI includes a number of options. For details, see
`Create and manage networks <https://docs.openstack.org/user-guide/cli-create-and-manage-networks.html>`__. `Create and manage networks <https://docs.openstack.org/user-guide/cli-create-and-manage-networks.html>`__.

View File

@ -15,7 +15,7 @@ There are two reference implementations of LBaaS v2.
The one is an agent based implementation with HAProxy. The one is an agent based implementation with HAProxy.
The agents handle the HAProxy configuration and manage the HAProxy daemon. The agents handle the HAProxy configuration and manage the HAProxy daemon.
Another LBaaS v2 implementation, `Octavia Another LBaaS v2 implementation, `Octavia
<https://docs.openstack.org/developer/octavia/>`_, has a separate API and <https://docs.openstack.org/octavia/latest/>`_, has a separate API and
separate worker processes that build load balancers within virtual machines on separate worker processes that build load balancers within virtual machines on
hypervisors that are managed by the Compute service. You do not need an agent hypervisors that are managed by the Compute service. You do not need an agent
for Octavia. for Octavia.
@ -141,7 +141,7 @@ The `Hands on Lab - Install and Configure OpenStack Octavia
session at the OpenStack Summit in Tokyo provides an overview of Octavia. session at the OpenStack Summit in Tokyo provides an overview of Octavia.
The DevStack documentation offers a `simple method to deploy Octavia The DevStack documentation offers a `simple method to deploy Octavia
<https://docs.openstack.org/developer/devstack/guides/devstack-with-lbaas-v2.html>`_ <https://docs.openstack.org/devstack/latest/guides/devstack-with-lbaas-v2.html>`_
and test the service with redundant load balancer instances. If you already and test the service with redundant load balancer instances. If you already
have Octavia installed and configured within your environment, you can have Octavia installed and configured within your environment, you can
configure the Network service to use Octavia: configure the Network service to use Octavia:

View File

@ -45,8 +45,7 @@ node. For more information, see the
installation guide (select an appropriate OVS version in the installation guide (select an appropriate OVS version in the
:guilabel:`Branch` drop-down menu). :guilabel:`Branch` drop-down menu).
`Neutron configuration reference for OVS-DPDK :doc:`/contributor/internals/ovs_vhostuser`
<https://docs.openstack.org/developer/neutron/devref/ovs_vhostuser.html>`__
for configuration of neutron OVS agent. for configuration of neutron OVS agent.
In case you wish to configure multiqueue, see the In case you wish to configure multiqueue, see the

View File

@ -50,6 +50,6 @@ Enable the native OVS firewall driver
[securitygroup] [securitygroup]
firewall_driver = openvswitch firewall_driver = openvswitch
For more information, see the `Open vSwitch Firewall Driver For more information, see the
<https://docs.openstack.org/developer/neutron/devref/openvswitch_firewall.html>`_ :doc:`/contributor/internals/openvswitch_firewall`
and the `video <https://www.youtube.com/watch?v=SOHeZ3g9yxM>`_. and the `video <https://www.youtube.com/watch?v=SOHeZ3g9yxM>`_.

View File

@ -64,8 +64,8 @@ path rendering.
.. image:: figures/port-chain-diagram.png .. image:: figures/port-chain-diagram.png
:alt: Port chain model :alt: Port chain model
See the `developer documentation See the `networking-sfc documentation
<https://docs.openstack.org/developer/networking-sfc/>`_ for more information. <https://docs.openstack.org/networking-sfc/latest/>`_ for more information.
Resources Resources
~~~~~~~~~ ~~~~~~~~~

View File

@ -28,4 +28,4 @@ The client command extension adds support for extending the neutron client while
considering ease of creation. considering ease of creation.
The full document can be found in the python-neutronclient repository: The full document can be found in the python-neutronclient repository:
http://docs.openstack.org/developer/python-neutronclient/contributor/client_command_extensions.html https://docs.openstack.org/python-neutronclient/latest/contributor/client_command_extensions.html

View File

@ -89,8 +89,7 @@ and examples below. We'll describe best practices for:
* Documentation; * Documentation;
Once you have everything in place you may want to add your project to the list Once you have everything in place you may want to add your project to the list
of Neutron sub-projects. See `Adding or removing projects to the stadium of Neutron sub-projects. See :ref:`add-remove-projects-to-stadium`
<http://docs.openstack.org/developer/neutron/stadium/governance.html#adding-or-removing-projects-to-the-stadium>`_
for details. for details.
@ -109,16 +108,15 @@ automatically provided. Contributors should follow the review guidelines
similar to those of Neutron. However, you as the maintainer have the similar to those of Neutron. However, you as the maintainer have the
flexibility to choose who can approve/merge changes in your own repo. flexibility to choose who can approve/merge changes in your own repo.
It is recommended (but not required, see `policies It is recommended (but not required,
<http://docs.openstack.org/developer/neutron/policies/thirdparty-ci.html>`_) see :doc:`policies <policies/thirdparty-ci>`)
that you set up a third-party CI system. This will provide a vehicle for that you set up a third-party CI system. This will provide a vehicle for
checking the third-party code against Neutron changes. See `Testing and checking the third-party code against Neutron changes. See `Testing and
Continuous Integration`_ below for more detailed recommendations. Continuous Integration`_ below for more detailed recommendations.
Design documents can still be supplied in form of Restructured Text (RST) Design documents can still be supplied in form of Restructured Text (RST)
documents, within the same third-party library repo. If changes to the common documents, within the same third-party library repo. If changes to the common
Neutron code are required, an `RFE Neutron code are required, an :ref:`RFE <request-for-feature-enhancement>`
<http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements>`_
may need to be filed. However, every case is different and you are invited to may need to be filed. However, every case is different and you are invited to
seek guidance from Neutron core reviewers about what steps to follow. seek guidance from Neutron core reviewers about what steps to follow.
@ -262,7 +260,7 @@ driver.
If you are contributing a new plugin, the approach to choose should be based on If you are contributing a new plugin, the approach to choose should be based on
`Extras.d Hooks' externally hosted plugins `Extras.d Hooks' externally hosted plugins
<http://docs.openstack.org/developer/devstack/plugins.html#extras-d-hooks>`_. <https://docs.openstack.org/devstack/latest/plugins.html#extras-d-hooks>`_.
With the extra.d hooks, the DevStack integration is co-located with the With the extra.d hooks, the DevStack integration is co-located with the
third-party integration library, and it leads to the greatest level of third-party integration library, and it leads to the greatest level of
flexibility when dealing with DevStack based dev/test deployments. flexibility when dealing with DevStack based dev/test deployments.
@ -339,7 +337,7 @@ oslo.i18n
* Each subproject repository should have its own oslo.i18n integration * Each subproject repository should have its own oslo.i18n integration
wrapper module ``${MODULE_NAME}/_i18n.py``. The detail is found at wrapper module ``${MODULE_NAME}/_i18n.py``. The detail is found at
http://docs.openstack.org/developer/oslo.i18n/usage.html. https://docs.openstack.org/oslo.i18n/latest/usage.html.
.. note:: .. note::
@ -486,11 +484,10 @@ directory as an entrypoint in the ``neutron.db.alembic_migrations`` group::
DB Model/Migration Testing DB Model/Migration Testing
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
Here is a `template functional test Here is a :doc:`template functional test <testing/template_model_sync_test>`
<http://docs.openstack.org/developer/neutron/devref/template_model_sync_test.html>`_ third-party third-party maintainers can use to develop tests for model-vs-migration sync in
maintainers can use to develop tests for model-vs-migration sync in their their repos. It is recommended that each third-party CI sets up such a test,
repos. It is recommended that each third-party CI sets up such a test, and runs and runs it regularly against Neutron master.
it regularly against Neutron master.
Entry Points Entry Points
~~~~~~~~~~~~ ~~~~~~~~~~~~

View File

@ -214,8 +214,8 @@ and interacting with linux utils.
tool, check if common platforms ship packages with the aforementioned tool, check if common platforms ship packages with the aforementioned
feature. Also, tag such a patch with ``UpgradeImpact`` to raise its feature. Also, tag such a patch with ``UpgradeImpact`` to raise its
visibility (as these patches are brought up to the attention of the core team visibility (as these patches are brought up to the attention of the core team
during team meetings). More details in `review guidelines during team meetings).
<http://docs.openstack.org/developer/neutron/policies/code-reviews.html#neutron-spec-review-practices>`_. More details in :ref:`review guidelines <spec-review-practices>`.
* When a patch or the code depends on a new feature in the kernel or in any platform tools * When a patch or the code depends on a new feature in the kernel or in any platform tools
(dnsmasq, ip, Open vSwitch etc.), consider introducing a new sanity check to (dnsmasq, ip, Open vSwitch etc.), consider introducing a new sanity check to
validate deployments for the expected features. Note that sanity checks *must validate deployments for the expected features. Note that sanity checks *must
@ -301,9 +301,9 @@ Deprecation
Sometimes we want to refactor things in a non-backward compatible way. In most Sometimes we want to refactor things in a non-backward compatible way. In most
cases you can use `debtcollector cases you can use `debtcollector
<http://docs.openstack.org/developer/debtcollector>`_ to mark things for <http://docs.openstack.org/debtcollector/latest/>`_ to mark things for
deprecation. Config items have `deprecation options supported by oslo.config deprecation. Config items have `deprecation options supported by oslo.config
<http://docs.openstack.org/developer/oslo.config/opts.html>`_. <https://docs.openstack.org/oslo.config/latest/reference/opts.html>`_.
The deprecation process must follow the `standard deprecation requirements The deprecation process must follow the `standard deprecation requirements
<http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements>`_. <http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements>`_.
@ -312,7 +312,7 @@ In terms of neutron development, this means:
* A launchpad bug to track the deprecation. * A launchpad bug to track the deprecation.
* A patch to mark the deprecated items. If the deprecation affects * A patch to mark the deprecated items. If the deprecation affects
users (config items, API changes) then a `release note users (config items, API changes) then a `release note
<http://docs.openstack.org/developer/reno/usage.html>`_ must be <https://docs.openstack.org/reno/latest/user/usage.html>`_ must be
included. included.
* Wait at least one cycle and at least three months linear time. * Wait at least one cycle and at least three months linear time.
* A patch that removes the deprecated items. Make sure to refer to the * A patch that removes the deprecated items. Make sure to refer to the
@ -334,7 +334,7 @@ Document common pitfalls as well as good practices done when instrumenting your
to avoid littering the logs with traces logged at inappropriate levels. to avoid littering the logs with traces logged at inappropriate levels.
* The logger should only be passed unicode values. For example, do not pass it * The logger should only be passed unicode values. For example, do not pass it
exceptions or other objects directly (LOG.error(exc), LOG.error(port), etc.). exceptions or other objects directly (LOG.error(exc), LOG.error(port), etc.).
See http://docs.openstack.org/developer/oslo.log/usage.html#no-more-implicit-conversion-to-unicode-str See https://docs.openstack.org/oslo.log/latest/user/migration.html#no-more-implicit-conversion-to-unicode-str
for more details. for more details.
* Don't pass exceptions into LOG.exception: it is already implicitly included * Don't pass exceptions into LOG.exception: it is already implicitly included
in the log message by Python logging module. in the log message by Python logging module.
@ -450,7 +450,7 @@ IRC
and send public questions to the channel rather then to a specific person if possible. and send public questions to the channel rather then to a specific person if possible.
(This increase the chances of getting faster answers to your questions). (This increase the chances of getting faster answers to your questions).
A list of the areas and lieutenants nicknames can be found at A list of the areas and lieutenants nicknames can be found at
`Core Reviewers <http://docs.openstack.org/developer/neutron/policies/neutron-teams.html>`_. :doc:`Core Reviewers <policies/neutron-teams>`.
Commit messages Commit messages
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~

View File

@ -52,6 +52,7 @@ Database migrations
For details on the neutron-db-manage wrapper and alembic migrations, see For details on the neutron-db-manage wrapper and alembic migrations, see
`Alembic Migrations <alembic_migrations.html>`_. `Alembic Migrations <alembic_migrations.html>`_.
.. _testing-database-migrations:
Tests to verify that database migrations and models are in sync Tests to verify that database migrations and models are in sync
--------------------------------------------------------------- ---------------------------------------------------------------

View File

@ -20,7 +20,7 @@ external DNS service. This interface is based on an abstract driver that can be
used as the base class to implement concrete drivers to interact with various used as the base class to implement concrete drivers to interact with various
DNS services. The reference implementation of such a driver integrates neutron DNS services. The reference implementation of such a driver integrates neutron
with with
`OpenStack Designate <http://docs.openstack.org/developer/designate/index.html>`_. `OpenStack Designate <https://docs.openstack.org/designate/latest/index.html>`_.
This integration allows users to publish *dns_name* and *dns_domain* This integration allows users to publish *dns_name* and *dns_domain*
attributes associated with floating IP addresses, ports, and networks in an attributes associated with floating IP addresses, ports, and networks in an

View File

@ -25,7 +25,7 @@ Neutron Stadium i18n
==================== ====================
* Refer to oslo_i18n documentation for the general mechanisms that should * Refer to oslo_i18n documentation for the general mechanisms that should
be used: http://docs.openstack.org/developer/oslo.i18n/usage.html be used: https://docs.openstack.org/oslo.i18n/latest/user/usage.html
* Each stadium project should NOT consume _i18n module from neutron-lib * Each stadium project should NOT consume _i18n module from neutron-lib
or neutron. or neutron.

View File

@ -41,7 +41,7 @@ dictionary messages by defining a strict structure and keeping strong typing.
Because of it, you can be sure of what is sent and how to use the data on the Because of it, you can be sure of what is sent and how to use the data on the
receiving end. receiving end.
.. _Oslo VersionedObjects: http://docs.openstack.org/developer/oslo.versionedobjects/ .. _Oslo VersionedObjects: https://docs.openstack.org/oslo.versionedobjects/latest/
Usage of objects Usage of objects
---------------- ----------------
@ -635,6 +635,6 @@ References
.. [#] 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/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#n516
.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n542 .. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/base.py?h=stable/ocata#n542
.. [#] http://docs.openstack.org/developer/neutron/devref/db_layer.html#the-standard-attribute-table .. [#] 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/tree/neutron/objects/rbac_db.py?h=stable/ocata#n291
.. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/utils.py?h=stable/ocata .. [#] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/utils.py?h=stable/ocata

View File

@ -296,7 +296,7 @@ References
---------- ----------
.. [#] `Oslo policy module <http://git.openstack.org/cgit/openstack/oslo.policy/>`_ .. [#] `Oslo policy module <http://git.openstack.org/cgit/openstack/oslo.policy/>`_
.. [#] `Oslo policy developer <documentation: http://docs.openstack.org/developer/oslo.policy/>`_ .. [#] `Oslo policy developer <https://docs.openstack.org/oslo.policy/latest/>`_
.. [#] API controller item_ method .. [#] 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://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/base.py?id=2015.1.1#n282

View File

@ -196,4 +196,4 @@ More Info
--------- ---------
For more information, see the oslo.messaging documentation: For more information, see the oslo.messaging documentation:
http://docs.openstack.org/developer/oslo.messaging/. https://docs.openstack.org/oslo.messaging/latest/.

View File

@ -27,7 +27,7 @@ Neutron Messaging Callback System
================================= =================================
Neutron already has a `callback system Neutron already has a `callback system
<https://docs.openstack.org/developer/neutron-lib/devref/callbacks.html>`_ <https://docs.openstack.org/neutron-lib/latest/contributor/callbacks.html>`_
for in-process resource callbacks where publishers and subscribers are for in-process resource callbacks where publishers and subscribers are
able to publish and subscribe for resource events. able to publish and subscribe for resource events.

View File

@ -27,9 +27,11 @@ repository is only meant for specs from Neutron itself, and the advanced
services repositories as well. This includes FWaaS, LBaaS, and VPNaaS. Other services repositories as well. This includes FWaaS, LBaaS, and VPNaaS. Other
sub-projects are encouraged to fold their specs into their own devref code sub-projects are encouraged to fold their specs into their own devref code
in their sub-project gerrit repositories. Please see additional comments in their sub-project gerrit repositories. Please see additional comments
in the Neutron teams `section <http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#neutron-specs-core-reviewer-team>`_ in the Neutron teams :ref:`section <specs-core-reviewer-team>`
for reviewer requirements of the neutron-specs repository. for reviewer requirements of the neutron-specs repository.
.. _request-for-feature-enhancement:
Neutron Request for Feature Enhancements Neutron Request for Feature Enhancements
---------------------------------------- ----------------------------------------
@ -261,10 +263,9 @@ Documentation
The above process involves two places where any given feature can start to be The above process involves two places where any given feature can start to be
documented - namely in the RFE bug, and in the spec - and in addition to those documented - namely in the RFE bug, and in the spec - and in addition to those
Neutron has a substantial `developer reference guide Neutron has a substantial :doc:`developer reference guide </contributor/index>`
<http://docs.openstack.org/developer/neutron/devref/index.html>`_ (aka (aka 'devref'), and user-facing docs such as
'devref'), and user-facing docs such as the `networking guide the :doc:`networking guide </admin/index>`. So it might be asked:
<http://docs.openstack.org/networking-guide/>`_. So it might be asked:
* What is the relationship between all of those? * What is the relationship between all of those?

View File

@ -137,8 +137,8 @@ It's also worth adding that some of these projects are part of the so
called Neutron `stadium <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_. called Neutron `stadium <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
Because of that, their release is managed centrally by the Neutron Because of that, their release is managed centrally by the Neutron
release team; requests for releases need to be funnelled and screened release team; requests for releases need to be funnelled and screened
properly before they can happen. Release request process is described `here properly before they can happen. Release request process is described
<http://docs.openstack.org/developer/neutron/stadium/guidelines.html#releases>`_. :ref:`here <guideline-releases>`.
.. _guidelines: .. _guidelines:
@ -263,7 +263,7 @@ If the bug report is sound, move next:
* Depending on ease of reproduction (or if the issue can be spotted in the * Depending on ease of reproduction (or if the issue can be spotted in the
code), mark it as 'Confirmed'. If you are unable to assess/triage the code), mark it as 'Confirmed'. If you are unable to assess/triage the
issue because you do not have access to a repro environment, consider issue because you do not have access to a repro environment, consider
reaching out the `Lieutenant <http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy>`_, reaching out the :ref:`Lieutenant <core-review-hierarchy>`,
go-to person for the affected component; go-to person for the affected component;
he/she may be able to help: assign the bug to him/her for further he/she may be able to help: assign the bug to him/her for further
screening. If the bug already has an assignee, check that a patch is screening. If the bug already has an assignee, check that a patch is
@ -348,7 +348,7 @@ Proposing New Tags
New tags, or changes in the meaning of existing tags (or deletion), are to be New tags, or changes in the meaning of existing tags (or deletion), are to be
proposed via patch to this section. After discussion, and approval, a member of proposed via patch to this section. After discussion, and approval, a member of
the bug team will create/delete the tag in Launchpad. Each tag covers an area the bug team will create/delete the tag in Launchpad. Each tag covers an area
with an identified go-to contact or `Lieutenant <http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy>`_, with an identified go-to contact or :ref:`Lieutenant <core-review-hierarchy>`,
who can provide further insight. Bug queries are provided below for convenience, who can provide further insight. Bug queries are provided below for convenience,
more will be added over time if needed. more will be added over time if needed.

View File

@ -59,6 +59,8 @@ In addition to that, the following rules are to follow:
that would help interested parties to identify their platform limitation that would help interested parties to identify their platform limitation
in timely manner. in timely manner.
.. _spec-review-practices:
Neutron Spec Review Practices Neutron Spec Review Practices
----------------------------- -----------------------------
In addition to code reviews, Neutron also maintains a BP specification git repository. Detailed In addition to code reviews, Neutron also maintains a BP specification git repository. Detailed

View File

@ -42,6 +42,8 @@ error causing job failures end up here. It should be duty of the diligent Neutro
classification rate for neutron jobs is as close as possible to 100%. To this aim, the diligent Neutron classification rate for neutron jobs is as close as possible to 100%. To this aim, the diligent Neutron
developer should adopt the procedure outlined in the following sections. developer should adopt the procedure outlined in the following sections.
.. _troubleshooting-tempest-jobs:
Troubleshooting Tempest jobs Troubleshooting Tempest jobs
---------------------------- ----------------------------
1. Open logs for failed jobs and look for logs/testr_results.html.gz. 1. Open logs for failed jobs and look for logs/testr_results.html.gz.
@ -52,7 +54,7 @@ Troubleshooting Tempest jobs
logstash. logstash.
4. On logstash, search for occurrences of this error message, and try to identify the root cause for the failure 4. On logstash, search for occurrences of this error message, and try to identify the root cause for the failure
(see below). (see below).
5. File a bug for this failure, and push an `Elastic Recheck Query <http://docs.openstack.org/developer/neutron/policies/gate-failure-triage.html#filing-an-elastic-recheck-query>`_ for it. 5. File a bug for this failure, and push an :ref:`Elastic Recheck Query <elastic-recheck-query>` for it.
6. If you are confident with the area of this bug, and you have time, assign it to yourself; otherwise look for an 6. If you are confident with the area of this bug, and you have time, assign it to yourself; otherwise look for an
assignee or talk to the Neutron's bug czar to find an assignee. assignee or talk to the Neutron's bug czar to find an assignee.
@ -68,12 +70,14 @@ Troubleshooting functional/fullstack job
forget to put a snippet of the trace into the new launchpad bug. If the forget to put a snippet of the trace into the new launchpad bug. If the
log file for a particular job doesn't contain any trace, pick the one log file for a particular job doesn't contain any trace, pick the one
from testr_results.html.gz. from testr_results.html.gz.
5. Create an `Elastic Recheck Query <http://docs.openstack.org/developer/neutron/policies/gate-failure-triage.html#filing-an-elastic-recheck-query>`_ 5. Create an :ref:`Elastic Recheck Query <elastic-recheck-query>`
Root Causing a Gate Failure Root Causing a Gate Failure
--------------------------- ---------------------------
Time-based identification, i.e. find the naughty patch by log scavenging. Time-based identification, i.e. find the naughty patch by log scavenging.
.. _elastic-recheck-query:
Filing An Elastic Recheck Query Filing An Elastic Recheck Query
------------------------------- -------------------------------
The `elastic recheck <http://status.openstack.org/elastic-recheck/>`_ page has all the current open ER queries. The `elastic recheck <http://status.openstack.org/elastic-recheck/>`_ page has all the current open ER queries.

View File

@ -22,5 +22,5 @@ For example, do not just put an empty "recheck" comment but find the related
bug number and put a "recheck bug ######" comment instead. If a bug does not bug number and put a "recheck bug ######" comment instead. If a bug does not
exist yet, create one so other team members can have a look. It helps us exist yet, create one so other team members can have a look. It helps us
maintain better visibility of gate failures. You can find how to troubleshoot maintain better visibility of gate failures. You can find how to troubleshoot
gate failures in the `Gate Failure Triage <http://docs.openstack.org/developer/neutron/policies/gate-failure-triage.html#troubleshooting-tempest-job>`_ gate failures in the :ref:`Gate Failure Triage <troubleshooting-tempest-jobs>`
documentation. documentation.

View File

@ -29,6 +29,8 @@ In essence, core reviewers share the following common ideals:
A core reviewer's responsibility doesn't end up with merging code. The above A core reviewer's responsibility doesn't end up with merging code. The above
lists are adding context around these responsibilities. lists are adding context around these responsibilities.
.. _core-review-hierarchy:
Core Review Hierarchy Core Review Hierarchy
--------------------- ---------------------
@ -191,6 +193,8 @@ they choose to use them. However, by choosing to be a part of the Neutron
project, they submit to oversight and veto by the Neutron PTL if any issues project, they submit to oversight and veto by the Neutron PTL if any issues
arise. arise.
.. _specs-core-reviewer-team:
Neutron Specs Core Reviewer Team Neutron Specs Core Reviewer Team
-------------------------------- --------------------------------
Neutron `specs core reviewers <https://review.openstack.org/#/admin/groups/314,members>`_ Neutron `specs core reviewers <https://review.openstack.org/#/admin/groups/314,members>`_
@ -220,7 +224,7 @@ the group of people who have full rights to the specs repo. This team, which mat
instituted to ensure a consistent architectural vision for the Neutron project, and instituted to ensure a consistent architectural vision for the Neutron project, and
to continue to disaggregate and share the responsibilities of the Neutron PTL. to continue to disaggregate and share the responsibilities of the Neutron PTL.
The team is in charge of reviewing and commenting on The team is in charge of reviewing and commenting on
`RFEs <http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements>`_, :ref:`RFEs <request-for-feature-enhancement>`,
and working with specification contributors to provide guidance on the process and working with specification contributors to provide guidance on the process
that govern contributions to the Neutron project as a whole. The team that govern contributions to the Neutron project as a whole. The team
`meets regularly <https://wiki.openstack.org/wiki/Meetings/NeutronDrivers>`_ `meets regularly <https://wiki.openstack.org/wiki/Meetings/NeutronDrivers>`_

View File

@ -78,8 +78,8 @@ team. Some of these practices are typically already followed by the most
mature OpenStack projects: mature OpenStack projects:
* Exhaustive documentation: it is expected that each project will have a * Exhaustive documentation: it is expected that each project will have a
`developer <http://docs.openstack.org/developer/neutron/>`_, :doc:`developer </contributor/index>`,
`user/operator <http://docs.openstack.org/mitaka/networking-guide/>`_ :doc:`user/operator </admin/index>`
and `API <http://developer.openstack.org/api-ref/networking/>`_ and `API <http://developer.openstack.org/api-ref/networking/>`_
documentations available. documentations available.
@ -99,14 +99,14 @@ mature OpenStack projects:
More Database related information can be found on: More Database related information can be found on:
* http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html * :doc:`/contributor/alembic_migrations`
* http://docs.openstack.org/developer/neutron/devref/db_layer.html * :doc:`/contributor/internals/db_layer`
Bear in mind that many projects have been transitioning their codebase and Bear in mind that many projects have been transitioning their codebase and
tests to fully support Python 3+, and it is important that each Stadium tests to fully support Python 3+, and it is important that each Stadium
project supports Python 3+ the same way Neutron core does. For more project supports Python 3+ the same way Neutron core does. For more
information on how to do testing, please refer to the information on how to do testing, please refer to the
`Neutron testing documentation <http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron>`_. :doc:`Neutron testing documentation </contributor/testing/testing>`.
* Good release footprint, according to the chosen `release model <http://governance.openstack.org/reference/tags/#release-management-tags>`_. * Good release footprint, according to the chosen `release model <http://governance.openstack.org/reference/tags/#release-management-tags>`_.
@ -117,7 +117,7 @@ mature OpenStack projects:
where applicable. This means having grenade support on top of the CI where applicable. This means having grenade support on top of the CI
coverage as described above. coverage as described above.
* Client bindings and CLI developed according to the OpenStack Client `plugin model <http://docs.openstack.org/developer/python-openstackclient/plugins.html>`_. * Client bindings and CLI developed according to the OpenStack Client `plugin model <https://docs.openstack.org/python-openstackclient/latest/plugins.html>`_.
On top of the above mentioned criteria, the following also are taken into On top of the above mentioned criteria, the following also are taken into
consideration: consideration:
@ -140,6 +140,8 @@ consideration:
interface to support multiple backend technologies, and/or adopt the interface to support multiple backend technologies, and/or adopt the
flavor framework as necessary. flavor framework as necessary.
.. _add-remove-projects-to-stadium:
Adding or removing projects to the Stadium Adding or removing projects to the Stadium
------------------------------------------ ------------------------------------------
@ -171,7 +173,8 @@ provides an informal checklist that shows what steps a project needs to
go through in order to enable the PTL and the TC to vote positively on go through in order to enable the PTL and the TC to vote positively on
the proposed inclusion. the proposed inclusion.
Once a project is included, it abides by the Neutron `RFE submission process <http://docs.openstack.org/developer/neutron/policies/blueprints.html>`_, Once a project is included, it abides by the Neutron
:doc:`RFE submission process </contributor/policies/blueprints>`,
where specifications to neutron-specs are required for major API as well where specifications to neutron-specs are required for major API as well
as major architectural changes that may require core Neutron platform as major architectural changes that may require core Neutron platform
enhancements. enhancements.
@ -180,10 +183,10 @@ Checklist
--------- ---------
* How to integrate documentation into docs.o.o: The documentation * How to integrate documentation into docs.o.o: The documentation
website has a section for `project developer documentation <http://docs.openstack.org/developer/openstack-projects.html>`_. website has a section for `project developer documentation <https://docs.openstack.org/openstack-projects.html>`_.
Each project in the Neutron Stadium must have an entry under the Each project in the Neutron Stadium must have an entry under the
'Networking Sub Projects' section that points to the developer 'Networking Sub Projects' section that points to the developer
documentation for the project, available at http://docs.openstack.org/developer/<your-project>/. documentation for the project, available at ``https://docs.openstack.org/<your-project>/latest/``.
This is a two step process that involves the following: This is a two step process that involves the following:
* Build the artefacts: this can be done by following example * Build the artefacts: this can be done by following example
@ -260,7 +263,7 @@ Checklist
* https://review.openstack.org/#/c/243085/ * https://review.openstack.org/#/c/243085/
For release documentation related to Neutron, please check the For release documentation related to Neutron, please check the
`Neutron policies document <http://docs.openstack.org/developer/neutron/#neutron-policies>`_. :doc:`/contributor/policies/index`.
Once, everything is set up and your project is released, make sure Once, everything is set up and your project is released, make sure
you see an entry on the release page (e.g. `Ocata <http://releases.openstack.org/ocata/index.html#other-projects>`_. you see an entry on the release page (e.g. `Ocata <http://releases.openstack.org/ocata/index.html#other-projects>`_.
Make sure you release according to the project declared release Make sure you release according to the project declared release
@ -280,8 +283,8 @@ Checklist
More information on how to develop python-openstackclient plugins More information on how to develop python-openstackclient plugins
can be found on the following links: can be found on the following links:
* http://docs.openstack.org/developer/python-openstackclient/plugins.html * https://docs.openstack.org/python-openstackclient/latest/contributor/plugins.html
* http://docs.openstack.org/developer/python-openstackclient/humaninterfaceguide.html * https://docs.openstack.org/python-openstackclient/latest/contributor/humaninterfaceguide.html
It is worth prefixing the commands being added with the keyword 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.openstack.org/#/c/340624/10/setup.cfg>`_ to

View File

@ -122,6 +122,8 @@ following the stable branch policies as defined by on the `Stable Branch wiki
means that, among other things, no features are allowed to be backported into means that, among other things, no features are allowed to be backported into
stable branches. stable branches.
.. _guideline-releases:
Releases Releases
-------- --------

View File

@ -34,14 +34,12 @@ What does the test do?
This test compares models with the result of existing migrations. It is based on This test compares models with the result of existing migrations. It is based on
`ModelsMigrationsSync `ModelsMigrationsSync
<http://docs.openstack.org/developer/oslo.db/api/oslo_db.sqlalchemy.test_migrations.html>`_ <https://docs.openstack.org/oslo.db/latest/reference/api/oslo_db.sqlalchemy.test_migrations.html>`_
which is provided by oslo.db and was adapted for Neutron. It compares core which is provided by oslo.db and was adapted for Neutron. It compares core
Neutron models and vendor specific models with migrations from Neutron core and Neutron models and vendor specific models with migrations from Neutron core and
migrations from the driver/plugin repo. This test is functional - it runs against migrations from the driver/plugin repo. This test is functional - it runs against
MySQL and PostgreSQL dialects. The detailed description of this test can be MySQL and PostgreSQL dialects. The detailed description of this test can be
found in Neutron Database Layer section - `Tests to verify that database found in Neutron Database Layer section - :ref:`testing-database-migrations`.
migrations and models are in sync
<http://docs.openstack.org/developer/neutron/devref/db_layer.html#module-neutron.tests.functional.db.test_migrations>`_.
Steps for implementing the test Steps for implementing the test
------------------------------- -------------------------------

View File

@ -40,7 +40,7 @@ def safe_creation(context, create_fn, delete_fn, create_bindings,
More information when this method could be used can be found in More information when this method could be used can be found in
developer guide - Effective Neutron: Database interaction section. developer guide - Effective Neutron: Database interaction section.
http://docs.openstack.org/developer/neutron/devref/effective_neutron.html https://docs.openstack.org/neutron/latest/contributor/effective_neutron.html
:param context: context :param context: context

View File

@ -1,4 +1,4 @@
See doc/source/devref/alembic_migrations.rst See doc/source/contributor/alembic_migrations.rst
Rendered at Rendered at
http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html https://docs.openstack.org/neutron/latest/contributor/alembic_migrations.html

View File

@ -24,7 +24,7 @@ depends_on = ('89ab9a816d70',)
# therefore the following column addition ( which should have been in an # therefore the following column addition ( which should have been in an
# expand phase ) is also submitted in the contract phase. For information # expand phase ) is also submitted in the contract phase. For information
# about the expand and contract scripts and how the depends_on works, please # about the expand and contract scripts and how the depends_on works, please
# refer <http://docs.openstack.org/developer/neutron/devref/ # refer <https://docs.openstack.org/neutron/latest/contributor/
# alembic_migrations.html#expand-and-contract-scripts> # alembic_migrations.html#expand-and-contract-scripts>
from alembic import op from alembic import op

View File

@ -8,7 +8,7 @@ features:
named 'trunk' must be added to the option ``service_plugins`` in your named 'trunk' must be added to the option ``service_plugins`` in your
neutron.conf. The plugin exposes two new extensions ``trunk`` and neutron.conf. The plugin exposes two new extensions ``trunk`` and
``trunk_details``. The plugin can work with multiple backends and in ``trunk_details``. The plugin can work with multiple backends and in
particular Neutron has support for `ML2/openvswitch <http://docs.openstack.org/developer/neutron/devref/openvswitch_agent.html#tackling-the-network-trunking-use-case>`_ particular Neutron has support for `ML2/openvswitch <https://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_agent.html#tackling-the-network-trunking-use-case>`_
and ML2/linuxbridge. and ML2/linuxbridge.
Even though Neutron API compatibility should be preserved for ports Even though Neutron API compatibility should be preserved for ports
associated to trunks, since this is the first release where the feature associated to trunks, since this is the first release where the feature

View File

@ -7,4 +7,4 @@ OpenStack projects. Background on the process, tooling, and
methodology is documented in a `mailing list post by Doug Hellmann <http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html>`_. methodology is documented in a `mailing list post by Doug Hellmann <http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html>`_.
For information on how to create release notes, please consult the For information on how to create release notes, please consult the
`Release Notes documentation <http://docs.openstack.org/developer/reno/>`_. `Release Notes documentation <https://docs.openstack.org/reno/latest/>`_.

View File

@ -5,7 +5,7 @@ description-file =
README.rst README.rst
author = OpenStack author = OpenStack
author-email = openstack-dev@lists.openstack.org author-email = openstack-dev@lists.openstack.org
home-page = http://docs.openstack.org/developer/neutron/ home-page = https://docs.openstack.org/neutron/latest/
classifier = classifier =
Environment :: OpenStack Environment :: OpenStack
Intended Audience :: Information Technology Intended Audience :: Information Technology