[openstack-dev] [ironic] reducing tftp usage and separating boot control from dhcp config
Devananda van der Veen
devananda.vdv at gmail.com
Thu May 9 15:57:23 UTC 2013
On Thu, May 9, 2013 at 6:39 AM, Jarrod B Johnson <jbjohnso at us.ibm.com>wrote:
> Hello, wanted to measure the relative interest in two related efforts I
> could work on. In general, I'm considering bringing over much of the
> capability of xCAT's deployment facility over to Ironic, but wanted to
> highlight a couple to start with.
>
> -An openstack tailored proxydhcp server. This would mean the boot control
> aspect would be cleanly split from network identity control. This would
> allow the bootstrap program to be more adaptive to UEFI and BIOS style
> boot. Given the limitations of python, I'd probably implement this as a
> moderately standalone C program (e.g. the ability to get at IP_PKTINFO
> afaict isn't cleanly possible until python 3.3). I can only be confident
> with x86, ARM I think would work with some different logic, POWER would not
> work.
> -If a system does a PXE request, then send down a second stage bootloader.
> Then that bootloader would download third stage bootloader
> (pxelinux.0/elilo/grub2/efibootmgfw.efi/pxeboot.n12/esxboot.c32/esxboot.efi)
> and would provide/download kernel/initrd/wim/multboot modules over https or
> http. This would be iPXE based (perhaps the xNBA branch that I established
> for xCAT). A patched esxboot would also be relevant. On EFI Linux, elilo
> could work with patch (as it does for xCAT), but I might see about grub2
> depending on whether it will do something with Simple filesystem or not.
> The impetus for not elilo would be figuring out the most straightforward
> path to target-side initrd concatenation. I presume there is a desire to
> ultimately not have many copies of the same initrd data, but I plan to also
> take advantage of initrd injection for other features. I can do server
> side injection into initrds, but it would mean unique initrds per target.
>
Hi Jarod,
I've also got some questions about the reasoning behind this.
* why create a new proxydhcp service? Can you be specific about what is
lacking in the existing implementations (eg. quantum and dnsmasq), and why
they can't be improved?
* we definitely need ARM support, and I have heard some reports that it
works today. I haven't had anyone specifically say "we need PPC" but I
wouldn't be surprised that someone out there wants it. Only supporting x86
is not an option.
Regards,
-Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/a8e8197c/attachment.html>
More information about the OpenStack-dev
mailing list