<html><body>
<p><tt><font size="2">Jay Pipes <jaypipes@gmail.com> wrote on 05/09/2013 11:13:25 AM:<br>
<br>
> From: Jay Pipes <jaypipes@gmail.com></font></tt><br>
<tt><font size="2">> To: openstack-dev@lists.openstack.org</font></tt><br>
<tt><font size="2">> Date: 05/09/2013 11:56 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] [ironic] reducing tftp usage and <br>
> separating boot control from dhcp config</font></tt><br>
<tt><font size="2">> <br>
> On 05/09/2013 09:39 AM, Jarrod B Johnson wrote:<br>
> > Hello, wanted to measure the relative interest in two related efforts I<br>
> > could work on. In general, I'm considering bringing over much of the<br>
> > capability of xCAT's deployment facility over to Ironic, but wanted to<br>
> > highlight a couple to start with.<br>
> > <br>
> > -An openstack tailored proxydhcp server. This would mean the boot<br>
> > control aspect would be cleanly split from network identity control.<br>
> > This would allow the bootstrap program to be more adaptive to UEFI and<br>
> > BIOS style boot. Given the limitations of python, I'd probably<br>
> > implement this as a moderately standalone C program (e.g. the ability to<br>
> > get at IP_PKTINFO afaict isn't cleanly possible until python 3.3). I<br>
> > can only be confident with x86, ARM I think would work with some<br>
> > different logic, POWER would not work.<br>
> > -If a system does a PXE request, then send down a second stage<br>
> > bootloader. Then that bootloader would download third stage bootloader<br>
> > (pxelinux.0/elilo/grub2/efibootmgfw.efi/pxeboot.n12/esxboot.c32/esxboot.efi)<br>
> > and would provide/download kernel/initrd/wim/multboot modules over https<br>
> > or http. This would be iPXE based (perhaps the xNBA branch that I<br>
> > established for xCAT). A patched esxboot would also be relevant. On<br>
> > EFI Linux, elilo could work with patch (as it does for xCAT), but I<br>
> > might see about grub2 depending on whether it will do something with<br>
> > Simple filesystem or not. The impetus for not elilo would be figuring<br>
> > out the most straightforward path to target-side initrd concatenation.<br>
> > I presume there is a desire to ultimately not have many copies of the<br>
> > same initrd data, but I plan to also take advantage of initrd injection<br>
> > for other features. I can do server side injection into initrds, but it<br>
> > would mean unique initrds per target.<br>
> <br>
> Hi Jarrod, I have a few starter questions for you.<br>
> <br>
> 1) What benefit would xCAT bring to OpenStack deployments that do not<br>
> use IBM hardware?<br>
> <br>
> 2) How is xCAT different from IPMI + Cobbler/PXE/tftp?<br>
> <br>
> 3) Given that neither the above proposed solutions is Python-based, what<br>
> plans are you thinking about for how to make the eventual solution<br>
> packagable and installation via the methods that most folks use for<br>
> deployment (Chef/Puppet/etc)<br>
> <br>
> Thanks!<br>
> -jay<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> </font></tt><br>
<br>
<tt><font size="2">1) xCAT works fine with generic IPMI/PXE systems. I have even put in workarounds for spec deviations by Supermicro that never had relevance to IBM equipment. The hardware control does present additional capability when it hits IBM hardware (e.g. LED status, remote video, firmware inventory), but the remote os boot has nearly zero affinity for our hardware as it stands (bog standard PXE, with the one exceedingly trivial exception of the ability to specify client IQN in an IBM way in addition to the standardi). Some other things I am considering (like ISO IPL payload delivery) might require vendor-specific backends, but these ideas don't.</font></tt><br>
<br>
<tt><font size="2">2) Perhaps I should have broached the xCAT general topic separate of these specific ideas. However to briefly distinguish, we have driver injection and os deployment and imaging for redhat, suse, ubuntu, windows, and esxi platforms. Our IPMI implementation can hit 4,000 servers in less than 10 seconds using a single process with a single filehandle. tftp is of course used in PXE flows, but to the extent possible immediately we jump to http for transfer of even kernel and initrd. For now this at least means a higher performance protocol to improve scalability and boot time. It also paves the way (in conjunction with other concepts) for end to end verified https transport of material that strongly suggests integrity assurance and privacy. However, all of this isn't critical for openstack's as the plan would be reimplementation of capability, not a direct injection of code (since xCAT is mostly perl) and as such each piece can be evaluated for its own merits as it goes rather than its relation to xCAT</font></tt><br>
<br>
<tt><font size="2">3) I must confess to not having my sea legs yet with respect to openstack (have looked at code, but haven't even so much as installed it yet) and thus am not yet certain of the best suggested approach to packaging logisticts. However, the proxydhcp solution would be roughly analagous to dnsmasq/dhcpd in terms of being C utility leveraged by broader openstack. The iPXE payload would be similarly analagous to pxelinux.0.<br>
</font></tt></body></html>