The MaaS package selection creates an Ubuntu Server instance infrastructure that can then (somewhat rapidly) provision a master server to be used (via PxE boot or initial boot-time access to the MaaS server) to provision large quantities of servers. Building the master server is blissfully simple and several different master-type instances can be built, virtualized, and brought into play to distribute multiple servers via DHCP rapidly after the master server "cut" (actually replicable instance).
We chose from Ubuntu Server's initial installation menus to create a MAAS/MaaS server, then chose to create an optional encrypted home directory. We were asked if we wanted to partition the disk and set up optional LVM (Linux Virtual Machine infrastructure) or optional encrypted LVM infrastructure or just do the base setup manually. If you don't need the containers that LVM provides, or have other plans, skip LVM.
We were then given the choice of the encryption seed (with a verification) to use. There is no recovery or decryption without the chosen seed, we found. You can choose insanely long seeds; the longer the seed, the tougher the encryption.
We then set up an HTTP proxy so that we could allow MaaS system controlled access to internal or external network resources. We could then tell the MaaS system how to get updates automatically, manage it externally (or with the Landscape application Canonical prefers), or prevent updates from the Internet or proxy source we'd entered.
Sparse instances could be brought up in as little as a minute, 20 virtualized instances at a time, and we weren't pushing or optimizing. Better times could be achieved with faster CPUs, more optimized (e.g. smaller payload) instances, and by running multiple concurrent MaaS servers.
Initial product loads using MaaS then required a boatload of automated updates, something we find frustrating with Canonical. Each version has an initial load, and then, even on release day, has a truckload of updates needed to bring it current, which all must be downloaded then installed. This means releases aren't really releases, they're just releases of baseline code that mandate (sometimes quite lengthy) updates after initial installations before an actual in-house "cut" or version freeze that was current as of the release date can be made. It's like buying an encyclopedia, but for 1994.
The upside to the MaaS system is that administrators can "version" instances after the initial finger-drumming update exercise, then have a patch-level confidence among the MaaS master server versions. Waltzing around the update step would prove desirable when many virtualized instances must be brought up for non-persistent use, ostensibly with Juju-serviced preconfigured application payloads.