Hi Gary, Comments inline, sorry for the slow reply, I'm swamped lately :)
On Wed, May 16, 2012 at 12:37 AM, Gary Kotton <gkot...@redhat.com> wrote: > ** > Hi, > First and foremost sorry for being a bit unclear last night. I am not my > best at 1:55am. Would it be possible to move the meeting a few hours > forwards or backwards? > > Update: > I have a POC running where instead of the agents polling the plugin > database a request is sent from the agent to the plugin to retrieve all of > the relevant network details (this is only done when a tap device has been > added or deleted (same for the gw)). I am still addressing the agent > network configuration (was distracted by a bug and issues with devstack > along the way). The current implementation has the agent polling the hosts > network devices to detect if there is a change. I started with this > following Sumits comments about decoupling the agent and the VIF driver. > > I hope to have a detailed design document ready in a few days - reviewing > will give a better idea and it will also help for documentation in the > future. > > Problem that I tried to mention last night: > The VIF driver creates the tap device for the attachment. This is done by > taking the attachment UUID and using the first 11 bytes, which is the name > of the tap device. > Btw, this actually isn't the case for the OVS plugin. The OVS vif driver in Nova passes the entire attachment UUID to OVS by setting an attribute on the local OVSDB entry for that port (note: the ovsdb is a simple embedded database that runs as part of OVS on the hypervisor... it is completely distinct from the primary database used by the OVS plugin). > The agent detects the new tap device and notifies the plugin which in turn > sends the network details back to the plugin. > The problem that I have with this (and it is a bug in the existing Quantum > code) is that if there is more than one attachment with the same prefix > then the networking will be incorrect (same for the network ID's). > For example: > Network A - 30e46c6c-fd53-4c32-86bb-628423c3083f > Attachment X on A - 04ea2bb8-d2fb-4517-97fc-046fe8eb04c5 > On the host there will be - gw-30e46c6c-fd and tap04ea2bb8-d2 created. > > Network B - *30e46c6c-fd*53-0000-2222-628423c3083f => problems with the > gateway > Attachment Y on B - *04ea2bb8-d2*fb-0000-1111-046fe8eb04c5 > *The host will have to create gw-30e46c6c-fd and tap04ea2bb8-d2 created. * > By my reckoning, each device has 10 random hexidecimal digits, of which there are 16^10 > 1 trillion possible values. Based on your description of how the linux bridge plugin works, those values must be unique across all VIFs and networks in a deployment. Even with tens of thousands of VIFs and networks, we're still looking at a 1 in a million chance of collision (assuming I can do math on a monday morning :P). With the OVS plugin, things are a bit better, as VIFs are already identified by full UUIDs (the device name includes the UUID only for convenience), meaning that you really have only a (# of network / 1 trillion) plus (# VIFs per hypervisor / 1 trillion) chance of a collision. That said, at least with OVS, it would be reasonable to generate random device names, checking for a collision and generating a new name if needed. This is because with OVS the full UUID can be stored as metadata on the port and the use of part of the UUID in the device name was more for ease of debugging than out of necessity. > First and foremost this will fail on the VIF driver with the creation. On > the agent side which is requesting the information - it may receive the > wrong network or attachment information. Should the plugin ensure that the > prefixes of the UUID's are unique until linux enables device names whose > length can solve the problem. > It could do this for networks, though currently the attachment IDs used for VIFs are nova interface ids, not generated by Quantum. > > This is why I think that it is important that the VIF driver notifies the > agent with the actual ID's. > Yes, this is actually what the OVS plugin already does (you'll see that it sets the iface-id attribute to the Nova VIF UUID). With the bridge, we'll require a bit of extra machinery, as you suggest. > > In addition to this I think that there are a number of additional issues > that we need to address: > 1. Inclusion of openstack common - on the IRC last night it was mentioned > to have a blueprint for the config (I feel this only addresses a small part > of the problem). I think that we should do this for the openstack common > project. Thgis will be healthier in the short and long run. > I think the proposal was to use the existing config library that is already a part of openstack common. Is that what you are suggesting, or something else? > 2. Python 2.4. I have yet to understand how to identify which modules are > from later versions. If this is a MUST for the agents then we can leave the > agents as they are and introduce new agents that support RPC. Is this a > viable solution? > I'd REALLY like to avoid having the core team work on two separate versions the agents for 2.4 vs. > 2.4. I think it would slow us down. For 2.4 things that are purely syntactic (e.g., not using "as" for exceptions), I think its fine for us to enforce this as part of our code review process. If there are libraries important to new capabilities where the clearly superior choice is not an option for 2.4, I think we need to raise this as a community discussion point. Is there a particular module you have in mind? > 3. I am in favour of the drivers notifying the agents. Yes, this has a bit > of coupling ans syncing but it is a healthier solution. > No general disagreement here. As I said, any plugin using OVS already does this. Building a mechanism to do this for the linux bridge plugin would certainly be reasonable. Dan > > Thanks > Gary > > -- > 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
