51a7169904
This puts into place a tox.ini for running unit tests without a large amount of deps installed into the system. For example, we did not want to need libnl-route-3-dev or build-essential installed in the system in order to run unit tests. In order avoid import errors in the modules due to these missing dependencies, we have added a 'fake_deps/' directory that provides mock'd objects of the dependencies that were used. The only installed packages necessary for this to run should be tox itself and its dependencies (pip and friends). From a clean new container we can then do: apt-get install tox git clone ... tox Also along the way: * adjust setup.py to only need the DistUtilsExtra during 'build'. This means tox usage doesn't require python3-distutils-extra. * drop use of lsb_release in favor of built-in parsing. This python module wasn't doing much. We can parse /etc/lsb-release ourselves with less footprint. Also part of the motivation for this is that lsb_release was not on pypi. * replace use of StorageInfo in test_partition.py with a FakeStorageInfo * .gitignore: ignore only the top level 'probert' directory so that we can track fake_deps/probert. * fix a couple escape chars, by using raw strings (r''). * adjust gettext to return un-modified strings rather than '_(string)', but support old style if FAKE_TRANSLATE=mangle. |
||
---|---|---|
bin | ||
console_conf | ||
debian | ||
examples | ||
fake_deps | ||
po | ||
scripts | ||
subiquity | ||
subiquitycore | ||
tests | ||
.gitignore | ||
.gitmodules | ||
.travis.yml | ||
LICENSE | ||
Makefile | ||
README.md | ||
kbdnames.txt | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
snapcraft.yaml | ||
tox.ini |
README.md
subiquity & console-conf
Ubuntu Server Installer & Snappy first boot experience
The repository contains the source for the new server installer (the "subiquity" part, aka "ubiquity for servers") and for the snappy first boot experience (the "console-conf" part).
We track bugs in Launchpad at https://bugs.launchpad.net/subiquity. Snappy first boot issues can also be discussed in the forum at https://forum.snapcraft.io.
Acquire subiquity from source
git clone https://github.com/CanonicalLtd/subiquity
cd subiquity && make install_deps
Testing out the installer Text-UI (TUI)
SUbiquity's text UI is is available for testing without actually installing anything to a system or a VM. Subiquity developers make use of this for rapid development. After checking out subiquity you can start it:
make dryrun
All of the features are present in dry-run mode. The installer will emit its backend configuration files to /tmp/subiquity-config-* but it won't attempt to run any installer commands (which would fail without root privileges). Further, subiquity can load other machine profiles in case you want to test out the installer without having access to the machine. A few sample machine profiles are available in the repository at ./examples/ and can be loaded via the MACHINE make variable:
make dryrun MACHINE=examples/mwhudson.json
Generating machine profiles
Machine profiles are generated from the probert tool. To collect a machine profile:
PYTHONPATH=probert ./probert/bin/probert --all > mymachine.json
Testing changes in KVM
To try out your changes for real, it is necessary to install them into an ISO. Rather than building one from scratch, it's much easier to install your version of subiquity into the daily image. Here's how to do this:
-
Build your change into a snap:
$ snapcraft snap --output subiquity_test.snap
-
Grab the current version of the installer:
$ urlbase=http://cdimage.ubuntu.com/ubuntu-server/daily-live/current $ isoname=$(distro-info -d)-live-server-$(dpkg --print-architecture).iso $ zsync ${urlbase}/${isoname}.zsync
-
Run the provided script to make a copy of the downloaded installer that has your version of subiquity:
$ sudo ./scripts/inject-subiquity-snap.sh ${isoname} subiquity_test.snap custom.iso
-
Boot the new iso in KVM:
$ qemu-img create -f raw target.img 10G $ kvm -m 1024 -boot d -cdrom custom.iso -hda target.img -serial stdio
-
Finally, boot the installed image:
$ kvm -m 1024 -hda target.img -serial stdio
The first three steps are bundled into the script ./scripts/test-this-branch.sh.