Open Stack

Devananda van der Veen <devananda.vdv at gmail.com> wrote on 05/09/2013
11:57:23 AM:

>
> 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?

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).

>
> * 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.

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.

>
> Regards,
> -Devananda
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/fed01b1f/attachment.html>