Open Stack

On 01/06/2013 09:42 PM, Robert Collins wrote:
> 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.

Why have Nova managing the DHCP. Quantum has IPAM and a option of using 
a DHCP agent. The advantage of this is that the DHCP agent will only 
allocate IP addresses for devices that are registered as Quantum ports.

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

The Quantum DHCP agent will only provide IP's for MAC addresses that are 
known to the agent.

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

When you create a Quantum port you are able to specify the MAC address 
of the port. This may require a few tweaks to the Nova code when 
creating the Quantum port. Today you are able to do a nova boot and pass 
the port id a parameter. So if you create the Quantum port outside of 
Nova then you can do this with the existing API's.

> Comments please!
>
> -Rob