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