On 01/22/2015 02:35 PM, Kevin Benton wrote: > Right, there are two bugs here. One is in whatever went wrong with defer_apply > and one is with this exception handling code. I would allow the fix to go in > for > the exception handling and then file another bug for the actual underlying > defer_apply bug.
What went wrong with defer_apply() was caused by oslo.concurrency - version 1.4.1 seems to fix the problem, see https://review.openstack.org/#/c/149400/ (thanks Ihar!) Xavier - can you update your oslo.concurrency to that version and verify it helps? It seems to work in my config. Then the change in the other patchset could be applied, along with a test that triggers exceptions so this gets caught. Thanks, -Brian > On Thu, Jan 22, 2015 at 10:32 AM, Brian Haley <brian.ha...@hp.com > <mailto:brian.ha...@hp.com>> wrote: > > On 01/22/2015 01:06 PM, Kevin Benton wrote: > > There was a bug for this already. > > https://bugs.launchpad.net/bugs/1413111 > > Thanks Kevin. I added more info to it, but don't think the patch > proposed there > is correct. Something in the iptables manager defer_apply() code isn't > quite right. > > -Brian > > > > On Thu, Jan 22, 2015 at 9:07 AM, Brian Haley <brian.ha...@hp.com > <mailto:brian.ha...@hp.com> > > <mailto:brian.ha...@hp.com <mailto:brian.ha...@hp.com>>> wrote: > > > > On 01/22/2015 10:17 AM, Carl Baldwin wrote: > > > I think this warrants a bug report. Could you file one with what > you > > > know so far? > > > > Carl, > > > > Seems as though a recent change introduced a bug. This is on a > devstack > > I just created today, at l3/vpn-agent startup: > > > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent Traceback > (most > > recent call last): > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent File > > "/opt/stack/neutron/neutron/common/utils.py", line 342, in call > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent return > > func(*args, **kwargs) > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent File > > "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in > process_router > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent > > self._process_external(ri) > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent File > > "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in > _process_external > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent > > self._update_fip_statuses(ri, existing_floating_ips, fip_statuses) > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent > UnboundLocalError: > > local variable 'existing_floating_ips' referenced before assignment > > 2015-01-22 11:55:07.961 4203 TRACE neutron.agent.l3.agent > > Traceback (most recent call last): > > File > "/usr/local/lib/python2.7/dist-packages/eventlet/greenpool.py", > line > > 82, in _spawn_n_impl > > func(*args, **kwargs) > > File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1093, in > > _process_router_update > > self._process_router_if_compatible(router) > > File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1047, in > > _process_router_if_compatible > > self._process_added_router(router) > > File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 1056, in > > _process_added_router > > self.process_router(ri) > > File "/opt/stack/neutron/neutron/common/utils.py", line 345, in > call > > self.logger(e) > > File > "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line > > 82, in __exit__ > > six.reraise(self.type_, self.value, self.tb) > > File "/opt/stack/neutron/neutron/common/utils.py", line 342, in > call > > return func(*args, **kwargs) > > File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 584, in > > process_router > > self._process_external(ri) > > File "/opt/stack/neutron/neutron/agent/l3/agent.py", line 576, in > > _process_external > > self._update_fip_statuses(ri, existing_floating_ips, > fip_statuses) > > UnboundLocalError: local variable 'existing_floating_ips' referenced > before > > assignment > > > > Since that's happening while we're holding the iptables lock I'm > assuming > > no rules are being applied. > > > > I'm looking into it now, will file a bug if there isn't already one. > > > > -Brian > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Kevin Benton > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
