[Yahoo-eng-team] [Bug 1444009] [NEW] Fix mock return settings in test_full_uuids_skip_port_id_lookup

2015-04-14 Thread Dane LeBlanc
Public bug reported:

In the test_full_uuids_skip_port_id_lookup test in test_security_group.py,  
there are a couple of problems
with how a mock return value is being set for a database query.

The first problem is that in this line:
fmock = sess_mock.query.return_value.outerjoin.return_value.filter
there is a missing '.return_value' missing between 'sess_mock' and 'query'.

The second problem is that in this line:
fmock.return_value.all.return_value = []
the 'all.return_value' should not be used.

For reference, the query for which this mock return value is being set is in the
get_sg_ids_grouped_by_port() method in ML2's db.py:
query = session.query(models_v2.Port,
  sg_db.SecurityGroupPortBinding.security_group_id)
query = query.outerjoin(sg_db.SecurityGroupPortBinding,
models_v2.Port.id == sg_binding_port)
query = query.filter(or_(*or_criteria))

If the mock return values are set correctly, the last statement should
yield an empty list.

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1444009

Title:
  Fix mock return settings in test_full_uuids_skip_port_id_lookup

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In the test_full_uuids_skip_port_id_lookup test in test_security_group.py,  
there are a couple of problems
  with how a mock return value is being set for a database query.

  The first problem is that in this line:
  fmock = sess_mock.query.return_value.outerjoin.return_value.filter
  there is a missing '.return_value' missing between 'sess_mock' and 'query'.

  The second problem is that in this line:
  fmock.return_value.all.return_value = []
  the 'all.return_value' should not be used.

  For reference, the query for which this mock return value is being set is in 
the
  get_sg_ids_grouped_by_port() method in ML2's db.py:
  query = session.query(models_v2.Port,

sg_db.SecurityGroupPortBinding.security_group_id)
  query = query.outerjoin(sg_db.SecurityGroupPortBinding,
  models_v2.Port.id == sg_binding_port)
  query = query.filter(or_(*or_criteria))

  If the mock return values are set correctly, the last statement should
  yield an empty list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1444009/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1443522] [NEW] Neutron dsvm functional tests fail with TimeoutException in test_killed_monitor_respawns

2015-04-13 Thread Dane LeBlanc
Public bug reported:

Occasionally the check-neutron-dsvm-functional upstream gating tests
fail with a TimeoutException error in the
neutron.tests.functional.agent.linux.test_ovsdb_monitor.TestOvsdbMonitor.test_killed_monitor_respawns
tests (both vsctl and native):

http://logstash.openstack.org/#eyJzZWFyY2giOiJcImxpbmUgODEsIGluIHRlc3Rfa2lsbGVkX21vbml0b3JfcmVzcGF3bnNcIiAiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0Mjg5NDA3NDYwMDh9

Here's a sample log from a failing check-neutron-dsvm-functional test
run:

ft1.123: 
neutron.tests.functional.agent.linux.test_ovsdb_monitor.TestOvsdbMonitor.test_killed_monitor_respawns(vsctl)_StringException:
 Empty attachments:
  pythonlogging:''
  pythonlogging:'neutron.api.extensions'
  stderr
  stdout

Traceback (most recent call last):
  File neutron/tests/functional/agent/linux/test_ovsdb_monitor.py, line 81, 
in test_killed_monitor_respawns
output1 = self.collect_initial_output()
  File neutron/tests/functional/agent/linux/test_ovsdb_monitor.py, line 76, 
in collect_initial_output
eventlet.sleep(0.01)
  File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py,
 line 34, in sleep
hub.switch()
  File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py,
 line 294, in switch
return self.greenlet.switch()
  File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py,
 line 346, in run
self.wait(sleep_time)
  File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/poll.py,
 line 85, in wait
presult = self.do_poll(seconds)
  File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/epolls.py,
 line 62, in do_poll
return self.poll.poll(seconds)
  File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/fixtures/_fixtures/timeout.py,
 line 52, in signal_handler
