* 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
@ -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
developer should adopt the procedure outlined in the following sections.
.._troubleshooting-tempest-jobs:
Troubleshooting Tempest jobs
----------------------------
1. Open logs for failed jobs and look for logs/testr_results.html.gz.
@ -52,7 +54,7 @@ Troubleshooting Tempest jobs
logstash.
4. On logstash, search for occurrences of this error message, and try to identify the root cause for the failure
(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
assignee or talk to the Neutron's bug czar to find an assignee.
@ -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
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
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>`
* 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
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
consideration:
@ -140,6 +140,8 @@ consideration:
interface to support multiple backend technologies, and/or adopt the
flavor framework as necessary.
.._add-remove-projects-to-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
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
as major architectural changes that may require core Neutron platform
enhancements.
@ -180,10 +183,10 @@ Checklist
---------
* 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
'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:
* Build the artefacts: this can be done by following example
@ -260,7 +263,7 @@ Checklist
* https://review.openstack.org/#/c/243085/
For release documentation related to Neutron, please check the
named 'trunk' must be added to the option ``service_plugins`` in your
neutron.conf. The plugin exposes two new extensions ``trunk`` and
``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.
Even though Neutron API compatibility should be preserved for ports
associated to trunks, since this is the first release where the feature
Akihiro Motoki
4 years ago