Open Stack

On 4 December 2014 at 08:00, Neil Jerram <Neil.Jerram at metaswitch.com> wrote:

> Kevin Benton <blak111 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141204/fe5af78d/attachment.html>