raise TimeoutException()
fixtures._fixtures.timeout.TimeoutException

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1443522

Title:
  Neutron dsvm functional tests fail with TimeoutException in
  test_killed_monitor_respawns

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Occasionally the check-neutron-dsvm-functional upstream gating tests
  fail with a TimeoutException error in the
  
neutron.tests.functional.agent.linux.test_ovsdb_monitor.TestOvsdbMonitor.test_killed_monitor_respawns
  tests (both vsctl and native):

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJcImxpbmUgODEsIGluIHRlc3Rfa2lsbGVkX21vbml0b3JfcmVzcGF3bnNcIiAiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0Mjg5NDA3NDYwMDh9

  Here's a sample log from a failing check-neutron-dsvm-functional test
  run:

  ft1.123: 
neutron.tests.functional.agent.linux.test_ovsdb_monitor.TestOvsdbMonitor.test_killed_monitor_respawns(vsctl)_StringException:
 Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
stderr
stdout

  Traceback (most recent call last):
File neutron/tests/functional/agent/linux/test_ovsdb_monitor.py, line 81, 
in test_killed_monitor_respawns
  output1 = self.collect_initial_output()
File neutron/tests/functional/agent/linux/test_ovsdb_monitor.py, line 76, 
in collect_initial_output
  eventlet.sleep(0.01)
File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py,
 line 34, in sleep
  hub.switch()
File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py,
 line 294, in switch
  return self.greenlet.switch()
File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py,
 line 346, in run
  self.wait(sleep_time)
File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/poll.py,
 line 85, in wait
  presult = self.do_poll(seconds)
File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/epolls.py,
 line 62, in do_poll
  return self.poll.poll(seconds)
File 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/fixtures/_fixtures/timeout.py,
 line 52, in signal_handler
  raise TimeoutException()
  fixtures._fixtures.timeout.TimeoutException

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1443522/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : 

[Yahoo-eng-team] [Bug 1441205] [NEW] Re-use callers session in ML2 DB methods

2015-04-07 Thread Dane LeBlanc
Public bug reported:

The get_port_from_device_mac() and get_sg_ids_grouped_by_port() methods in ML2 
db.py module
do not use a session passed in from the caller, but instead create a new 
session.
This should be changed so that the caller's session is passed in to be 
consistent with
other methods in ML2 db.py.

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1441205

Title:
  Re-use callers session in ML2 DB methods

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The get_port_from_device_mac() and get_sg_ids_grouped_by_port() methods in 
ML2 db.py module
  do not use a session passed in from the caller, but instead create a new 
session.
  This should be changed so that the caller's session is passed in to be 
consistent with
  other methods in ML2 db.py.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1441205/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1441382] [NEW] IPv6 SLAAC subnet Tempest tests fail due to IntegrityError

2015-04-07 Thread Dane LeBlanc
Public bug reported:

If 2 Tempest tests are run concurrently as follows:
Test 1: Any test that uses DHCP and cleans up the DHCP port as part of cleanup. 
For example:

tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcp_stateful_router
Test 2: Any test that creates an IPv6 SLAAC subnet
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_64_subnets
and this patch has been applied to eliminate DB access deadlocks:
https://review.openstack.org/#/c/170690/
Then occasionally Test 2 will fail in subnet create, and the following error 
can be observed
in the neutron server log (q-svc.log):

TRACE neutron.api.v2.resource DBReferenceError: (IntegrityError) (1452,
'Cannot add or update a child row: a foreign key constraint fails
(`neutron`.`ipallocations`, CONSTRAINT `ipallocations_ibfk_2` FOREIGN
KEY (`port_id`) REFERENCES `ports` (`id`) ON DELETE CASCADE)') 'INSERT
INTO ipallocations (port_id, ip_address, subnet_id, network_id) VALUES
(%s, %s, %s, %s)' ('dc359c7e-59b1-46d2-966f-194bc7fa0ffb',
'2003::f816:3eff:fea6:41d3', 'dc9f1ac8-92c1-4f0e-8b86-524824861fa3',
'45e4e8ea-81ed-46ad-a753-cdca392adb2a')

