[Rdo-list] Trying out Neutron Quickstart running into issues with netns (l2 agent and dhcp agent)

[Gilles Dubreuil]

On Mon, 2013-08-05 at 12:27 -0400, Terry Wilson wrote:
> 
> ----- Original Message -----
> > On 08/05/2013 04:27 AM, Thomas Graf wrote:
> > > On 08/04/2013 05:47 PM, Kashyap Chamarthy wrote:
> > >>>> 2013-08-04 09:08:05  WARNING [quantum.openstack.common.loopingcall]
> > >>>> task run outlasted interval by 56.853869 sec
> > >>>> 2013-08-04 09:08:06     INFO [quantum.agent.dhcp_agent]
> > >>>> Synchronizing state
> > >>>> 2013-08-04 09:32:34    ERROR [quantum.agent.dhcp_agent] Unable to
> > >>>> enable dhcp.
> > >>>> Traceback (most recent call last):
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/dhcp_agent.py", line
> > >>>> 131, in call_driver
> > >>>>      getattr(driver, action)()
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/dhcp.py", line
> > >>>> 124, in enable
> > >>>>      reuse_existing=True)
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/dhcp_agent.py", line
> > >>>> 554, in setup
> > >>>>      namespace=namespace)
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/interface.py",
> > >>>> line 181, in plug
> > >>>>      ns_dev.link.set_address(mac_address)
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py",
> > >>>> line 180, in set_address
> > >>>>      self._as_root('set', self.name, 'address', mac_address)
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py",
> > >>>> line 167, in _as_root
> > >>>>      kwargs.get('use_root_namespace', False))
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py",
> > >>>> line 47, in _as_root
> > >>>>      namespace)
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py",
> > >>>> line 58, in _execute
> > >>>>      root_helper=root_helper)
> > >>>>    File
> > >>>> "/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py",
> > >>>> line 61, in execute
> > >>>>      raise RuntimeError(m)
> > >>>> RuntimeError:
> > >>>> Command: ['sudo', 'quantum-rootwrap', '/etc/quantum/rootwrap.conf',
> > >>>> 'ip', 'link', 'set', 'tap07d8cc77-fc', 'address', 'fa:16:3e:da:66:28']
> > >>>> Exit code: 2
> > >>>> Stdout: ''
> > >>>> Stderr: 'RTNETLINK answers: Device or resource busy\n'
> > > 
> > > Quantum attempts to change the MAC address while the link is up. The
> > > live MAC address change feature is not supported in the openstack
> > > kernel at this point.
> > > 
> > > We can attempt a backport of the feature to the openstack kernel and
> > > enable it for tap and veth devices or we modify quantum to bring down
> > > the interface before changing the mac address and bring it up again
> > > afterwards.
> > 
> > Thanks Thomas.  Or perhaps we need a fix to Quantum itself to create the
> > link with the proper MAC address to begin with rather than changing it
> > in a second step?
> > 
> > With the above error, I wonder if the Quantum Quickstart ever fully
> > worked at all on either RHOS or RDO Grizzly?
> > 
> > Terry, how did you work around the above issue when testing on RHOS?
> 
> I didn't run into this issue when testing on RHOS or RDO. For me, on my test VMs, everything comes up properly on both systems (launching vm's, getting addresses, connecting vial floating ip, etc. just works)--although I haven't tested RHOS with the latest changes because the build was just done this morning.
> 
> Terry

Interestingly we're having similar issues with l2-agent and dhcp on RDO,
using ovs_veth to True. Meanwhile our environment is not a all-in-one
architecture but using a dedicated controller node and a dedicated
network node plus two compute nodes.

The instances sitting on the same host are talking to each others -
assuming same tenant subnet/router of course.
But no instances across hosts cat see each others.
Also, none of the VMs are getting dhcp.

The MAC address reset solution would be great. Because when managing
remote servers is just a blocker especially when trying to push the
whole thing automatically. It'll force to have a dedicated mgmt
interface, which of course is the recommended thing in production but
for now....

Gilles