Open Stack

Ian Wells <ijw.ubuntu at cack.org.uk> writes:

> 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.

Many thanks for your explanations; I think I'm understanding this more
fully now.  For example, I now see that, when using libvirt, Nova has to
generate config that describes all aspects of the VM to launch,
including how the VNIC is implemented and how it's bound to networking
on the host.  Also different hypervisors, or layers like libvirt, may go
to different lengths as regards how far they connect the VNIC to some
form of networking on the host, and I can see that Nova would want to
normalize that, i.e. to ensure that a predictable level of connectivity
has always been achieved, regardless of hypervisor, by the time that
Nova hands over to someone else such as Neutron.

Therefore I see now that Nova _must_ be involved to some extent in VIF
plugging, and hence that VIF_TYPE_NOOP doesn't fly.

For a minimal, generic implementation of an unbridged TAP interface,
then, we're back to VIF_TYPE_TAP as I've proposed in
https://review.openstack.org/#/c/130732/.  I've just revised and
reuploaded this, based on the insight provided by this ML thread, and
hope people will take a look.

Many thanks,
     Neil