[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

vmdebootstrap plans

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

I want to build worthwhile things that might last. --joeyh

Attachment: signature.asc
Description: PGP signature

Reply to: