You can use many different OS images with MAAS
Errors or typos? Topics missing? Hard to read? Let us know!
MAAS provides supported images for stable Ubuntu releases, and for CentOS 7 and CentOS 8.0 releases. Other images can be customised for use with MAAS.
MAAS images are more than just the operating system kernel. In fact, a usable MAAS image consists of at least four things:
- a bootloader^, which boots the computer to the point that an operating system can be loaded. MAAS currently uses one of three types of bootloaders: open firmware, PXE, and UEFI.
- a bootable kernel.
- an initial ramdisk.
- a squashfs filesystem.
If you were to look at the
squashfs.manifest, you’d see something like this:
This snippet gives you a basic idea of the kinds of things that have to be loaded onto a drive in order for the system to function independently.
Here’s a conceptual view of the way that images get deployed to create a running MAAS machine:
This is a good place to explain how images work, including the nuances of
curtin configurations. Let’s take it from the top.
Before a machine can be deployed, it must be added to MAAS, commissioned, and allocated. Machines can be added to MAAS either by enlistment or by direct user action. This machine must then be commissioned, which establishes the configuration and resources of the machine. Finally, that machine must be allocated, that is, assigned to the control of one and only one user, so that conflicting commands to the same machine are not possible. This aggregate step is represented by the green lines in the above diagram.
When MAAS receives the “deploy” command from the user (blue lines), it must first retrieve (from the MAAS DB) the machine info that was gathered about the machine during commissioning (red lines). MAAS then boots the machine and waits for the machine’s firmware to request a bootable “ephemeral” OS. This ephemeral OS must be one of the images supplied by the MAAS simplestreams^ and cannot be a custom OS image.
At the point that MAAS must send the ephemeral OS to the machine, MAAS needs to have this OS downloaded to the rack controller, based on earlier selections made by the user (yellow lines). Assuming that the a suitable simplestreams image is available, MAAS can send it to the machine. This ephemeral OS is not deployed, but it is used to download and deploy the image you’ve chosen for the machine.
When the ephemeral OS boots, it immediately spawns curtin^. Curtin’s deployment of the target image can be customised with pre-seeds, shown by the brown lines in the diagram. These pre-seeds control things which are difficult to change once the target OS has been installed (such as partitioning^. Things which can be customized after the target image is running are generally configured with cloud-init^, represented by the pink lines.
To continue with the deployment flow, curtin retrieves the target image, either from the rack controller’s cache (if the image is standard) or from the MAAS DB (if the image is custom). Curtin then installs the target image and reboots the machine. When the target image boots, it retrieves cloud-init configuration either from the MAAS metadata server (proxied by the region controller), or from cloud-init configuration data packed with the target image – whichever is “closer”.
Once cloud-init has finished, the machine is deployed, that is, up and running, ready to perform whatever functions have been assigned to it.
The flowchart above is a bit complicated, but there are few key takeaways you should remember:
Machines have to be added, either by enlistment or direct user action, before they can be deployed.
Machines must be commissioned before deployment, so that MAAS knows what resources the machine has available.
Machines must be allocated before deployment, to lock out all other users (so that no command deadlock can occur).
You must have selected and downloaded at least one suitable image from the MAAS simplestreams before you can deploy a machine, because this simplestreams image is used to boot the machine from the network, so that the target OS can then be installed on the machine.
If you need to customize things about the machine that can’t be changed after the target OS is installed (like partitioning drives), you must use curtin pre-seeds to do this. You must specify these pre-seeds before you start deployment.
If you want to customize things about the machine that can be changed after the target OS is installed (like downloading and installing an application), you must use cloud-init to do this. You must specify this cloud-init configuration, at the very least, before deployment begins.
If you wish to deploy a custom image, you must pack it and upload it to MAAS before deployment begins.
A region controller downloads its images from a boot source. The main characteristics of a boot source are location (URL) and an associated GPG public keyring.
A boot resource is another name for an image. So boot resources are found within a boot source.
MAAS stores images in the region controller’s database, from where the rack controller proxies them to the individual machines. It’s important to note that for ESXi images, network configuration includes only these five parameters:
- Static/auto IP assignments
Bonds are mapped to NIC teaming in only three ways:
- balance-rr – portid
- active-backup – explicit
- 802.3ad – iphash, LACP rate and XMIT hash policy settings ignored
MAAS comes configured with a boot source that should suffice for most users:
The above URL points to the ‘stable’ stream (for the v3 format). See Local image mirror for some explanation regarding the availability of other streams.
Although the backend supports multiple boot sources, MAAS itself uses a single source. If multiple sources are detected, the web UI will print a warning and will be unable to manage images.
Last updated 11 days ago.