Thanks Dan for your detailed response. My question was indeed based on the understanding that the current nova network managers (in the network service) do perform some L3/DHCP/VPN configurations apart from L2 configuration. As of today's implementation in the network-refactoring-l2 branch, one would need to run the nova-network service configured with either one of Flat/DHCP/VLANManagers even when running Quantum as a separate service, right? If that is the case, how does one correlate an entry in the network table in the nova database, with a network created in Quantum? (I do realize that one could write a different network manager within nova, but my question is more in the context of what is available today.)
I am guessing that the current approach is to use the Flat/DHCP/VLANManger to configure the L3/DHCP/VPN artifacts, and to use Quantum to configure the L2 network (in cases where it's not a Linux bridge). I was not necessarily trying to imply that the nova implementation (as is in the network-refactoring-l2 branch today) interacts (i.e. communicates) with Quantum. My question was more based on the earlier point as to how the nova deployment would co-exist with Quantum (and any other NetStack services), given that nova still maintains certain network related information. (And while on that, nova has the notion of a "user" and one or more "projects" associated with that user; how do these map to the "tenant" in Quantum?) But, I did also want to ask, as to what is the thinking around nova communicating with Quantum (if required). You have rightly pointed out "reporting the interface binding" as one of the cases when this might need to be done. Another case wherein I think this might be relevant is if the VIF driver (within nova virt layer) needs some information about the network from Quantum. There would need to be a communication channel between the VIF driver and Quantum to achieve this. I believe your suggestion is that in any of these cases, the Quantum client library can be used to communicate with the Quantum API (either core or extensions). As for the part on APIs which was not clear in my email, yes I was referring to the "nova-api (i.e. the OpenStack API) will expose interface-ids as an API extension", as you point out. I believe, the extension referred to here is on the nova API side (and not on the Quantum side as my email seemed to suggest), right? Thanks, ~Sumit. From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Sunday, July 24, 2011 10:46 PM To: Sumit Naiksatam (snaiksat) Cc: Ishimoto, Ryu; netstack@lists.launchpad.net Subject: Re: "network-refactoring-l2" branch, and Quantum Hi Sumit, Very good questions. I'll give you my take inline, and Ryu should jump in as well :) Dan On Sun, Jul 24, 2011 at 12:50 PM, Sumit Naiksatam (snaiksat) <snaik...@cisco.com> wrote: Hi Ryu, Dan, and others involved, I had some questions regarding how the code base in the "network-refactoring-l2" branch currently works (or is supposed to) with Quantum. The network-refactoring-l2 branch itself doesn't actually interact with Quantum. It is really just a first step to providing more flexibility within nova for how VM interfaces are created and plugged into a "switch". This will be very helpful for many people using Quantum, as the existing nova code was hard-coded to use the Linux bridge. As I understand, eventually we want to get to a point where one should be able to run the Quantum service instead of the nova-network service. I actually don't think that's necessarily true. The existing nova-network service does many things beyond L2 networking, namely: - IP address management (melange project is targeting providing an improved version of this) - Network Node capabilities, including DHCP, L3 gateway, VPN, metadata server, floating IP forwarding, etc (such functionality may grow to be their own independent services, or an addon to Quantum in the future). - Network orchestration, in the sense that it automatically attaches VIFs to networks based on config (vlan vs. flat manager) and project assignment (donabe aims to become the primary mechanism for this type of orchestration, though some simple behavior equivalent to the existing flat/flatdhcp/vlan models may make sense to stay in nova for a while). There are some obvious next steps for D4: - Ryu will continue the work to merge his work that makes sure that other nova services retrieve network info via the API (not the DB). This is a critical step. - We'll expose interface-ids via the nova API (likely as an extension) - Troy's team will continue integrating the melange code with nova. - We'll probably create an alternate NetworkManager class (and corresponding manager utility) that uses melange for IPAM, quantum for L2 networks, and supports several different orchestration options. However, we are not there yet. Currently one still needs to run the nova-network service in order to be able create the network on the nova side of things. If this understanding is correct, here are few thoughts and questions - (1) How are you reconciling the network created within nova, with that created in Quantum? Current nova networks are a bit tricky, as they represent both L2 networks and IP subnets. A new network manager class + utility will give us the flexibility to handle this however we want. (2) The blueprint for this branch indicates that OpenStack APIs will be implemented as extension APIs in Quantum. Do we have any documentation on this API? (Also, I did not find any implementation in the Quantum trunk, I am guessing we haven't done that yet, right?) I'm not sure I follow what you're saying here. I suspect you are referring to the fact that nova-api (i.e. the OpenStack API) will expose interface-ids as an API extension? Those changes have not gone into nova yet, but are on the list I mentioned above. (3) There was earlier some talk about nova using an "administrative API" to communicate with Quantum. Is that still the plan? In general, what is the thinking around how nova would communicate with Quantum? There are possible uses that I have mentioned for such an admin API: - Reporting "interface bindings" from nova to a quantum plugin. Right now, since the nature of the binding is specific to the nova vif-plugin itself, we're leaving the communication of this binding info up to the plugin itself, so you're free to do whatever you want (your quantum plugin can expose additional APIs if needed). If there is code to share here, we'll probably just do it by sharing a code library (I suspect the new network manager we build will also require the quantum client library, which I would see an a nova dependency if using quantum). - Communicating permission to plug a vif. There have been a couple emails back and forth about this on the list. I am hoping we can use keystone for this, which in case no direct nova/quantum communication is needed. Otherwise, we'll probably create an admin API for this. Thanks, ~Sumit. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
