The commit replaces DefCore committee (a former name) by
Interop Working Group (the current name) and updates a few
more old interop references.
Change-Id: I578a21d610b5b680b4549bf34e1857307a1b8e74
Also update some outdated URLs at the same time, e.g. defcore is now
interop.
Unfortunately unlike GitHub, gitea doesn't yet support URLs with
shortened SHA1s; however this is being worked on:
https://github.com/go-gitea/gitea/issues/6450
Change-Id: I6e6b63619f1138cc961b61be548453361d01f73c
During development of a new git commit, locally running a whole unit
or functional test suite to check every minor code change is
prohibitively expensive. For maximum developer productivity and
happiness, it's generally desirable to make the feedback loop of the
traditional red/green cycle as quick as possible.
So add run-tests-for-diff.sh and run-tests.py to the tools/
subdirectory, using a few tricks as explained below to help with this.
run-tests.py takes a list of files on STDIN, filters the list for
tests which can be run in the current tox virtualenv, and then runs
them with the correct stestr options.
run-tests-for-diff.sh is a simple wrapper around run-tests.py which
determines which tests to run using output from "git diff". This
allows running only the test files changed/added in the working tree:
tools/run-tests-for-diff.sh
or by a single commit:
tools/run-tests-for-diff.sh mybranch^!
or a range of commits, e.g. a branch containing a whole patch series
for a blueprint:
tools/run-tests-for-diff.sh gerrit/master..bp/my-blueprint
It supports the same "-HEAD" invocation syntax as flake8wrap.sh (as
used by the "fast8" tox environment):
tools/run-tests-for-diff.sh -HEAD
run-tests.py uses two tricks to make test runs as quick as possible:
1. It's (already) possible to speed up running of tests by
source'ing the "activate" file for the desired tox virtualenv,
e.g.
source .tox/py36/bin/activate
and then running stestr directly. This saves a few seconds by
skipping the overhead introduced by running tox.
2. When only one test file needs to be run, specifying the -n option
to stestr will skip the costly test discovery phase, saving
several more valuable seconds.
Future commits could build on top of this work, harnessing a framework
such as watchdog / watchmedo[0] or Guard[1] in order to automatically
run relevant tests every time your editor saves changes to a .py file.
[0] https://github.com/gorakhargosh/watchdog - Python-based
[1] https://guardgem.org - probably best in class, but Ruby-based so
maybe unacceptable for use within Nova.
Change-Id: I9a9bda5d29bbb8d8d77f769cd1abf7c42a18c36b
Cells v1 has been deprecated since Pike. CERN
has been running with cells v2 since Queens.
The cells v1 job used to be the only thing that
ran with nova-network, but we switched the job
to use neutron in Rocky:
I9de6b710baffdffcd1d7ab19897d5776ef27ae7e
The cells v1 job also suffers from intermittent
test failures, like with snapshot tests.
Given the deprecated nature of cells v1 we should
just move it to the experimental queue so that it
can be run on-demand if desired but does not gate
on all nova changes, thus further moving along its
eventual removal.
This change also updates the cells v1 status doc
and adds some documentation about the different
job queues that nova uses for integration testing.
Change-Id: I74985f1946fffd0ae4d38604696d0d4656b6bf4e
Closes-Bug: #1807407
The testing strategy doc was linking to the hacking repo docs
on creating unit tests, which are very specific to creating
unit tests for hacking rules.
This changes the link to the 'creating unit tests' section in
the HACKING.rst file, which has more information on testing
within nova.
Along with that change, the HACKING.rst testing section is
updated a bit to point out that we use stestr now instead of
testr and adds a proper link to the development environment
quickstart docs.
The nova/tests/unit/README.rst actually needs a lot of work,
but that's left for another day.
Change-Id: Ie5106d87d632286162b31ce132e947c306d21abd
Closes-Bug: #1732024
Per the spec [1]:
user/ – end-user content such as concept guides, advice, tutorials,
step-by-step instructions for using the CLI to perform specific tasks,
etc.
The remaining content all ends up in here.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I480eee9cd7568efe2f76dd185004774588eb4a99
Per the spec [1]:
contributor/ – anything related to contributing to the project or how
the team is managed. Applies to some of the current content under
/developer, we are changing the name to emphasize that not all
contributors are developers and sometimes developers are users but not
contributors.
We currently have a handful of docs that focus on the "how to develop or
contribute" aspects of nova, and these are moved. Docs that focus on
architecture or design decisions for nova are not moved, as these will
go into 'reference'.
A TODO is added to the former 'api_plugins' document as it's mega
out-of-date and needs some serious work.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: Iad770688b4eafeb9caa710b4398b02d80a017a70
Martin Kopec