<html><body>
<p><tt><font size="2">Devananda van der Veen <devananda.vdv@gmail.com> wrote on 05/09/2013 11:57:23 AM:<br>
<br>
> <br>
> Hi Jarod,</font></tt><br>
<tt><font size="2">> <br>
> I've also got some questions about the reasoning behind this.</font></tt><br>
<tt><font size="2">> <br>
> * why create a new proxydhcp service? Can you be specific about what<br>
> is lacking in the existing implementations (eg. quantum and <br>
> dnsmasq), and why they can't be improved?</font></tt><br>
<br>
<tt><font size="2">Well, it comes largely out of some complications we've had in xCAT and something I was hoping to take the opportunity to avoid in Openstack. xCAT is currently largely locked into a solution of using ISC DHCP with a stub proxydhcp server for Windows UEFI(dnsmasq isn't quite capable enough for everything we require). We have had some environments that were not necessarily prepared for us to control both the networking identity and boot control, and accommodating those has been more special than I'd like. Even if not worrying about those potential users as undesired, I thought it might be cleaner if the in-target deployment didn't make any particularly specific mandates about the content of DHCPOFFERs intended for network identity management (or even to function absent of a DHCPOFFER at all, depending on how other concepts go). Also bootmgfw.efi requires that configuration be delivered via ProxyDHCP answer rather than a DHCP answer (it just entirely ignores the structures that DHCPOFFER fills in). Finally, it's not a lot of work to do (basically it could hard bake esxi/xen/linux/windows boot schemes in uefi/bios contexts with netbot/localboot modes). It would probably use a YAML or JSON config file and reread on inotify detected activity. Config file would specify relevant DUID and MAC keys and what node they map to and whether it should do network or local boot scheme (the esxi/xen/linux/windows behavior would be driven by script content rather than data in the payload, uefi/bios selection would be autodetected at deployment target boot time).</font></tt><br>
<br>
<tt><font size="2">> <br>
> * we definitely need ARM support, and I have heard some reports that<br>
> it works today. I haven't had anyone specifically say "we need PPC" <br>
> but I wouldn't be surprised that someone out there wants it. Only <br>
> supporting x86 is not an option.</font></tt><br>
<br>
<tt><font size="2">These of course would be usable in a scheme that is processor agnostic. If ARM doesn't have an iPXE work-alike, then all that has to happen is for the ARM architecture to be detected and told to skip the iPXE phase and tolerate the tftp penalty and proceed to the ARM specific loader. It's roughly analagous to how the proposal already handles UEFI and BIOS which are in effect totally different architectures from the perspective to something like ironic. xCAT already affords PPC the same concession, bootp/tftp only until the OS actually starts running and it wasn't particularly onerous to do.</font></tt><br>
<br>
<tt><font size="2">> <br>
> Regards,</font></tt><br>
<tt><font size="2">> -Devananda</font></tt><br>
<tt><font size="2">> <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></body></html>