> 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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
