← Back to team overview

maas-devel team mailing list archive

Re: Dynamic TFTP server

 

On 2012-06-28 00:04, Gavin Panella wrote:
I've worked a bit on a dynamic TFTP server. You can see my progress in
lp:~allenap/maas/dynamic-tftp. This can field a TFTP request and
dynamically render a PXE configuration file, falling back to the
filesystem for non-matching paths. It's only rendering a stub right
now, but next I'll hook it up to the existing PXEConfig stuff. I think
that'll be quite easy.

Thanks for doing this. I'd be quite interested to know how well the base implementation that you used holds up under stress — barring any problems there, doing this now does look simpler than continuing to manage the PXE downloads purely through the filesystem.


As we discussed, and you asked me to explain here in more detail, there is a loosely related issue of the static files (pre-bootloader, kernel, initrd) and how to keep them consistent. A booting node ought to receive an initrd that matches its kernel, and since the TFTP server keeps no sessions, neither of those files should be replaced while being downloaded.

We can't stop nodes from booting at inopportune times, so I think we'll have to go with a versioning scheme — maintain multiple versions of these files, so nodes that are booting from older versions can continue using those even when newer versions become available during the boot. We'd garbage-collect versions that are no longer needed.

With a dynamic TFTP server we have two ways to do versioning: explicit or transparent.

* “Explicit”: keep a version number visible somewhere in its TFTP path. So for instance, you could direct a node to load kernel /maas/amd64/precise/install-123/linux.

* “Transparent”: hide the version numbers from the TFTP paths, but remember that a node is booting off a particular version and transparently serve it that version. The path would still be like /maas/amd64/precise/install/linux as it is today.

I think the explicit approach is probably best, because it naturally keeps the choice of version as node-side state. On the flip side, it will complicate our TFTP path handling a bit, and we'll have to keep track of the current version somewhere.


Jeroen


Follow ups

References