Rework provisioner for increased flexibility #158

New Issue

joshuaboniface · 2022-09-30T18:47:05-04:00

joshuaboniface commented

2022-09-30 18:47:05 -04:00

The current provisioner is based heavily around a specific debootstrap-centric workflow, with OVA support tacked on.

Revamp the provisioner workflow to be more modular, allowing the scripting of the various discrete steps besides install() within the process.

This will allow greater flexibility in the guests that can be installed, e.g. alternate Linux distros, BSDs, etc.

The current provisioner is based heavily around a specific debootstrap-centric workflow, with OVA support tacked on. Revamp the provisioner workflow to be more modular, allowing the scripting of the various discrete steps besides `install()` within the process. This will allow greater flexibility in the guests that can be installed, e.g. alternate Linux distros, BSDs, etc.

joshuaboniface added the

API

improvement

labels 2022-09-30 18:47:05 -04:00

joshuaboniface commented

2022-09-30 22:24:23 -04:00

Initial thoughts:

Instead of just install(), have functions for the 5 the key customizable parts of the install process in the script:

a. Setup (setup(), to ensure dependencies and such are installed)

a. Libvirt definition creation (create())

a. Disk creation, mapping, and mounting (prepare())

a. Installation (install())

a. Cleanup (cleanup())

This will greatly increase flexibility of the process ensuring that nearly every conceivable install process (aside from manual) could be scripted here.
Implement installer scripts as (sub)classes of a larger Provisioner class which can implement several helper functions and other useful bits.
Provide additional security to the system, perhaps using a read-only bind mount inside a chroot before beginning the install.
Craft template, OVA and ISO (#119) scripts to ensure these utilize the script framework rather than being special cases. Work these into the profile system in a cleaner way (OVA and ISO are special csaes of the template case).

Initial thoughts: 1. Instead of just `install()`, have functions for the 5 the key customizable parts of the install process in the script: a. Setup (`setup()`, to ensure dependencies and such are installed) a. Libvirt definition creation (`create()`) a. Disk creation, mapping, and mounting (`prepare()`) a. Installation (`install()`) a. Cleanup (`cleanup()`) This will greatly increase flexibility of the process ensuring that nearly every conceivable install process (aside from manual) could be scripted here. 2. Implement installer scripts as (sub)classes of a larger Provisioner class which can implement several helper functions and other useful bits. 3. Provide additional security to the system, perhaps using a read-only bind mount inside a chroot before beginning the install. 4. Craft template, OVA and ISO (#119) scripts to ensure these utilize the script framework rather than being special cases. Work these into the profile system in a cleaner way (OVA and ISO are special csaes of the template case).

joshuaboniface commented

2022-09-30 22:36:33 -04:00

To proceed cleanly, some work will need to be done to remove the current OVA hackery and cleanly implement both OVA and ISO uploads.

Functionally, ISO and RBD image uploads are identical, the main difference being what the result is mounted as in the final VM (a "temporary" secondary volume vs. the main volume respectively). OVAs require the additional parsing of the OVA to create the system template, but each disk in turn becomes identical to an RBD image upload once completed.

Thus I think it's most sensible to proceed like so:

Remove the current OVA functionality entirely (including the various parts of the profiles and schemas).
Revamp the script system as the new method without any consideration yet for the special cases.
Implement cloned volume types first using the current framework.
Revamp the OVA importer to create something more like cloned volume formats.
Implement ISO as a special case of the cloned volume type.

This should ensure things proceed nicely. No intervening version can occur until this work is done.

To proceed cleanly, some work will need to be done to remove the current OVA hackery and cleanly implement both OVA and ISO uploads. Functionally, ISO and RBD image uploads are identical, the main difference being what the result is mounted as in the final VM (a "temporary" secondary volume vs. the main volume respectively). OVAs require the additional parsing of the OVA to create the system template, but each disk in turn becomes identical to an RBD image upload once completed. Thus I think it's most sensible to proceed like so: 1. Remove the current OVA functionality entirely (including the various parts of the profiles and schemas). 2. Revamp the script system as the new method without any consideration yet for the special cases. 3. Implement cloned volume types first using the current framework. 4. Revamp the OVA importer to create something more like cloned volume formats. 5. Implement ISO as a special case of the cloned volume type. This should ensure things proceed nicely. No intervening version can occur until this work is done.

joshuaboniface commented

2022-09-30 22:39:36 -04:00

Thinking further and reviewing the code, removing OVA support first might not be worth the trouble. OVAs are a bit of a special beast and trying to generalize them did not work originally, so I see no sense in repeating that mistake again.

OVAs can indeed still be a special kind of script; ISO can be added later too using similar special logic.

The main thing to do then is to indeed revamp the provisioner creation ignoring OVAs as much as possible at first, then write the special OVA handler script to work with them.

Thinking further and reviewing the code, removing OVA support first might not be worth the trouble. OVAs are a bit of a special beast and trying to generalize them did not work originally, so I see no sense in repeating that mistake again. OVAs can indeed still be a special kind of script; ISO can be added later too using similar special logic. The main thing to do then is to indeed revamp the provisioner creation ignoring OVAs as much as possible at first, then write the special OVA handler script to work with them.

joshuaboniface commented

2022-10-07 23:23:58 -04:00

This has been implemented.

The provisioner flow has been reworked to externalize most of the heavy lifting into a plugin-like script framework which leverages a 5-function standard class (VMBuilderScript extending VMBuilder) and a chroot with read-only / for execution.
OVA provisioning has been moved to a script which must be added before any OVAs can be imported.
Debootstrap example has been fully reworked into the new format.
New noop and rinse (Rocky/CentOS) examples have been created leveraging the new format and working.

The last remaining items are to implement ISO and template VM build examples. These can be implemented similar to OVAs: the code to upload and manage them is custom, but the actual provisoning task lifting is handled by a script. Though it seems that for both the noop script would work best.

A planned further extension is a (Free)BSD script, though this might be impossible.

This has been implemented. 1. The provisioner flow has been reworked to externalize most of the heavy lifting into a plugin-like script framework which leverages a 5-function standard class (VMBuilderScript extending VMBuilder) and a chroot with read-only `/` for execution. 2. OVA provisioning has been moved to a script which must be added before any OVAs can be imported. 3. Debootstrap example has been fully reworked into the new format. 4. New noop and rinse (Rocky/CentOS) examples have been created leveraging the new format and working. The last remaining items are to implement ISO and template VM build examples. These can be implemented similar to OVAs: the code to upload and manage them is custom, but the actual provisoning task lifting is handled by a script. Though it seems that for both the noop script would work best. A planned further extension is a (Free)BSD script, though this might be impossible.

joshuaboniface closed this issue

2022-10-07 23:23:58 -04:00

joshuaboniface referenced this issue

2022-10-07 23:31:51 -04:00

Support custom default libvirt schemas in provisioner #93

Sign in to join this conversation.