Open Stack

On Nov 7, 2012, at 3:52 AM, Salvatore Orlando <sorlando at nicira.com> wrote:

> Hi,
> 
> I have been following this thread, and I agree with the need of allowing Nova to access information about internals of the Quantum plugin so that it's allowed to plug interfaces using the appropriate driver.
> I think the APIs proposed by Gary are suitable, although the nature of the binding object should be fleshed out a little bit better. Also I think Kyle has a good point that this information should be per-port, not per-network, as in some cases there will be port-specific parameter that needs to be passed into the vif driver. The trade-off here is that instead of 1 call per network there will be 1 call per port. The /port/<port-id>/binding syntax in theory also allows for retrieving logical port and binding info in one call.
> 
> Those APIs can easily be structured as admin-only; however we need to keep in mind that at the moment nova-quantum interaction is performed within the tenant context. We can either change this logic and say that Nova wil always have admin access to Quantum, or that we use an elevated context only for fetching port binding details. To this aim I would think about adding a "service" role to Quantum, which should be used specifically for retrieving binding details.
> 
I think given the fact the end result of this is that something can change with regards to the hosts physical resources, this has to be done with admin privileges. Is there anything wrong with saying Nova always has admin access to Quantum? Failing that, the "service" role for getting these details seems like a nice idea.

> However, I am now reading that there might be use cases in which nova pushes into back into Quantum concerning the way a VIF has been plugged. I am failing at envisioning such use case, and it would be great if you could shed some light on it. I am interested in this because one of Quantum's goals was to provide a clean separation between compute and networking services. It seems that entanglement between the two it's now crawling back. Personally, I would let Quantum figure out binding information once the VIF is plugged, and keep the VIF plugging API as GET only.
> While VIF creation is clearly a task which pertains to the compute service, VIF plugging is arguably borderline, and hence it's more than understandable that there are different valuable approaches and solutions.
> 
The easiest way to think about this is the PCI passthrough case. In that case, the VIF is actually going to be a physical NIC card which is passed directly to the guest. Nova will know the guest is using PCI passthrough, so it needs a way to indicate this to Quantum so Quantum can ensure the network the port is attaching to can handle the PCI passthrough case.

Thanks,
Kyle

> Salvatore
> 
> On 7 November 2012 10:08, Gary Kotton <gkotton at redhat.com> wrote:
> On 11/06/2012 11:58 PM, Ian Wells wrote:
> On 6 November 2012 19:39, Gary Kotton<gkotton at redhat.com>  wrote:
> GET /network-implementation-details/<net-id>
> A minor quibble, but these commands will probably change the state on
> the host that you're getting an attachment for for (or, at least, it
> would the way I would do it - you do the call, and e.g. a bridge pops
> up and Nova knows where to find it by the return of the call).  If
> that's the case, it is a POST rather than a GET as you're creating
> something.
> 
> I need to update the blueprint. The idea in general is to have something like
> 
> GET /port/<id>/binding
> and
> PUT /port/<id>/binding/<something>
> 
> This will enable the information to be passed to Quantum.
> 
> 
> 
> I'm sure you could do it the other way around (GET the details of how
> to connect to the network and then do the work in Nova to make an
> endpoint that the hypervisor could use) but I prefer that the work of
> buggering about with the networking remained entirely within Quantum.
> This seems eminently sensible for PCI passthrough in particular, where
> the call would hand over the details of the card to be attached and
> return that it had been attached - versus bridge creation, where you'd
> probably say 'give me a bridge' and be told the details of the
> arbitrarily named bridge you'd just had created.
> 
> I would hope that the above PUT command enables Nova to provide this information to Quantum.
> 
> Each plugin has its way of allocating and managing the resources. Some may be done via agents, others may be done directly in Nova. It is allo debatible whether this is good or bad. At this stage I would like to provide an API that can ensure that we have our bases covered for the interim period and the long run.
> 
> 
> 
> The options seem to be:
>   - be explicit about which port we're attaching (and, presumably, that
> a port can only be attached once)
>   - implicitly create a port iff you attach to a network, use an
> existing port otherwise
>   - drop ports altogether, or replace them with these attachments that
> we're talking about right now (get a 'realised' attachment point and
> you have effectively added a port to the network, after all).
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev