Hello, those interested in vmdebootstrap. I have some news of changes
I'm planning.
I'm at the minidebconf in Cambridge, and spent much of yexterdays's
sprint time looking at the code and test code in vmdebootstrap. Things
are not good and it's my fault.
* I want to have an automated test suite that gives me confidence that
if tests pass, I can make a release. The current test suite is
purely yarns, and slow. The full suite takes half an hour to run,
and though there is a subset that runs fast (seconds), it has
insufficient coverage for me to have sufficient confidence. Speed of
the test suite is also important, though less so than confidence. A
slow test suite basically prevents productivity. For high confidence
I want a good unit test suite as well. Unit tests can easily test
very specific things, and are easy to keep fast.
* The current code is not easily unit testable. Which means it needs
to be refactored as I add unit test. Which can only be done safely
if there is already a test suite one has confidence in. Also,
writing unit tests afterwards is awful work.
* The main code path is quite hard to understand. It is also in need
to allow more variation. For example, partitioning is very
simplistic right now, and should be improved. The way vmdb has been
developed/extended so far has been to add options and then
complicate the main code path to handle variations more or less in
line. This is unsustainable, since the result is hard to understand,
difficult to maintain, and fairly fragile. Worse, it would be good
for users to be able to vary the main code path so they can produce
the kinds of images they need.
* I reject the design of adding hooks with callback, and plugins that
can add callback, to increase flexibility to users. It'd result in
another type of complexity where one needs to understand a
non-linear code base where some things happen here and some there
and it's not possible to see here when something happens there. It'd
be similar to event driven programming with callbacks.
* I also reject the idea of having users writing plugins in Python to
achieve what they need.
* My plan: I'll add a domain specific language to replace the main
code path. I'll have vmdb read a YAML file and executes steps listed
therein. The step implementations are provided by vmdb, or perhaps
plugins. Steps may be parameterised. This should give a lot of
flexibility to users without increasing complexity.
I'll use YAML so I don't need to write a parser. Parameter values
will be run throught jinja2, with variables the are set via vmdb
command line options, of by steps that get executed.
* The YAML might look somethin like this:
- step: create_raw_file
size: {{ size }}
filename: {{ image }}
- step: create_partition_table
partition_table_type: msdos
- step: create_partition
size: {{ bootsize }}
partition_type: ext2
bootable: yes
mount_point: /boot
- step: create_partition
size: rest
partition_type: ext4
mount_point: /
- step: mount_all
- step: debootstrap
- step: install_grub
- step: run_customization_script
script: {{ customize }}
- step: cleanup
- step: convert_image_to_output_format
output_format: qcow2
The "step:" key specifies the step to execute. The other keys are
parameters for the step. The {{...}} parts are where Jinja2 is used
to expand variable values.
* I can't promise when anything works.
* I will try hard to keep the vmdb command line interface backwards
compatible.
--
I want to build worthwhile things that might last. --joeyh
Attachment:
signature.asc
Description: PGP signature