Open Stack

> I wanted to raise another design failure of why creating the port on
> nova-compute is bad. Previously, we have encountered this bug
> (https://bugs.launchpad.net/neutron/+bug/1160442). What was causing the
> issue was that when nova-compute calls into quantum to create the port;
> quantum creates the port but fails to return the port to nova and instead
> timesout. When this happens the instance is scheduled to be run on another
> compute node where another port is created with the same device_id and when
> the instance boots it will look like it has two ports. This is still a
> problem that can occur today in our current implementation (!).

Well, the issue there would seem to be that we've merged the
functionality of 'create' (and 'update') and 'plug', where we make an
attachment to the network.  If we 'create'd a port without attaching
it, and then attached it from the compute driver, it would be obvious
when the second compute driver came along that we had an eventual
consistency problem that needed resolving.  We should indeed be
'create'ing the port from the API and then using a different 'plug'
call from the compute host, I think.

On the more general discussion:

I'm going to play my usual card  - if I want a mapped PCI device,
rather than a vswitch device, to be used, then I need to tell Neutron
that's what I'm thinking, and the obvious place to do that is from the
compute node where I'm creating the VM and know what specific PCI
device I've allocated.  Doing it from the Nova API server makes a lot
less sense - I shouldn't know the PCI bus ID on the API server for
anything more than debugging purposes, that's a compute-local choice.

[I'm also not convinced that the current model - where I choose a VF
to map in, then tell the Neutron server which tells the agent back on
the compute node which configures the PF of the card to encapsulate
the VF I've mapped, makes any sense.  I'm not entirely sure it makes
sense for OVS, either.  But that's a whole other thing.]
-- 
Ian.