Here is a full traceback:

2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/api/v2/resource.py, line 83, in resource
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/api/v2/base.py, line 461, in create
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource obj = 
obj_creator(request.context, **kwargs)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/plugins/ml2/plugin.py, line 794, in create_subnet
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource result, mech_context 
= self._create_subnet_db(context, subnet)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/plugins/ml2/plugin.py, line 785, in 
_create_subnet_db
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource result = 
super(Ml2Plugin, self).create_subnet(context, subnet)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/db/db_base_plugin_v2.py, line 1349, in 
create_subnet
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource raise 
n_exc.BadRequest(resource='subnets', msg=msg)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/db/db_base_plugin_v2.py, line 1285, in 
_create_subnet_from_implicit_pool
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource # If this subnet 
supports auto-addressing, then update any
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/db/db_base_plugin_v2.py, line 1379, in 
_add_auto_addrs_on_network_ports
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource except 
db_exc.DBReferenceError:
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 470, 
in __exit__
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource self.rollback()
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py, line 
60, in __exit__
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource 
compat.reraise(exc_type, exc_value, exc_tb)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 467, 
in __exit__
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource self.commit()
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 377, 
in commit
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource self._prepare_impl()
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 357, 
in _prepare_impl
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource self.session.flush()
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1919, 
in flush
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource self._flush(objects)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 2037, 
in _flush
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource 
transaction.rollback(_capture_exception=True)
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py, line 
60, in __exit__
2015-04-07 16:39:16.026 TRACE neutron.api.v2.resource 
compat.reraise(exc_type, exc_value, exc_tb)
2015-04-07 16:39:16.026 TRACE 

[Yahoo-eng-team] [Bug 1440192] [NEW] DB Deadlock: Lock wait timeout exceeded; try restarting transaction') 'INSERT INTO ipallocations

2015-04-03 Thread Dane LeBlanc
/dist-packages/sqlalchemy/orm/unitofwork.py, line 
526, in execute
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource uow
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py, line 
65, in save_obj
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource mapper, table, insert)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py, line 
570, in _emit_insert_statements
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource execute(statement, 
multiparams)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 729, 
in execute
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource return meth(self, 
multiparams, params)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py, line 321, 
in _execute_on_connection
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource return 
connection._execute_clauseelement(self, multiparams, params)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 826, 
in _execute_clauseelement
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource compiled_sql, 
distilled_params
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 958, 
in _execute_context
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource context)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/compat/handle_error.py,
 line 261, in _handle_dbapi_exception
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource e, statement, 
parameters, cursor, context)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 1156, 
in _handle_dbapi_exception
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
util.raise_from_cause(newraise, exc_info)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/compat.py, line 199, 
in raise_from_cause
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
reraise(type(exception), exception, tb=exc_tb)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py, line 951, 
in _execute_context
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource context)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py, line 
436, in do_execute
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
cursor.execute(statement, parameters)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py, line 174, in execute
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
self.errorhandler(self, exc, value)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/lib/python2.7/dist-packages/MySQLdb/connections.py, line 36, in 
defaulterrorhandler
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource raise errorclass, 
errorvalue

Steps to Reproduce:

(1) Run DevStack with Q_DVR_MODE=dvr_snat in localrc/local.conf
(2) cd /opt/stack/tempest
(3) Create a file called my_load_list_file with the following content:

tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_64_subnets[id-4256c61d-c538-41ea-9147-3c450c36669e]
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcp_stateful_router[id-e98f65db-68f4-4330-9fea-abd8c5192d4d]

(4) Run 'testr init'
(5) Run the following test loop:

for i in `seq 1 50`; do testr run --load-list=my_load_list_file  
my_tempest_log; done
 
You should see the failure in approximately 1 in 6 runs.

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1440192

