Open Stack

On 9 January 2013 22:02, Gary Kotton <gkotton at redhat.com> wrote:
>
>
> This is certainly something can be optimized. One idea would be to cache
> ports instead of deleting them and reuse them. This would save interactions
> with the Quantum service.

I've been looking into this some more, and I think we may need some
(very minor) work there.

This is being driven from the nova compute side - inside nova the
hypervisor driver (baremetal) is the thing that knows that a
particular MAC is needed.

However, that driver isn't meant to talk to the network_api for a few
reasons, so its limited to reporting to the compute manager (this is
in run_instance btw) that it has some constraints. It *could* report a
port UUID and perhaps a a network UUID, but that leads to a problem in
the future.

Today, few folk have openflow switches, so in the absence of a vendor
specific plugin, the baremetal networking is non-virtual: you can do
DHCP but you can't change the L2 domain, the VLAN trunk/non-trunk mode
and the VLANs present on the physical switch port.

If we teach the baremetal hypervisor about network UUIDs, then we'll
end up modelling the entire VLAN infrastructure etc within it. But
we'll also have to model that in Quantum - as provider networks.

And then, when folk with switch vendor plugins or openflow switches
start using the baremetal hypervisor, baremetal passing network UUIDs
around would be a misfeature: it would constrain things that don't
need to be constrained.

Likewise port UUIDs: the only reason a port UUID is relevant is
because *without* vendor switch plugins or openflow switches, we need
to guarantee a mapping to a particular network that is defined
independently of the tenant.

Instead, it seems less likely to hit those problems if:
 - baremetal only stores MAC addresses, and in
nova/network/quantumv2/api.py's 'allocate_for_instances' we query
Quantum for ports (searching by MAC which AFAICT isn't supported yet?)
 - for non-virtualised L2 baremetal networks:
   - adding baremetal nodes involves adding the port to quantum, done
by an administrator
   - (and using provider networks to configure them correctly)
   - those ports are not deleted when the instance
 - for virtualised L2 baremetal networks (openflow/vendor switch plugin):
   - the port creation can be done as you suggested, just-in-time
using the MAC and the desired Quantum network.
   - those ports would be deleted when the instance is

What do you think?

>From this the work-set for honouring the MAC constraint would be (if I
am right):
 - add a lookup-by-MAC facility to Quantum
 - update quantumclient (is that needed, or is it dynamic?)
 - change nova to use that API, creatings ports just-in-time for
non-found ports.

-Rob

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