| 2012-08-24 09:46:44 |
Robie Basak |
description |
An outcome of a recent MAAS-related sprint is the conclusion that MAAS needs to be able to operate in an environment where it cannot control the DHCP server.
This means that we cannot rely on the ability to differentiate architectures based on ISC dhcpd.conf conditional statements on vendor-class-identifier setting alternate next-server filenames as we are doing at the moment (see bug 927781 for details of this mechanism).
Instead we need some other way for MAAS to detect the architecture of the booting system in order to send it the correct architecture kernel/initrd.
If this doesn't happen, then MAAS will have to resort to guessing based on MAC addresses supplied by vendors, or the user entering in the information on a per-MAC basis manually, or the user nominating an entire MAAS cluster as homogeneous on a particular architecture. None of these options are ideal.
Instead, I propose the following minor change to U-Boot to enable architecture detection outside of DHCP.
The original (Intel) pxelinux.0 falls back through MAC addresses, IP address and subnets and then to "default". Prior to U-Boot pxelinux emulation, a TFTP server could assume that sending an i386 kernel would always work.
pxelinux emulation on other architectures breaks this assumption. So I propose that all alternative architecture pxelinux emulators (eg. U-Boot) fall back to "default.<arch>-<subarch>" before further falling back to "default" as usual.
<arch> and <subarch> must be defined in a new pxelinux emulator namespace, and MAAS will consequently need to map this namespace to Ubuntu's architecture and kernel flavour names. But to start with, they'll probably match 1-1.
So:
default.arm-highbank
default.arm-armadaxp
default.arm-omap4
For this proposed change to work, we need all vendors to take this up. I think the change would be trivial, but I would appreciate feedback from U-Boot maintainers and vendors before we commit to this direction. |
An outcome of a recent MAAS-related sprint is the conclusion that MAAS needs to be able to operate in an environment where it cannot control the DHCP server.
This means that we cannot rely on the ability to differentiate architectures based on ISC dhcpd.conf conditional statements on vendor-class-identifier setting alternate next-server filenames as we are doing at the moment (see bug 927781 for details of this mechanism).
Instead we need some other way for MAAS to detect the architecture of the booting system in order to send it the correct architecture kernel/initrd.
If this doesn't happen, then MAAS will have to resort to guessing based on MAC addresses supplied by vendors, or the user entering in the information on a per-MAC basis manually, or the user nominating an entire MAAS cluster as homogeneous on a particular architecture. None of these options are ideal.
Instead, I propose the following minor change to U-Boot to enable architecture detection outside of DHCP.
The original (Intel) pxelinux.0 falls back through MAC addresses, IP address and subnets and then to "default". Prior to U-Boot pxelinux emulation, a TFTP server could assume that sending an i386 kernel would always work.
pxelinux emulation on other architectures breaks this assumption. So I propose that all alternative architecture pxelinux emulators (eg. U-Boot) fall back to "default.<arch>-<subarch>" and then "default.<arch>" before further falling back to "default" as usual.
<arch> and <subarch> must be defined in a new pxelinux emulator namespace, and MAAS will consequently need to map this namespace to Ubuntu's architecture and kernel flavour names. But to start with, they'll probably match 1-1.
So:
default.arm-highbank
default.arm-armadaxp
default.arm-omap4
For this proposed change to work, we need all vendors to take this up. I think the change would be trivial, but I would appreciate feedback from U-Boot maintainers and vendors before we commit to this direction. |
|
