[openstack-dev] [quantum] RFC: quantum baremetal config/work to do

Robert Collins robertc at robertcollins.net
Sun Jan 6 19:42:21 UTC 2013


Hey, so I've been poking at quantum with the baremetal hypervisor on
classic l2 switches - no openflow.

Here is what I think needs to be done to make it all work, and what I
think 'it' is :)

So the goal is to have a regular L2 network, with quantum + baremetal
nova managing dhcp on it.

Ignoring quantum for the moment, what needs to happen is that:
 - machines attempt PXE booting using their own MAC address
 - if the machine is not known to nova, something sensible (e.g.
allocate from a pool, or log and ditch, or allocate a number and do
hardware discovery)
 - if the machine is known to nova, boot it providing appropriate
bootfile-name, server-ip-address and tftp-server options.
 - nova's baremetal hypervisor then handles tftp and the rest of the
boot process.

What I have so far is this:
 - quantum with the ovs plugin
 - with a provider network configured (e.g.
tenant_network_type=none
network_vlan_ranges=ctlplane
bridge_mappings=ctlplane:br-ctlplane

and a network and subnet made with that:
$ quantum net-create ctlplane --tenant-id $tenantuuid
--provider:network_type flat --provider:physical_network ctlplane

$ subnet-create --ip-version 4 --allocation-pool
start=192.0.2.34,end=192.0.2.38 --gateway=192.0.2.33 $netuuid
192.0.2.32/29

Will answer DHCP for DHCP requests coming from the physical L2 network
if the MAC has been registered as a port.

My plan for unknown machines for now is to ignore them (can just have
a deliberately slow DHCP server running on the same network, as a
stopgap), but long term would like to teach quantum a fallback
configuration for unknown requests. [which might be to proxy-DHCP the
request].

For machines known to nova, there can be many baremetal hypervisor
machines. One (and only one) will have the right files to PXE boot the
machine that is starting up. [same as for virtualised instances, there
is one owning hypervisor, at least for now]. So we need to set
server-ip-address/tftp-server at least semi-dynamically.  I propose to
handle this by defining a separate pxe boot set of options for each
hypervisor ((in reload_allocations()), and use host set:<tag> rules to
map each baremetal host back to the correct hypervisor.

nova doesn't currently VIF plug correctly - we end up with dynamic MAC
addresses, which messes this up - I'm tackling that now, but wanted a
sanity check on the rest of the stuff.

Comments please!

-Rob
-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services



More information about the OpenStack-dev mailing list