docs: Fix indent level
Leading spaces before item lists leads to vertical line on the left side. They are completely unnecessary. Change-Id: I08c3f077e470aa593076a525de1445bc5d0bdb9a
This commit is contained in:
Akihiro Motoki
parent
a23cd43abe
commit
eee9d2ca80
16
TESTING.rst
16
TESTING.rst
|
|
@ -50,14 +50,14 @@ We will talk about three classes of tests: unit, functional and integration.
|
|||
Each respective category typically targets a larger scope of code. Other than
|
||||
that broad categorization, here are a few more characteristic:
|
||||
|
||||
* Unit tests - Should be able to run on your laptop, directly following a
|
||||
* Unit tests - Should be able to run on your laptop, directly following a
|
||||
'git clone' of the project. The underlying system must not be mutated,
|
||||
mocks can be used to achieve this. A unit test typically targets a function
|
||||
or class.
|
||||
* Functional tests - Run against a pre-configured environment
|
||||
* Functional tests - Run against a pre-configured environment
|
||||
(tools/configure_for_func_testing.sh). Typically test a component
|
||||
such as an agent using no mocks.
|
||||
* Integration tests - Run against a running cloud, often target the API level,
|
||||
* Integration tests - Run against a running cloud, often target the API level,
|
||||
but also 'scenarios' or 'user stories'. You may find such tests under
|
||||
tests/tempest/api, tests/tempest/scenario, tests/fullstack, and in the
|
||||
Tempest and Rally projects.
|
||||
|
|
@ -469,9 +469,7 @@ the tracking of long-running tests and other things.
|
|||
|
||||
For more information on the standard Tox-based test infrastructure used by
|
||||
OpenStack and how to do some common test/debugging procedures with Testr,
|
||||
see this wiki page:
|
||||
|
||||
https://wiki.openstack.org/wiki/Testr
|
||||
see this wiki page: https://wiki.openstack.org/wiki/Testr
|
||||
|
||||
.. _Testr: https://wiki.openstack.org/wiki/Testr
|
||||
.. _tox: http://tox.readthedocs.org/en/latest/
|
||||
|
|
@ -593,9 +591,9 @@ doc/source/devref/testing_coverage.rst. You could also rely on Zuul
|
|||
logs, that are generated post-merge (not every project builds coverage
|
||||
results). To access them, do the following:
|
||||
|
||||
* Check out the latest `merge commit <https://review.openstack.org/gitweb?p=openstack/neutron.git;a=search;s=Jenkins;st=author>`_
|
||||
* Go to: http://logs.openstack.org/<first-2-digits-of-sha1>/<sha1>/post/neutron-coverage/.
|
||||
* `Spec <https://review.openstack.org/#/c/221494/>`_ is a work in progress to
|
||||
* Check out the latest `merge commit <https://review.openstack.org/gitweb?p=openstack/neutron.git;a=search;s=Jenkins;st=author>`_
|
||||
* Go to: http://logs.openstack.org/<first-2-digits-of-sha1>/<sha1>/post/neutron-coverage/.
|
||||
* `Spec <https://review.openstack.org/#/c/221494/>`_ is a work in progress to
|
||||
provide a better landing page.
|
||||
|
||||
Debugging
|
||||
|
|
|
|||
|
|
@ -77,13 +77,13 @@ 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:
|
||||
|
||||
* 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/>`_,
|
||||
`user/operator <http://docs.openstack.org/mitaka/networking-guide/>`_
|
||||
and `API <http://developer.openstack.org/api-ref/networking/>`_
|
||||
documentations available.
|
||||
|
||||
* Exhaustive OpenStack CI coverage: unit, functional, and tempest coverage
|
||||
* Exhaustive OpenStack CI coverage: unit, functional, and tempest coverage
|
||||
using OpenStack CI (upstream) resources so that `Grafana <http://grafana.openstack.org/dashboard/db/neutron-failure-rate>`_
|
||||
and `OpenStack Health <http://status.openstack.org/openstack-health/#/>`_
|
||||
support is available. Access to CI resources and historical data by the
|
||||
|
|
@ -108,33 +108,33 @@ mature OpenStack projects:
|
|||
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>`_.
|
||||
|
||||
* 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>`_.
|
||||
|
||||
* Adherence to deprecation and `stable backports policies <http://governance.openstack.org/reference/tags/#stable-maintenance-tags>`_.
|
||||
* Adherence to deprecation and `stable backports policies <http://governance.openstack.org/reference/tags/#stable-maintenance-tags>`_.
|
||||
|
||||
* Demonstrated ability to do `upgrades <http://governance.openstack.org/reference/tags/assert_supports-upgrade.html>`_
|
||||
* Demonstrated ability to do `upgrades <http://governance.openstack.org/reference/tags/assert_supports-upgrade.html>`_
|
||||
and/or `rolling upgrades <http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html>`_,
|
||||
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 <http://docs.openstack.org/developer/python-openstackclient/plugins.html>`_.
|
||||
|
||||
On top of the above mentioned criteria, the following also are taken into
|
||||
consideration:
|
||||
|
||||
* A project must use, adopt and implement open software and technologies.
|
||||
* A project must use, adopt and implement open software and technologies.
|
||||
|
||||
* A project must integrate with Neutron via one of the supported, advertised
|
||||
* A project must integrate with Neutron via one of the supported, advertised
|
||||
and maintained public Python APIs. REST API does not qualify (the project
|
||||
python-neutronclient is an exception).
|
||||
|
||||
* It adopts neutron-lib (with related hacking rules applied), and has proof
|
||||
* It adopts neutron-lib (with related hacking rules applied), and has proof
|
||||
of good decoupling from Neutron core internals.
|
||||
|
||||
* It provides an API that adopts API guidelines as set by the Neutron core
|
||||
* It provides an API that adopts API guidelines as set by the Neutron core
|
||||
team, and that relies on an open implementation.
|
||||
|
||||
* It adopts modular interfaces to provide networking services: this means
|
||||
* It adopts modular interfaces to provide networking services: this means
|
||||
that L2/7 services are provided in the form of ML2 mech drivers and
|
||||
service plugins respectively. A service plugin can expose a driver
|
||||
interface to support multiple backend technologies, and/or adopt the
|
||||
|
|
@ -179,7 +179,7 @@ enhancements.
|
|||
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>`_.
|
||||
Each project in the Neutron Stadium must have an entry under the
|
||||
'Networking Sub Projects' section that points to the developer
|
||||
|
|
@ -194,7 +194,7 @@ Checklist
|
|||
More information can also be found on the
|
||||
`project creator guide <http://docs.openstack.org/infra/manual/creators.html#add-link-to-your-developer-documentation>`_.
|
||||
|
||||
* How to integrate into Grafana: Grafana is a great tool that provides
|
||||
* How to integrate into Grafana: Grafana is a great tool that provides
|
||||
the ability to display historical series, like failure rates of
|
||||
OpenStack CI jobs. A few examples that added dashboards over time are:
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ Checklist
|
|||
Any subproject must have a Grafana dashboard that shows failure
|
||||
rates for at least Gate and Check queues.
|
||||
|
||||
* How to integrate into neutron-lib's CI: there are a number of steps
|
||||
* How to integrate into neutron-lib's CI: there are a number of steps
|
||||
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
|
||||
|
|
@ -225,7 +225,7 @@ Checklist
|
|||
#. https://review.openstack.org/#/c/357086/
|
||||
#. https://review.openstack.org/#/c/359143/
|
||||
|
||||
* How to port api-ref over to neutron-lib: to publish the subproject
|
||||
* How to port api-ref over to neutron-lib: to publish the subproject
|
||||
API reference into the `Networking API guide <http://developer.openstack.org/api-ref/networking/>`_
|
||||
you must contribute the API documentation into neutron-lib's api-ref
|
||||
directory as done in the `WADL/REST transition patch <https://review.openstack.org/#/c/327510/>`_.
|
||||
|
|
@ -235,7 +235,7 @@ Checklist
|
|||
for Stadium inclusion, where all the aspects as outlined in this
|
||||
documented are reviewed by the PTL.
|
||||
|
||||
* How to port API definitions over the neutron-lib: the most basic
|
||||
* How to port API definitions over the neutron-lib: the most basic
|
||||
steps to port API definitions over to neutron-lib are demonstrated
|
||||
in the following patches:
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ Checklist
|
|||
on top of the Neutron API backbone. The change can only merge when
|
||||
there is a released version of neutron-lib.
|
||||
|
||||
* How to integrate into the openstack release: every project in the
|
||||
* How to integrate into the openstack release: every project in the
|
||||
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:
|
||||
|
||||
|
|
@ -266,7 +266,7 @@ Checklist
|
|||
Make sure you release according to the project declared release
|
||||
`model <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
|
||||
|
||||
* How to port OpenStack Client over to python-neutronclient: client
|
||||
* How to port OpenStack Client over to python-neutronclient: client
|
||||
API bindings and client command line interface support must be
|
||||
developed in python-neutronclient under `osc module <https://github.com/openstack/python-neutronclient/tree/master/neutronclient/osc/v2>`_.
|
||||
If your project requires one or both, consider looking at the
|
||||
|
|
|
|||
Loading…
Reference in New Issue