Title:
  DB Deadlock: Lock wait timeout exceeded; try restarting transaction')
  'INSERT INTO ipallocations

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If DVR is enabled, and the following 2 Tempest tests are run
  concurrently:

  
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcp_stateful_router[id-e98f65db-68f4-4330-9fea-abd8c5192d4d]
  
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_64_subnets[id-4256c61d-c538-41ea-9147-3c450c36669e]

  then the test_dhcpv6_64_subnets test case will fail intermittently
  (about 1

[Yahoo-eng-team] [Bug 1432270] [NEW] Create router port without fixed_ips should not associate IPv6 SLAAC addrs

2015-03-14 Thread Dane LeBlanc
Public bug reported:

Consider the following sequence:
- Create a neutron network
- Create multiple subnets on the network, including one or more IPv6 SLAAC
  or DHCPv6-stateless subnets
- Create a port on the network without specifying fixed_ips and with
   one of the following device_owners:
  - DEVICE_OWNER_ROUTER_INTF,
  - DEVICE_OWNER_DVR_INTERFACE

The port created in this case is incorrectly getting associated with
addresses from the SLAAC or DHCPv6-stateless subnet(s).

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1432270

Title:
  Create router port without fixed_ips should not associate IPv6 SLAAC
  addrs

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Consider the following sequence:
  - Create a neutron network
  - Create multiple subnets on the network, including one or more IPv6 SLAAC
or DHCPv6-stateless subnets
  - Create a port on the network without specifying fixed_ips and with
 one of the following device_owners:
- DEVICE_OWNER_ROUTER_INTF,
- DEVICE_OWNER_DVR_INTERFACE

  The port created in this case is incorrectly getting associated with
  addresses from the SLAAC or DHCPv6-stateless subnet(s).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1432270/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1427474] [NEW] IPv6 SLAAC subnet create should update ports on net

2015-03-02 Thread Dane LeBlanc
Public bug reported:

If ports are first created on a network, and then an IPv6 SLAAC
or DHCPv6-stateless subnet is created on that network, then the
ports created prior to the subnet create are not getting
automatically updated (associated) with addresses for the
SLAAC/DHCPv6-stateless subnet, as required.

Note that this problem was discussed in the Neutron
multiple-ipv6-prefixes blueprint, but is being addressed
with a separate  Neutron bug since this is a bug that can
potentially be backported to Juno.

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1427474

Title:
  IPv6 SLAAC subnet create should update ports on net

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If ports are first created on a network, and then an IPv6 SLAAC
  or DHCPv6-stateless subnet is created on that network, then the
  ports created prior to the subnet create are not getting
  automatically updated (associated) with addresses for the
  SLAAC/DHCPv6-stateless subnet, as required.

  Note that this problem was discussed in the Neutron
  multiple-ipv6-prefixes blueprint, but is being addressed
  with a separate  Neutron bug since this is a bug that can
  potentially be backported to Juno.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1427474/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1393435] [NEW] Subnet delete for IPv6 SLAAC should not require prior port disassoc

2014-11-17 Thread Dane LeBlanc
Public bug reported:

With the current Neutron implementation, a subnet cannot be deleted
until all associated IP addresses have been removed from ports (via
port update) or the associated ports/VMs have been deleted. 

In the case of SLAAC-enabled subnets, however, it's not feasible to
require removal of SLAAC-generated addresses individually from each
associated port before deleting a subnet because of the multicast
nature of RA messages. For SLAAC-enabled subnets, the processing of
subnet delete requests needs to be changed so that these subnets will
be allowed to be deleted, and all ports get disassociated from their
corresponding SLAAC IP address, when there are ports existing
on the SLAAC subnet.

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1393435

