I'm personally a fan of the model where a DHCP port is just like any other port, including how the devices are named. Mark's existing patch already sets the device_id attribute on the Quantum port object on the network-id, and uses to look up the port-id, so it should be a pretty easy change to make.
Dan On Sun, Jul 8, 2012 at 1:06 AM, Gary Kotton <gkot...@redhat.com> wrote: > ** > On 07/08/2012 10:48 AM, Salvatore Orlando wrote: > > At a first glance (meaning that I've not looked in detail at the code), I > would say that this kind of situations will be much more likely to happen > once we start attaching different services to Quantum ports. > I reckon this is an example of incompatibility between the dnsmasq-based > plugin/driver for DHCP and the linux bridge L2 plugin - there will be of > course cases in which plugin are definitively incompatible, but we should > strive to make sure that such incompatibility cases are limited - and port > naming should probably not be a reason for incompatibility. > > Finding a final solution during the Folsom timeline is going to be quite > difficult, and it certainly needs a thorough discussion. Among the options > suggested by Gary, I probably prefer (in order) either #4 or #2. From my > (limited) perspective, it looks like it could be merged as a separate bug > fix, do you agree? > > > I do not think that this is a blocking issue and can certainly be handled > as a bug fix. I have given +1 to the development (+2 is pending a really > minor issue). > > I would prefer that #4 be the solution. The reason is twofold: > 1. I do not think that a agent should create a device from the network id. > I think that this is a bug in the linux bridge implementation and that it > should be removed as part of the V1 removal. > 2. As a rule I do not think that the addition of new agents should require > us to change the functionality of existing agents. This is not written in > stone but should be taken into account. > > > > Salvatore > > On 8 July 2012 08:34, Gary Kotton <gkot...@redhat.com> wrote: > >> Hi, >> Great work regarding the agent. My tests with the OVS have passed >> successfully. I nonetheless have some problems regarding the linuxbridge. >> The problem is that if a device is created from the network ID then it >> should have a "gw-" as the prefix. >> I think that if you create the dnsmasq interface from the port id then >> this will solve the issue. This would require a few changes to the dhcp >> code. If not then we need to change the logic of the linux bridge agent. I >> have added my comments to https://review.openstack.org/#/c/9064/. >> >> Off the bat I think that there are a few options: >> 1. DHCP agent changes tap device to "gw-..." no changes to linux bridge. >> The fact that the DNSMASQ may not be the default gateway may be a bit >> misleading (I agree with what you have written in your comments) >> 2. Change linux bridge code to check if the tap device is contains a >> network id. >> 3. Add a new prefix that could indicate that the device is a "dhcp" >> device. This is a minor change in the linux bridge agent to support. I'd be >> happy to do this. >> 4. DHCP agent uses the port id. No changes to linux bridge. >> Any thoughts? >> >> 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 >> > > > > -- > 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
