Open Stack

On 7 November 2012 18:42, Salvatore Orlando <sorlando at nicira.com> wrote:
> Kyle had a good point concerning PCI passthrough or similar situations. My
> thinking is that in that case you can let the Quantum plugin manage the
> Virtual Functions on the host and then just pass to Nova the one which was
> selected for a given VM.

Precisely.  There's also the more boring case where you dedicate a
whole, unvirtualised NIC by todging the settings of the switch it's
attached to, but it's a simpler case and can be handled in  the same
way.

> The VIF drivers have always bothered me a little. Indeed my perfect world is
> a world without them.
> Just for the sake of precision, they're not really specific to the plugin,
> as several plugins use the same drivers, but they're definitely specific to
> the hypervisor.

They're not *all* specific to a single Quantum plugin, but some are,
and there's many for Quantum that don't work for nova-network (at
that, slightly higher, level of plugin).

>> If we did the above, then the
>> interface to Quantum moves to encompass all of the administration of
>> the networking within the host kernel (for virtual interfaces) and the
>> physical networking (if the interface is a PCI port).
>
> I personally agree with this view. I said in the past that in a host there's
> a compute part, which should be managed by nova, and a network part which
> should be managed by Quantum.

The other thing about this, though whether we can make use of it I'm
not sure, is that for something like router insertion it's another
separate client of L2 Quantum at the same level as Nova.   I know this
is all currently part of the greater Quantum, but if you see it as two
levels - the straightforward L2 plugging and the more exciting L3
features - then we almost have an L2 API here.

>> > Personally, I would let Quantum figure out binding information once the
>> > VIF
>> > is plugged, and keep the VIF plugging API as GET only.
>>
>> I prefer that Quantum is defined as producing an endpoint to which the
>> VM can then be attached.  Otherwise the question in my mind is, what
>> precisely are you passing from Quantum to Nova?
>
>
> I don't know, honestly. Previously in this thread there was an argument that
> Nova should send data to Quantum with a PUT or POST request.
> You're asking the same question I asked, and I could not get a straight
> answer (or an answer I could understand).

I think it's a POST - simply because state is being created in Quantum
(in as much as 'there is now a bridge on this hypervisor' is a form of
state).  You could DELETE to clear the attachment up when you've done
with it.

> One counter argument is that you would make a remote call, with might then
> involve more remote invocations (REST, message queues, or else) for
> something which could be entirely handled by logic on the host. So that's
> something we need to plan carefully.

Implementing the above idea, I imagine we would be make an API call to
Quantum (which is good from a separation perspective) followed by
whatever kind of comms happen between the q-api and the q-agent.  The
issue would that the interaction with the agent would now be
synchronous.

-- 
Ian.