On Thu, May 10, 2012 at 5:23 AM, Robert Kukura <rkuk...@redhat.com> wrote: > > > Hi Maru, > > I agree a REST interface could do the job. I misinterpreted your email > as arguing that the VIF driver should just create the tap device and the > agent should poll to discover the tap device, as is done now.
> I'm not sure there would be much difference in code complexity using RPC > vs REST, except maybe that, assuming the VIF driver remains in nova, it > would need to use nova's copy of the openstack-common RPC rather than > quantum's copy, and these would need to remain compatible. RPC might > have the advantage of offering async messaging, but I'm not sure that's > needed here. > But it would seem reasonable for the VIF driver in nova to use the same > mechanism that nova itself will be using to talk with quantum (replacing > QuantumManager), which I'd guess is REST. > > I think the general pattern has been that RPC interfaces should be > internal to either the nova or quantum components, and REST interfaces > should be using for communications between different OpenStack > components. In that case, it boils down to whether the VIF drivers are > considered part of nova, where REST should be used, or part of quantum, > where either REST or RPC could be used. > Vif drivers are most certainly part of nova. They are code run by the nova-compute process. Definitely agree that communication between nova + quantum should all be via rest. Its worth noting that Nova already calls Quantum via REST on instance creation to create a new port. This call already passes on information about what host Nova is creating the port on. It might be nice to extend this to include the exact vswitch port id (if available), further optimizing the process, but the big win would be notifying the agent about a new port + attachment, which would eliminate the need for that agent to poll the central DB to learn about new ports. In the re-write of the Nova/Quantum integration, this call will be moving from nova-network (which will no longer exist if Quantum is in use) and instead be performed directly by nova-compute. With that in mind, it probably makes sense to have this code be part of the generic communication between Nova + Quantum, rather than viewing it as part of each vif-driver (which is specific to the exact type of edge switching technology in use). Dan > > -Bob > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
