On 4 December 2014 at 08:00, Neil Jerram <neil.jer...@metaswitch.com> wrote:
> Kevin Benton <blak...@gmail.com> writes: > I was actually floating a slightly more radical option than that: the > idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does > absolutely _nothing_, not even create the TAP device. > Nova always does something, and that something amounts to 'attaches the VM to where it believes the endpoint to be'. Effectively you should view the VIF type as the form that's decided on during negotiation between Neutron and Nova - Neutron says 'I will do this much and you have to take it from there'. (In fact, I would prefer that it was *more* of a negotiation, in the sense that the hypervisor driver had a say to Neutron of what VIF types it supported and preferred, and Neutron could choose from a selection, but I don't think it adds much value at the moment and I didn't want to propose a change just for the sake of it.) I think you're just proposing that the hypervisor driver should do less of the grunt work of connection. Also, libvirt is not the only hypervisor driver and I've found it interesting to nose through the others for background reading, even if you're not using them much. For example, suppose someone came along and wanted to implement a new > OVS-like networking infrastructure? In principle could they do that > without having to enhance the Nova VIF driver code? I think at the > moment they couldn't, but that they would be able to if VIF_TYPE_NOOP > (or possibly VIF_TYPE_TAP) was already in place. In principle I think > it would then be possible for the new implementation to specify > VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind > of configuration and vSwitch plugging that you've described above. > At the moment, the rule is that *if* you create a new type of infrastructure then *at that point* you create your new VIF plugging type to support it - vhostuser being a fine example, having been rejected on the grounds that it was, at the end of Juno, speculative. I'm not sure I particularly like this approach but that's how things are at the moment - largely down to not wanting to add code that isn;t used and therefore tested. None of this is criticism of your proposal, which sounds reasonable; I was just trying to provide a bit of context. -- Ian.
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev