One of the most interesting talks I had at cfgmgmtcam was about the future of provisioning in Foreman.
Current state
- Hard to trace and as a consequence hard to debug
- Transactional
- Uses model’s lifecycle hooks to manage external services
- A lot of different paths which contribute to overall complexity of the code
- Need for support new operating systems provisioning methods, like bootable containers
We have talked about ways to change it and generate a clear strategy about the way to continue maintaining the provisioning part in Foreman
We talked about two options that we currently have on the table:
Option 1: Actor-based provisioning
The idea is to divide the provisioning process into multiple actors that each one of them would be responsible for a single aspect of the provisioning: one for DHCP record, one for DNS record, one for compute reource creation e.t.c.
The user will select which actors will be used to provision a selected machine
The actors will consue and contribute data to the model. Each actor will decide what data is needed for it to run and at the end of the run will contribute the new data to the host object.
For example the DHCP actor will consume mac address and contribute an IP address. The DNS actor will consume the IP address and provide an FQDN and so on. The orchestration of the actors can be performed as a single task with multiple parallel steps that will wait for the data to appear on the object.
The end of the process would be defined when no actor can contribute more data.
Advantages
Asynchronous
Traceable (through the checklist of actors)
Uses proper tasks
Provides a clear view of which tasks are going to be executed
A bit more mature
Disadvantages
Does not remove complexity from a single provisioning
Does not reduce the amount of provisioning paths
Option 2: Image oriented provisioning
The idea is to generate a provisioning image on the Foreman side before the provisioning begins using image-generating tools like mkosi. Once the image is generated, Foreman will use a specially-crafted provisioning image (similar to what we have in Discovery) to write the operating system image to the disk. The provisioning image can be booted by any means that are available in the network - PXE, redfish or even a physical USB stick. Of course Foreman will be able to help with the task of distributing the image.
Advantages
Asynchronous
The process of creating the image is outsourced, reducing the support burden form Foreman
The created image is testable and repeatable
No dependency on how to build the image
No dependency on hot to boot the installer
Single way to deploy any operating system
Disadvantages
A revolutional approach
New way to deploy, may require developing a new tool (the provisioning image)
Less mature
Next steps
I would like us to converge to a single path and have a clear strategy as to the direction we want to take with the provisioning. Once we decide on the proper strategy, we can start designing the smaller seps that will get us there eventually.
Thanks to @ekohl, @lstejska, @nofaralfasi, @Jan and @m-bucher for bearing with me on this one!