Running the functional tests is time consuming. This patch adds the
option `-j <job count>` to the tests/run_functests.sh: when given the
test run in parallel up the <job count> jobs.
When using this, be sure to have enough resources (CPUs, RAM and HD
space) on the host.
In addition there was the need to change two things:
o Global /tmp/dib-test-should-fail was move to temporary build
directory of each execution.
o Because the logs might now interleave, each log line has now a
prefix of the name of the testcase.
[In my environment running functests sequential takes 15+ minutes,
running them parallel takes less than 6 minutes.]
Change-Id: Id9ea5131f0026c292ca6453ba2c80fe12c47f808
Signed-off-by: Andreas Florath <andreas@florath.net>
As motivation for this; we have had two breakouts of dib in recent
memory. One was a failure to unmount through symlinks in the core
code (I335316019ef948758392b03e91f9869102a472b9) and the other was
removing host keys on the build-system
(Ib01d71ff9415a0ae04d963f6e380aab9ac2260ce).
For the most part, dib runs unprivileged. Bits of the core code are
hopefully well tested (modulo bugs like the first one!). We give free
reign inside the chroot (although there is still some potential there
for adverse external affects via bind mounts). Where we could be a
bit safer (and could have prevented at least the second of these
breakouts) is with some better checking that the "sudo" calls
*outside* the chroot at least looked sane.
This adds a basic check that we're using chroot or image paths when
calling sudo in those parts of elements that run *outside* the chroot.
Various files are updated to accomodate this check; mostly by just
ignoring it for existing code (I have not audited these calls).
Nobody is pretending this type of checking makes dib magically safe,
or removes the issues with it needing to do things as root during the
build. But this can help find egregious errors like the key removal.
Change-Id: I161a5aea1d29dcdc7236f70d372c53246ec73749
Prior to this, no user documentation of dib-lint existed, which
meant users had to read the dib-lint code itself to figure out
how it worked. This changes adds documentation on using dib-lint
and the checks it currently supports.
Change-Id: I285c5cc680dd9fbd9bd3f667ef102be14e248114
Add documentation to our developer guide about not creating executables
before or after 10/90 in the upstream element's phase directories.
Change-Id: I93ab70f37da0d81f8683a76fd3b341b761ea04e9
This cuts the image size down alot, esspecially if there were lots of
small file deletes.
The fstrim utility is in the util-linux package and should be on
most all systems. fstrim also works with XFS, ext4, btrfs, etc
prodiving the kernel is new enough.
A reduction of 25% or more in size is common.
Change-Id: I269b4416be450369616f9b8e030f84c30e329804
In the common case of not specifying a size, we are already running
"du" over the image to figure out how big it is. Leverage that by
saving it's output and displaying a pruned list of big files when
requested.
We add a flag to show a summarised option (files >10MiB) and another
to show full output, should you wish that level of detail.
"Invocation" documentation is updated (and formatted a little better
while we're here).
Change-Id: I255800790a62fed1c82fcd311f1cc29c9867766d
The quickstart should be the first bit of developer documentation, not
the last. Also add in a short blurb for the developer docs so we dont
have two doc titles back to back.
Change-Id: Icb5683b8eb22e759fefb1cb2252ed445dea5f7dd
This simplifies and enhances the functional-test runner script for
much better interactive behaviour and to give us the ability to better
choose what is running in CI.
Firstly, I have split the image-output testing into a separate script.
This is not actually part of the functional testing of elements and is
both logically and functionally different. It currently does not run
in upstream CI because we don't have docker in the images. I have
nothing against it, but it can be it's own thing.
run_functests.sh is overhauled to have a useful interactive interface,
e.g.
---
$ ./run_functests.sh -h
run_functests.sh [-h] [-l] <test> <test> ...
-h : show this help
-l : list available tests
<test> : functional test to run
Special test 'all' will run all tests
$ ./run_functests.sh -l
The available functional tests are:
apt-sources/test-sources
debian/build-succeeds
fedora/build-succeeds
fedora/build-succeeds-f21
ironic-agent/build-succeeds-fedora
---
As described there, you can run a single test, a number of tests, the
default tests (as CI will do) or all tests. Running all tests is too
much for regular CI, but currently the only way to stop a low priority
test running, or temporarily pause is to remove it completely --
clearly sub-optimal (see I93c2990472e88ab3e5ff14db56b4ff1b4dd965ef).
There is nothing complicated about this, and to further simplify I
have merged the runner functions back into run_functests.sh which
remains a very modest ~150 lines, with most of that being argument
sanity. With that and the image-format cleanup, we can remove the
indirection of the 3 small library files.
For consistency, I have renamed the "dib_functions_test" (that tests
things from the dib functions library) with a run_* prefix.
Because the default list is the same as the current functional tests
run, this does not modify the status-quo. I plan to modify this,
however, to run fedora-minimal & centos-minimal tests in a future
change, as these are required to be stable for openstack ci.
Documentation is updated, and a README.rst is added in the tests
directory for discoverability.
Change-Id: I86d208bd34ff09a29fdb916a4e7ef740c7f65af8
Install-types are a user facing feature, not just for developers. Lets
move the docs on them in to the user guide.
Change-Id: I6ee8f657c270cf90da9c0729494740bb23aa47c5
Now 'tox -efunc' can be invoked to run all functional tests in
the 'venv' tox environment. Also `tox -efunc element-name` can be
used to run function tests for one element (e.g. ironic-agent).
Change-Id: Ia685d1b2a7deef2f8b98876ac09792134dd30f2f
Use inline code syntax for env variables.
Link to elements README files.
Point 'redhat' to 'redhat-common' instead.
Change-Id: Ied1150aaa631c7c6d7f2f55314f9aa3529fd4ba0
Augment the developing_elements.rst by taking advantage of Sphinx
markup. Most of the doc used to be in /README.md and thus did not
leverage on Sphinx.
Use inline codeblock to denote variables, files, command: ``foo``
Phase Subdirectories:
List phase names in the preliminary introduction
Get rid of lists in favor of definitions
Highlight whether the phase runs in or outside the chroot
Input parameters are now lists
Use definition lists in Dependencies and Ramdisk sections.
Link to elements README when they exist.
Testing Element: split into two subsections: 'shell' and 'python'.
Use "sourcecode:: sh" for the couple examples at the very top and very
bottom of the document.
Change-Id: I2421f76ec452cac243ccb2208f88c7d320ffedd3
As described in the comments, inspect the installation to see if we
have been installed with "pip -e" and, if so, make sure we reference
the scripts from the source location rather than the
system-installations.
Update the documentation with a terse but helpful quick-start to show
an easy way to start developing a change using this.
Closes-Bug: #1491035
Change-Id: I0460061b834a2b854175f8c9be2be8d38c540c9d
The README.rst has a lot of information that has been duplicated in the
Sphinx maintained documentation (3600330).
Remove dupes from README.rst
Point to http://docs.openstack.org/developer/diskimage-builder/
Change summary:
=====================+======================================
README.md | Sphinx document
section |
=====================+======================================
Installation | installation.rst
---------------------+--------------------------------------
Invocation | invocation.rst
---------------------+--------------------------------------
Requirements | installation.rst Speedups
---------------------+--------------------------------------
Caches/offline | caches.rst + changes from 849e9cb2
| fix some markup
---------------------+--------------------------------------
Install Types | install_types.rst
---------------------+--------------------------------------
Writing an element | developing_elements.rst + fe7823a2
| `Testing element` from b9b6640f
| `3rd party elements' from f1e7bf3a
---------------------+--------------------------------------
Existing elements | elements.rst
---------------------+--------------------------------------
What tools are there | components.rst
---------------------+--------------------------------------
Design | design.rst
---------------------+--------------------------------------
Change-Id: I578daa8e3a8d876b3ee3c9a748d7c8aa2bf7a0b7
jenkin => jenkins
on ci.md
documention => documentation
on developer/caches.html
typicallly => typically
on developer/developing_elements.html
Closes-Bug: #1476993
Change-Id: Ie40205debad5dbc6074e65672e0f3ebeaee5b08e
Having data files in the phase subdirs is an easy source of confusion
in reviews (especially when the data file is a script) and theres really
no reason to be putting data files there at this point. Lets make a
convention out of not doing this.
Change-Id: I99571a2a49e14e8c709af20f6d13d662ac745eb4
Adding a test function which allows us to use elements to perform
element-specific tests. In order for this to work sanely, also adding
some configuration to our break system so we can assert on negative
tests.
Also adding a test for apt-sources to verify this code actually works.
Change-Id: I378a74255010eca192f5766b653f8a42404be5ea
Add a small documentation paragraph about the operating system elements,
what they are required to provide (and thus what other elements can rely
on).
This makes DISTRO_NAME a prime-class variable, which can now be assumed
to always exists (it was de-facto required so far).
Change-Id: Iffbc69de0516b58bfde48e87cd73073428d66b05
Set the pbr option 'warnerrors' to make build_sphinx turns warnings into
error. Fix all warnings.
`tox -edocs` will thus abort whenever someone introduce a new error.
Change-Id: Id6d09768a241866e1fdc1a1e2bf90336f5c5087d
Our docs are very developer focused. Lets create a separate user guide
to help new users get started.
Change-Id: I8a03920e6d3306dd0405177875ea55ccb4b40fea