Title:
  Subnet delete for IPv6 SLAAC should not require prior port disassoc

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  With the current Neutron implementation, a subnet cannot be deleted
  until all associated IP addresses have been removed from ports (via
  port update) or the associated ports/VMs have been deleted.   

  In the case of SLAAC-enabled subnets, however, it's not feasible to
  require removal of SLAAC-generated addresses individually from each
  associated port before deleting a subnet because of the multicast
  nature of RA messages. For SLAAC-enabled subnets, the processing of
  subnet delete requests needs to be changed so that these subnets will
  be allowed to be deleted, and all ports get disassociated from their
  corresponding SLAAC IP address, when there are ports existing
  on the SLAAC subnet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1393435/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1369767] [NEW] Fixed IPs that do not match EUI64 should be rejected for IPv6 SLAAC subnets

2014-09-15 Thread Dane LeBlanc
Public bug reported:

When a port is created on a subnet that is configured for IPv6 SLAAC,
that port's IP address will be automatically generated (to a pre-
determined value) using the EUI64 address algorithm, based on the
subnet's IPv6 prefix and the port's MAC address. Therefore, any port
create requests that include a fixed IPv6 address that does not match
the expected IPv6 EUI64 address should be rejected.

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1369767

Title:
  Fixed IPs that do not match EUI64 should be rejected for IPv6 SLAAC
  subnets

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When a port is created on a subnet that is configured for IPv6 SLAAC,
  that port's IP address will be automatically generated (to a pre-
  determined value) using the EUI64 address algorithm, based on the
  subnet's IPv6 prefix and the port's MAC address. Therefore, any port
  create requests that include a fixed IPv6 address that does not match
  the expected IPv6 EUI64 address should be rejected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1369767/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1361896] [NEW] Test commit - Do not review

2014-08-26 Thread Dane LeBlanc
Public bug reported:

This is  a temporary bug filed to test direct reporting of 3rd party CI
test results.

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1361896

Title:
  Test commit - Do not review

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  This is  a temporary bug filed to test direct reporting of 3rd party
  CI test results.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1361896/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1361896] Re: Test commit - Do not review

2014-08-26 Thread Dane LeBlanc
** Changed in: neutron
   Status: New = Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1361896

Title:
  Test commit - Do not review

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  This is  a temporary bug filed to test direct reporting of 3rd party
  CI test results.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1361896/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1286565] [NEW] Cisco Nexus: maximum recursion error in ConnectionContext.__del__

2014-03-01 Thread Dane LeBlanc
Public bug reported:

If DevStack is configured for the Cisco Nexus plugin with the latest DevStack, 
the following
infinite recursion error is observed:
Exception RuntimeError: 'maximum recursion depth exceeded' in bound method
ConnectionContext.__del__ of 
neutron.openstack.common.rpc.amqp.ConnectionContext
object at 0x403a3d0 ignored

An investigation shows that this failure triggered when the DB base plugin's
_is_native_pagination_supported method is called. The infinite recursion begins
when this exception is raised:

 raise AttributeError(
 _('%(model)s' object has no attribute '%(name)s') %
{'model': self._model, 'name': name})

in the PluginV2.__getattr__ method in
neutron/plugins/cisco/network_plugin.py. The problem is that self._model
object is being interpreted as a string, and this causes infinite recursion
into the __getattr__ method.

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New


** Tags: cisco

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1286565

Title:
  Cisco Nexus: maximum recursion error in ConnectionContext.__del__

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If DevStack is configured for the Cisco Nexus plugin with the latest 
DevStack, the following
  infinite recursion error is observed:
  Exception RuntimeError: 'maximum recursion depth exceeded' in bound method
  ConnectionContext.__del__ of 
neutron.openstack.common.rpc.amqp.ConnectionContext
  object at 0x403a3d0 ignored

  An investigation shows that this failure triggered when the DB base plugin's
  _is_native_pagination_supported method is called. The infinite recursion 
begins
  when this exception is raised:

   raise AttributeError(
   _('%(model)s' object has no attribute '%(name)s') %
  {'model': self._model, 'name': name})

  in the PluginV2.__getattr__ method in
  neutron/plugins/cisco/network_plugin.py. The problem is that self._model
  object is being interpreted as a string, and this causes infinite recursion
  into the __getattr__ method.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1286565/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1284162] [NEW] Cisco plugin fails test_port_list_filter_by_router_id with ParseError no element found

