[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