2014-02-24 Thread Dane LeBlanc
Public bug reported:

When the Cisco nexus plugin is configured on DevStack, the recently added 
tempest Neutron API test test_port_list_filter_by_router_id fails with the 
following error:
 ParseError: no element found: line 1, column 0

These failures occur for the following classes:
NetworksIpV6TestXML
NetworksTestXML

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New


** Tags: cisco

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1284162

Title:
  Cisco plugin fails test_port_list_filter_by_router_id with ParseError
  no element found

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When the Cisco nexus plugin is configured on DevStack, the recently added 
tempest Neutron API test test_port_list_filter_by_router_id fails with the 
following error:
   ParseError: no element found: line 1, column 0

  These failures occur for the following classes:
  NetworksIpV6TestXML
  NetworksTestXML

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1284162/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1281694] [NEW] Delete subnet fails if assoc port has IPs from another subnet

2014-02-18 Thread Dane LeBlanc
Public bug reported:

Perform the following:
- Create a network
- Create a subnet (subnet 1) on the network
- Create a port on the network. (A fixed IP is allocated from subnet 1)
- Create a second subnet (subnet 2) on the same network
- Update port with fixed IP from subnet 2 (port has 2 fixed IPs)
- Update port to remove fixed IP from subnet 2 (port has 1 fixed IP)
- Delete subnet 2
= = =  FAILURE: Subnet delete fails because SUPPOSEDLY there
are port(s) still associated with that subnet.

Looking at delete_subnet() in neutron/db/db_base_plugin_v2.py,
the check for port(s) still being associated with that _subnet_
is actually checking for port(s) still being associated with
the _network_ (not the subnet), i.e. it's doing a:
filter_by(network_id=subnet.network_id)
rather than a:
filter_by(subnet_id=subnet['id'])

** Affects: neutron
 Importance: Undecided
 Assignee: Dane LeBlanc (leblancd)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Dane LeBlanc (leblancd)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1281694

Title:
  Delete subnet fails if assoc port has IPs from another subnet

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Perform the following:
  - Create a network
  - Create a subnet (subnet 1) on the network
  - Create a port on the network. (A fixed IP is allocated from subnet 1)
  - Create a second subnet (subnet 2) on the same network
  - Update port with fixed IP from subnet 2 (port has 2 fixed IPs)
  - Update port to remove fixed IP from subnet 2 (port has 1 fixed IP)
  - Delete subnet 2
  = = =  FAILURE: Subnet delete fails because SUPPOSEDLY there
  are port(s) still associated with that subnet.

  Looking at delete_subnet() in neutron/db/db_base_plugin_v2.py,
  the check for port(s) still being associated with that _subnet_
  is actually checking for port(s) still being associated with
  the _network_ (not the subnet), i.e. it's doing a:
  filter_by(network_id=subnet.network_id)
  rather than a:
  filter_by(subnet_id=subnet['id'])

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1281694/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1241262] Re: Add a Cisco smoke test for testing plugins on actual Nexus switch

2013-11-14 Thread Dane LeBlanc
** Changed in: neutron
   Status: In Progress = Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1241262

Title:
  Add a Cisco smoke test for testing plugins on actual Nexus switch

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Create a Cisco smoke test for quickly testing Nexus plugin operation
  (for both original Cisco Nexus plugin and the Cisco ML2 mechanism
  driver) operation on an actual Nexus switch. 

   The test requires SSH access to a Nexus switch which has
  one ethernet interface available on which the user doesn't
  mind VLANs being configured/unconfigured by the test.
  In order to trigger the test to run, the user must provide
  connection information for a Nexus switch (IP address,
  username, password, and ethernet interface number).

  The smoke test is based on existing Neutron unit tests.
  If Nexus switch connection information is not provided,
  the tests will default to being skipped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1241262/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp