[Yahoo-eng-team] [Bug 1582739] [NEW] [DVR][L3 HA] Unable to ping 8.8.8.8 from VM without floating ip

2016-05-17 Thread Ann Kamyshnikova
Public bug reported:

On the environment with L3 HA and DVR enabled all pings from VM without
floating ip to 8.8.8.8 were lost.

This happened because router_centralized_snat port was binded to the
wrong host were l3 agent was in standby state.

root@node-4:~# neutron l3-agent-list-hosting-router 
a1de4263-08af-48cb-a9b5-400ebcd3ac1a
+--+---++---+--+
| id   | host  | admin_state_up | 
alive | ha_state |
+--+---++---+--+
| ae474016-48ee-4121-88b7-71b65f2a4244 | node-4.domain.tld | True   | 
:-)   | standby  |
| b93959c3-51da-45ae-8af7-aa90671953b4 | node-5.domain.tld | True   | 
:-)   | active   |
| ca082545-5c1a-4eb5-882b-b35bf76f9350 | node-2.domain.tld | True   | 
:-)   | standby  |
+--+---++---+--+
root@node-4:~# neutron port-show cd1e7af6-0aa7-444b-b0b3-37d04325655f   

 
+---+---+
| Field | Value 
|
+---+---+
| admin_state_up| True  
|
| allowed_address_pairs |   
|
| binding:host_id   | node-2.domain.tld 
|
| binding:profile   | {}
|
| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
|
| binding:vif_type  | ovs   
|
| binding:vnic_type | normal
|
| created_at| 2016-05-17T08:55:58   
|
| description   |   
|
| device_id | a1de4263-08af-48cb-a9b5-400ebcd3ac1a  
|
| device_owner  | network:router_centralized_snat   
|
| dns_name  |   
|
| extra_dhcp_opts   |   
|
| fixed_ips | {"subnet_id": "fe4e6901-f5ce-41b1-a7ce-582d70fe310e", 
"ip_address": "10.100.0.4"} |
| id| cd1e7af6-0aa7-444b-b0b3-37d04325655f  
|
| mac_address   | fa:16:3e:f4:1d:6a 
|
| name  |   
|
| network_id| 7e9e27d7-d331-4b09-8b28-04a0d5173af7  
|
| port_security_enabled | False 
|
| security_groups   |   
|
| status| DOWN  
|
| tenant_id |   
|
| updated_at| 2016-05-17T11:12:50   
|
+---+---+

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: l3-dvr-backlog l3-ha

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

Title:
  [DVR][L3 HA] Unable to ping 8.8.8.8 from VM without floating ip

Status in neutron:
  New

Bug description:
  On the environment with L3 HA and DVR enabled all pings from VM
  without floating ip to 8.8.8.8 were lost.

  This happened because router_centralized_snat port was binded to the
  wrong host were l3 agent was in standby state.

  root@node-4:~# neutron l3-age

[Yahoo-eng-team] [Bug 1566194] Re: Make sure resources for HA router exists before the router creation

2016-04-18 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: In Progress => Opinion

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

Title:
  Make sure resources for HA router exists before the router creation

Status in neutron:
  Opinion

Bug description:
  Before HA rouer is used by agent,
  1) HA network should be created
  2) vr_id has to be allocated
  3) HA router should able to create sufficient number of ports on HA network

  If scheduler(from rpc worker) process the HA router(as router is available in 
DB) before these resources are created, then the following races(between api 
and rpc workers) can happen
  1) Race for creating HA network
  2) vr_id not avialable for agent, so can't spawn HA proxy process
  3) If creating router ports in api worker is failed, router is deleted. So 
rpc worker will have races as router is deleted while it is binding router's ha 
ports to agent.

  To avoid this, l3 scheduler should skip this router(while syncing for
  the agent) if above resources are not yet created.

  To facilitate this, new status("ALLOCATING") is proposed for HA router in 
https://review.openstack.org/#/c/257059/
  In this patch, first router is created and set status as ALLOCATING. And once 
all the above resources are created, its status is changed back to ACTIVE. 
Added proper checks(in the code) to skip using Router if it's status is 
ALLOCATING.

  So with this patch
  1) we are creating a new router status
  2) carefully identify where router can be accessed before its resources are 
created.
  3) How code behaves(during its acess to router) when status transitioned from 
ALLOCATING to ACTIVE
  4) API impact

  Alternatively, if we are able to create HA router's resources before
  HA router creation, we can avoid a new status and new checks, but same
  functionality as https://review.openstack.org/#/c/257059/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1566194/+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 1562887] Re: L3 HA: IpAddressGenerationFailure during rally test execution

2016-03-30 Thread Ann Kamyshnikova
** Tags removed: l3-ha

** Summary changed:

- L3 HA: IpAddressGenerationFailure during rally test execution
+ IpAddressGenerationFailure during rally test execution

** Also affects: rally
   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/1562887

Title:
  IpAddressGenerationFailure during rally test execution

Status in neutron:
  New
Status in Rally:
  New

Bug description:
  Environment 3 controllers, 46 computes, liberty. L3 HA During
  execution NeutronNetworks.create_and_delete_routers in logs there is
  hundreds of traces in dhcp-agent logs
  http://paste.openstack.org/show/491423/,
  http://paste.openstack.org/show/491408/. Tests passes but having these
  traces in logs is ugly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1562887/+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 1562892] [NEW] L3 HA: HA networks remain existing after rally tests execution

2016-03-28 Thread Ann Kamyshnikova
Public bug reported:

After running rally tests HA networks remain existing although all HA routers 
were deleted.
For example, after running create_list_routers we have just one router (which 
was not created by rally) and around 35 HA networks: 
http://paste.openstack.org/show/491573/ There are no ports on these networks 
and they can be simply deleted with "neutron net-delete " command.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: l3-ha

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

Title:
  L3 HA: HA networks remain existing after rally tests execution

Status in neutron:
  New

Bug description:
  After running rally tests HA networks remain existing although all HA routers 
were deleted.
  For example, after running create_list_routers we have just one router (which 
was not created by rally) and around 35 HA networks: 
http://paste.openstack.org/show/491573/ There are no ports on these networks 
and they can be simply deleted with "neutron net-delete " command.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1562892/+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 1562887] [NEW] L3 HA: IpAddressGenerationFailure during rally test execution

2016-03-28 Thread Ann Kamyshnikova
Public bug reported:

Environment 3 controllers, 46 computes, liberty. L3 HA During execution
NeutronNetworks.create_and_delete_routers in logs there is hundreds of
traces in dhcp-agent logs http://paste.openstack.org/show/491423/,
http://paste.openstack.org/show/491408/. Tests passes but having these
traces in logs is ugly.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ha

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

Title:
  L3 HA: IpAddressGenerationFailure during rally test execution

Status in neutron:
  New

Bug description:
  Environment 3 controllers, 46 computes, liberty. L3 HA During
  execution NeutronNetworks.create_and_delete_routers in logs there is
  hundreds of traces in dhcp-agent logs
  http://paste.openstack.org/show/491423/,
  http://paste.openstack.org/show/491408/. Tests passes but having these
  traces in logs is ugly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1562887/+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 1562878] [NEW] L3 HA: Unable to complete operation on subnet

2016-03-28 Thread Ann Kamyshnikova
Public bug reported:

Environment 3 controllers, 46 computes, liberty. L3 HA During execution 
NeutronNetworks.create_and_delete_routers several times test failed with 
"Unable to complete operation on subnet . One or more ports have an IP 
allocation from this subnet. " trace in neutron-server logs 
http://paste.openstack.org/show/491557/
Rally report attached.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: l3-ha

** Attachment added: "create_delete_routers L3 HA report"
   
https://bugs.launchpad.net/bugs/1562878/+attachment/4614887/+files/create_delete_200_70.html

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

Title:
  L3 HA: Unable to complete operation on subnet

Status in neutron:
  New

Bug description:
  Environment 3 controllers, 46 computes, liberty. L3 HA During execution 
NeutronNetworks.create_and_delete_routers several times test failed with 
"Unable to complete operation on subnet . One or more ports have an IP 
allocation from this subnet. " trace in neutron-server logs 
http://paste.openstack.org/show/491557/
  Rally report attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1562878/+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 1562876] [NEW] Deadlock 'DELETE FROM ipallocationpools' during rally test_create_delete_routers

2016-03-28 Thread Ann Kamyshnikova
Public bug reported:

Environment 3 controllers, 46 computes, liberty. L3 HA During execution
NeutronNetworks.create_and_delete_routers several times test failed with
deadlock  error in neutron-server logs
http://paste.openstack.org/show/491572/.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

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

Title:
  Deadlock 'DELETE FROM ipallocationpools' during rally
  test_create_delete_routers

Status in neutron:
  New

Bug description:
  Environment 3 controllers, 46 computes, liberty. L3 HA During
  execution NeutronNetworks.create_and_delete_routers several times test
  failed with deadlock  error in neutron-server logs
  http://paste.openstack.org/show/491572/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1562876/+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 1557546] [NEW] Correct usage of context manager for transactions

2016-03-15 Thread Ann Kamyshnikova
Public bug reported:

When we working with transaction we should use context manager as if exception 
appears transaction can hang. 
The code like:

context.session.begin(subtransactions=True)
...
try:
context.session.add(binding)
context.session.commit()
except db_exc.DBDuplicateEntry:
context.session.rollback()

is not safe becuase if another exception, not DBDuplicateEntry will be
raised, transaction will hang.

** Affects: neutron
 Importance: Low
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
   Importance: Undecided => Low

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

Title:
  Correct usage of context manager for transactions

Status in neutron:
  New

Bug description:
  When we working with transaction we should use context manager as if 
exception appears transaction can hang. 
  The code like:

  context.session.begin(subtransactions=True)
  ...
  try:
  context.session.add(binding)
  context.session.commit()
  except db_exc.DBDuplicateEntry:
  context.session.rollback()

  is not safe becuase if another exception, not DBDuplicateEntry will be
  raised, transaction will hang.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1557546/+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 1555670] [NEW] L3 HA: MessagingTimeout during running rally create_and_delete_routers

2016-03-10 Thread Ann Kamyshnikova
Public bug reported:

During running rally test create_and_delete_routers (standard test) on
env with L3 HA enabled (3 controllers, 1 compute, liberty) getting about
50% failure with "Not enough l3 agents available to ensure HA. Minimum
required 2, available 1."

Logs of l3 agent full of errors http://paste.openstack.org/show/490011/,
so agent considered to be dead for server
http://paste.openstack.org/show/490010/ If concurrency for test is
lower than 10 the number of failing tests is reduced.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: l3-ha

** Attachment added: "rally test result"
   
https://bugs.launchpad.net/bugs/1555670/+attachment/4595093/+files/outpu1.html

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

Title:
  L3 HA: MessagingTimeout during running  rally
  create_and_delete_routers

Status in neutron:
  New

Bug description:
  During running rally test create_and_delete_routers (standard test) on
  env with L3 HA enabled (3 controllers, 1 compute, liberty) getting
  about 50% failure with "Not enough l3 agents available to ensure HA.
  Minimum required 2, available 1."

  Logs of l3 agent full of errors
  http://paste.openstack.org/show/490011/, so agent considered to be
  dead for server http://paste.openstack.org/show/490010/ If concurrency
  for test is  lower than 10 the number of failing tests is reduced.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1555670/+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 1519171] Re: model-migration check fails to detect integer-biginteger mismatch

2015-11-29 Thread Ann Kamyshnikova
The issue here is cause that in model is used with_variant type [1] So,
compare_type method see [2] and seems that it compares them as equal.
This is the only case in Neutron, so there are no other places to fix
this. I will propose patch for oslo.db, not sure that there is something
that should be done on Neutron side.


[1] - 
https://github.com/openstack/neutron/blob/master/neutron/db/model_base.py#L100
[2] - http://paste.openstack.org/show/480278/

** Changed in: neutron
   Status: Confirmed => Opinion

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

Title:
  model-migration check fails to detect integer-biginteger mismatch

Status in neutron:
  Opinion

Bug description:
  See
  
https://review.openstack.org/#/c/222079/15/neutron/db/migration/alembic_migrations/versions/mitaka/expand/32e5974ada25_add_neutron_resources_table.py

  Kevin had Integer in the model and BigInteger in the migration.
  This should be detected by _TestModelsMigrations().

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1519171/+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 1480808] Re: got an unexpected keyword argument 'exception_checker' when migrate neutron db

2015-11-17 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: Confirmed => 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/1480808

Title:
  got an unexpected keyword argument 'exception_checker' when migrate
  neutron db

Status in neutron:
  Invalid

Bug description:
  + /usr/bin/neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugin.ini --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini upgrade head
  Traceback (most recent call last):
File "/usr/bin/neutron-db-manage", line 10, in 
  sys.exit(main())
File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 
366, in main
  CONF.command.func(config, CONF.command.name)
File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 
119, in do_upgrade
  run_sanity_checks(config, revision)
File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 
357, in run_sanity_checks
  script_dir.run_env()
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 382, in 
run_env
  util.load_python_file(self.dir, 'env.py')
File "/usr/lib/python2.7/site-packages/alembic/util.py", line 241, in 
load_python_file
  module = load_module_py(module_id, path)
File "/usr/lib/python2.7/site-packages/alembic/compat.py", line 79, in 
load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py",
 line 24, in 
  from neutron.db.migration.models import head  # noqa
File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 
24, in 
  from neutron.db import address_scope_db  # noqa
File "/usr/lib/python2.7/site-packages/neutron/db/address_scope_db.py", 
line 22, in 
  from neutron.extensions import address_scope as ext_address_scope
File 
"/usr/lib/python2.7/site-packages/neutron/extensions/address_scope.py", line 
19, in 
  from neutron.api.v2 import base
File "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 36, in 

  from neutron import quota
File "/usr/lib/python2.7/site-packages/neutron/quota/__init__.py", line 28, 
in 
  from neutron.quota import resource_registry
File "/usr/lib/python2.7/site-packages/neutron/quota/resource_registry.py", 
line 18, in 
  from neutron.quota import resource
File "/usr/lib/python2.7/site-packages/neutron/quota/resource.py", line 
139, in 
  class TrackedResource(BaseResource):
File "/usr/lib/python2.7/site-packages/neutron/quota/resource.py", line 
209, in TrackedResource
  exception_checker=lambda exc:
  TypeError: __init__() got an unexpected keyword argument 'exception_checker'

  
  /usr/lib/python2.7/site-packages/oslo_db/api.py 

  class wrap_db_retry(object):
  def __init__(self, retry_interval=0, max_retries=0, inc_retry_interval=0,
   max_retry_interval=0, retry_on_disconnect=False,
   retry_on_deadlock=False, retry_on_request=False):
  super(wrap_db_retry, self).__init__()

  did not contain the param exception_checker

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1480808/+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 1413859] Re: neutron-db-manage sync failed

2015-11-10 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: Incomplete => 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/1413859

Title:
  neutron-db-manage sync failed

Status in neutron:
  Invalid

Bug description:
  when use this "su -s /bin/sh -c "neutron-db-manage --config-file
  /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini
  upgrade head" neutron " , report error below:

  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  Traceback (most recent call last):
File "/usr/bin/neutron-db-manage", line 10, in 
  sys.exit(main())
File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 
141, in main
  CONF.command.func(config, CONF.command.name)
File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 
78, in do_upgrade_downgrade
  do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 
57, in do_alembic_command
  getattr(alembic_command, cmd)(config, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/alembic/command.py", line 125, in 
upgrade
  script.run_env()
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 203, in 
run_env
  util.load_python_file(self.dir, 'env.py')
File "/usr/lib/python2.7/site-packages/alembic/util.py", line 212, in 
load_python_file
  module = load_module_py(module_id, path)
File "/usr/lib/python2.7/site-packages/alembic/compat.py", line 58, in 
load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py",
 line 103, in 
  run_migrations_online()
File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py",
 line 87, in run_migrations_online
  options=build_options())
File "", line 7, in run_migrations
File "/usr/lib/python2.7/site-packages/alembic/environment.py", line 688, 
in run_migrations
  self.get_context().run_migrations(**kw)
File "/usr/lib/python2.7/site-packages/alembic/migration.py", line 242, in 
run_migrations
  self):
File "/usr/lib/python2.7/site-packages/alembic/command.py", line 114, in 
upgrade
  return script._upgrade_revs(revision, rev)
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 183, in 
_upgrade_revs
  for script in reversed(list(revs))
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 165, in 
_iterate_revisions
  lower = self.get_revision(lower)
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 102, in 
get_revision
  return self._revision_map[id_]
File "/usr/lib/python2.7/site-packages/alembic/util.py", line 268, in 
__get__
  obj.__dict__[self.__name__] = result = self.fget(obj)
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 213, in 
_revision_map
  script = Script._from_filename(self, self.versions, file_)
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 496, in 
_from_filename
  module = util.load_python_file(dir_, filename)
File "/usr/lib/python2.7/site-packages/alembic/util.py", line 212, in 
load_python_file
  module = load_module_py(module_id, path)
File "/usr/lib/python2.7/site-packages/alembic/compat.py", line 58, in 
load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/versions/d06e871c0d5_set_admin_state_up_not_null_ml2.py",
 line 38, in 
  @migration.skip_if_offline
  AttributeError: 'module' object has no attribute 'skip_if_offline'

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1413859/+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 1511732] [NEW] HA router schedule for another active agent

2015-10-30 Thread Ann Kamyshnikova
Public bug reported:

Neutron Liberty, Ubuntu 14.04

3 controllers(3 l3-agents are available and active.), 1 compute

I have max_l3_agents_per_router=2, router is scheduled to 2 agents. If
you of one these agents is stopped I will have something like:

root@node-1:~# neutron l3-agent-list-hosting-router r3
+--+---++---+--+
| id   | host  | admin_state_up | 
alive | ha_state |
+--+---++---+--+
| 1fa93569-fc36-4fb4-b467-85b11ba5f20c | node-3.domain.tld | True   | 
xxx   | active   |
| 709998f7-cc64-4b6a-9777-6c815dfebb5c | node-2.domain.tld | True   | 
:-)   | active   |
+--+---++---+--+


The point is: router won't be rescheduled from dead agent and scheduled for 
another available active one. This situation can be avoided by simply setting  
max_l3_agents_per_router=0, but for current case is it possible to have a 
solution?

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: l3-ha

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

Title:
  HA router schedule for another active agent

Status in neutron:
  New

Bug description:
  Neutron Liberty, Ubuntu 14.04

  3 controllers(3 l3-agents are available and active.), 1 compute

  I have max_l3_agents_per_router=2, router is scheduled to 2 agents. If
  you of one these agents is stopped I will have something like:

  root@node-1:~# neutron l3-agent-list-hosting-router r3
  
+--+---++---+--+
  | id   | host  | admin_state_up | 
alive | ha_state |
  
+--+---++---+--+
  | 1fa93569-fc36-4fb4-b467-85b11ba5f20c | node-3.domain.tld | True   | 
xxx   | active   |
  | 709998f7-cc64-4b6a-9777-6c815dfebb5c | node-2.domain.tld | True   | 
:-)   | active   |
  
+--+---++---+--+

  
  The point is: router won't be rescheduled from dead agent and scheduled for 
another available active one. This situation can be avoided by simply setting  
max_l3_agents_per_router=0, but for current case is it possible to have a 
solution?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1511732/+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 1505701] [NEW] HEAD files are needed for conflict management

2015-10-13 Thread Ann Kamyshnikova
Public bug reported:

Some time ago we merged change https://review.openstack.org/#/c/227319/
that removes HEADS file. Validation of migration revisions using HEADS
file was replaced with pep8. This allows us to avoid merge conflicts
that appeared every time a new migration was merged.

The problem is that the original idea of HEAD file was not only to
validate revisions, so as not to allow outdated changes go into merge
queue, that could be very important for the end of the cycle when a lot
of patches get approved.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

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

Title:
  HEAD files are needed for conflict management

Status in neutron:
  New

Bug description:
  Some time ago we merged change
  https://review.openstack.org/#/c/227319/ that removes HEADS file.
  Validation of migration revisions using HEADS file was replaced with
  pep8. This allows us to avoid merge conflicts that appeared every time
  a new migration was merged.

  The problem is that the original idea of HEAD file was not only to
  validate revisions, so as not to allow outdated changes go into merge
  queue, that could be very important for the end of the cycle when a
  lot of patches get approved.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1505701/+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 1501686] [NEW] Incorrect exception handling in DB code involving rollbacked transactions.

2015-10-01 Thread Ann Kamyshnikova
Public bug reported:

I found out that some methods like _create_ha_interfaces
https://github.com/openstack/neutron/blob/master/neutron/db/l3_hamode_db.py#L329-L345
contain the following logic:

def create():
  create_something()
  try:
_do_other_thing()
  except Exception:
 with excutils.save_and_reraise_exception():
 delete_something()

def  _do_other_thing():
 with context.session.begin(subtransactions=True):
 


The problem is that when exception is raised in _do_other_thing it is caught in 
except block, but the object cannot be deleted in except section because 
internal transaction has been rolled back. We have tests on these methods, but 
they also are not correct (for example 
https://github.com/openstack/neutron/blob/master/neutron/tests/unit/db/test_l3_hamode_db.py#L360-L377)
 as methods  _do_other_thing() are mocked so inside transaction is never 
created and aborted.

The possible solution is to use nested transaction in such places like
this:

def create()
   with context.session.begin(subtransactions=True):
   create_something()
   try:
   _do_other_thing()
   except Exception:
   with excutils.save_and_reraise_exception():
   delete_something()

def _do_other_thing():
 with context.session.begin(nested=True):
 

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

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

Title:
  Incorrect exception handling in DB code involving rollbacked
  transactions.

Status in neutron:
  New

Bug description:
  I found out that some methods like _create_ha_interfaces
  
https://github.com/openstack/neutron/blob/master/neutron/db/l3_hamode_db.py#L329-L345
  contain the following logic:

  def create():
create_something()
try:
  _do_other_thing()
except Exception:
   with excutils.save_and_reraise_exception():
   delete_something()

  def  _do_other_thing():
   with context.session.begin(subtransactions=True):
   

  
  The problem is that when exception is raised in _do_other_thing it is caught 
in except block, but the object cannot be deleted in except section because 
internal transaction has been rolled back. We have tests on these methods, but 
they also are not correct (for example 
https://github.com/openstack/neutron/blob/master/neutron/tests/unit/db/test_l3_hamode_db.py#L360-L377)
 as methods  _do_other_thing() are mocked so inside transaction is never 
created and aborted.

  The possible solution is to use nested transaction in such places like
  this:

  def create()
 with context.session.begin(subtransactions=True):
 create_something()
 try:
 _do_other_thing()
 except Exception:
 with excutils.save_and_reraise_exception():
 delete_something()

  def _do_other_thing():
   with context.session.begin(nested=True):
   

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1501686/+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 1241577] Re: sqlalchemy.exc.OperationalError: (OperationalError) Cannot add a NOT NULL column with default value NULL

2015-09-29 Thread Ann Kamyshnikova
This problem is invalid for master branch, so for juno, kilo, liberty
branches.

** 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/1241577

Title:
  sqlalchemy.exc.OperationalError: (OperationalError) Cannot add a NOT
  NULL column with default value NULL

Status in neutron:
  Invalid
Status in neutron icehouse series:
  Fix Released

Bug description:
  As per this piupart failure report:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726719

  there's a problem with alembic migration with SQLite.

  INFO  [alembic.migration] Context impl SQLiteImpl.
INFO  [alembic.migration] Will assume transactional DDL.
INFO  [alembic.migration] Running upgrade None -> folsom
INFO  [alembic.migration] Running upgrade folsom -> 2c4af419145b
INFO  [alembic.migration] Running upgrade 2c4af419145b -> 5a875d0e5c
INFO  [alembic.migration] Running upgrade 5a875d0e5c -> 48b6f43f7471
INFO  [alembic.migration] Running upgrade 48b6f43f7471 -> 3cb5d900c5de
INFO  [alembic.migration] Running upgrade 3cb5d900c5de -> 1d76643bcec4
INFO  [alembic.migration] Running upgrade 1d76643bcec4 -> 2a6d0b51f4bb
INFO  [alembic.migration] Running upgrade 2a6d0b51f4bb -> 1b693c095aa3
INFO  [alembic.migration] Running upgrade 1b693c095aa3 -> 1149d7de0cfa
INFO  [alembic.migration] Running upgrade 1149d7de0cfa -> 49332180ca96
INFO  [alembic.migration] Running upgrade 49332180ca96 -> 38335592a0dc
INFO  [alembic.migration] Running upgrade 38335592a0dc -> 54c2c487e913
INFO  [alembic.migration] Running upgrade 54c2c487e913 -> 45680af419f9
INFO  [alembic.migration] Running upgrade 45680af419f9 -> 1c33fa3cd1a1
INFO  [alembic.migration] Running upgrade 1c33fa3cd1a1 -> 363468ac592c
INFO  [alembic.migration] Running upgrade 363468ac592c -> 511471cc46b
INFO  [alembic.migration] Running upgrade 511471cc46b -> 3b54bf9e29f7
INFO  [alembic.migration] Running upgrade 3b54bf9e29f7 -> 4692d074d587
INFO  [alembic.migration] Running upgrade 4692d074d587 -> 1341ed32cc1e
INFO  [alembic.migration] Running upgrade 1341ed32cc1e -> grizzly
INFO  [alembic.migration] Running upgrade grizzly -> f489cf14a79c
INFO  [alembic.migration] Running upgrade f489cf14a79c -> 176a85fc7d79
INFO  [alembic.migration] Running upgrade 176a85fc7d79 -> 32b517556ec9
INFO  [alembic.migration] Running upgrade 32b517556ec9 -> 128e042a2b68
Traceback (most recent call last):
  File "/usr/bin/neutron-db-manage", line 10, in 
sys.exit(main())
  File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
143, in main
CONF.command.func(config, CONF.command.name)
  File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
80, in do_upgrade_downgrade
do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
  File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
59, in do_alembic_command
getattr(alembic_command, cmd)(config, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/alembic/command.py", line 124, in 
upgrade
script.run_env()
  File "/usr/lib/python2.7/dist-packages/alembic/script.py", line 191, in 
run_env
util.load_python_file(self.dir, 'env.py')
  File "/usr/lib/python2.7/dist-packages/alembic/util.py", line 186, in 
load_python_file
module = imp.load_source(module_id, path, open(path, 'rb'))
  File 
"/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py",
 line 105, in 
run_migrations_online()
  File 
"/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py",
 line 89, in run_migrations_online
options=build_options())
  File "", line 7, in run_migrations
  File "/usr/lib/python2.7/dist-packages/alembic/environment.py", line 494, 
in run_migrations
self.get_context().run_migrations(**kw)
  File "/usr/lib/python2.7/dist-packages/alembic/migration.py", line 211, 
in run_migrations
change(**kw)
  File 
"/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/versions/128e042a2b68_ext_gw_mode.py",
 line 55, in upgrade
nullable=False, default=True))
  File "", line 7, in add_column
  File "/usr/lib/python2.7/dist-packages/alembic/operations.py", line 342, 
in add_column
schema=schema
  File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 126, in 
add_column
self._exec(base.AddColumn(table_name, column, schema=schema))
  File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 75, in 
_exec
conn.execute(construct, *multiparams, **params)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 
662, in execute
params)
  File "/usr/lib/python2.7/dist-packages/sqlalche

[Yahoo-eng-team] [Bug 1499647] [NEW] L3 HA: extra L3HARouterAgentPortBinding created for routers

2015-09-25 Thread Ann Kamyshnikova
Public bug reported:

I have tested work of L3 HA on environment with 3 controllers and 1
compute (Kilo) keepalived v1.2.13 I create 50 nets with 50 subnets and
50 routers with interface is set for each subnet(Note: I've seem the
same errors with just one router and net). I've got the following
errors:

root@node-6:~# neutron l3-agent-list-hosting-router router-1
Request Failed: internal server error while processing your request.
 
In neutron-server error log:  http://paste.openstack.org/show/473760/

When I fixed _get_agents_dict_for_router to skip None for further
testing, so then I was able to see:

root@node-6:~# neutron l3-agent-list-hosting-router router-1
+--+---++---+--+
| id   | host  | admin_state_up | 
alive | ha_state |
+--+---++---+--+
| f3baba98-ef5d-41f8-8c74-a91b7016ba62 | node-6.domain.tld | True   | 
:-)   | active   |
| c9159f09-34d4-404f-b46c-a8c18df677f3 | node-7.domain.tld | True   | 
:-)   | standby  |
| b458ab49-c294-4bdb-91bf-ae375d87ff20 | node-8.domain.tld | True   | 
:-)   | standby  |
| f3baba98-ef5d-41f8-8c74-a91b7016ba62 | node-6.domain.tld | True   | 
:-)   | active   |
+--+---++---+--+

root@node-6:~# neutron port-list 
--device_id=fcf150c0-f690-4265-974d-8db370e345c4
+--+-+---++
| id   | name   
 | mac_address   | fixed_ips
  |
+--+-+---++
| 0834f8a2-f109-4060-9312-edebac84aba5 |
 | fa:16:3e:73:9f:33 | {"subnet_id": 
"0c7a2cfa-1cfd-4ecc-a196-ab9e97139352", "ip_address": "172.18.161.223"}  |
| 2b5a7a15-98a2-4ff1-9128-67d098fa3439 | HA port tenant 
aef8d13bad9d42df9f25d8ee54c80ad6 | fa:16:3e:b8:f6:35 | {"subnet_id": 
"1915ccb8-9d0f-4f1a-9811-9a196d1e495e", "ip_address": "169.254.192.149"} |
| 48c887c1-acc3-4804-a993-b99060fa2c75 | HA port tenant 
aef8d13bad9d42df9f25d8ee54c80ad6 | fa:16:3e:e7:70:13 | {"subnet_id": 
"1915ccb8-9d0f-4f1a-9811-9a196d1e495e", "ip_address": "169.254.192.151"} |
| 82ab62d6-7dd1-4294-a0dc-f5ebfbcbb4ca |
 | fa:16:3e:c6:fc:74 | {"subnet_id": 
"c4cc21c9-3b3a-407c-b4a7-b22f783377e7", "ip_address": "10.0.40.1"}   |
| bbca8575-51f1-4b42-b074-96e15aeda420 | HA port tenant 
aef8d13bad9d42df9f25d8ee54c80ad6 | fa:16:3e:84:4c:fc | {"subnet_id": 
"1915ccb8-9d0f-4f1a-9811-9a196d1e495e", "ip_address": "169.254.192.150"} |
| bee5c6d4-7e0a-4510-bb19-2ef9d60b9faf | HA port tenant 
aef8d13bad9d42df9f25d8ee54c80ad6 | fa:16:3e:09:a1:ae | {"subnet_id": 
"1915ccb8-9d0f-4f1a-9811-9a196d1e495e", "ip_address": "169.254.193.11"}  |
| f8945a1d-b359-4c36-a8f8-e78c1ba992f0 | HA port tenant 
aef8d13bad9d42df9f25d8ee54c80ad6 | fa:16:3e:c4:54:b5 | {"subnet_id": 
"1915ccb8-9d0f-4f1a-9811-9a196d1e495e", "ip_address": "169.254.193.12"}  |
+--+-+---++
mysql root@192.168.0.2:neutron> SELECT * FROM ha_router_agent_port_bindings 
WHERE router_id='fcf150c0-f690-4265-974d-8db370e345c4';
+--+--+--+-+
| port_id  | router_id| 
l3_agent_id  | state   |
|--+--+--+-|
| 2b5a7a15-98a2-4ff1-9128-67d098fa3439 | fcf150c0-f690-4265-974d-8db370e345c4 | 
c9159f09-34d4-404f-b46c-a8c18df677f3 | standby |
| 48c887c1-acc3-4804-a993-b99060fa2c75 | fcf150c0-f690-4265-974d-8db370e345c4 | 
b458ab49-c294-4bdb-91bf-ae375d87ff20 | standby |
| bbca8575-51f1-4b42-b074-96e15aeda420 | fcf150c0-f690-4265-974d-8db370e345c4 | 
   | standby |
| bee5c6d4-7e0a-4510-bb19-2ef9d60b9faf | fcf150c0-f690-4265-974d-8db370e345c4 | 
f3baba98-ef5d-41f8-8c74-a91b7016ba62 | active  |
| f8945a1d-b359-4c36-a8f8-e78c1ba992f0 | fcf150c0-f690-4265-974d-8db370e345c4 | 
f3baba98-ef5d-41f8-8c74-a91b7016ba62 | active  |
+--+--+--

[Yahoo-eng-team] [Bug 1497272] [NEW] L3 HA: Unstable rescheduling time

2015-09-18 Thread Ann Kamyshnikova
Public bug reported:

I have tested work of L3 HA on environment with 3 controllers and 1 compute 
(Kilo) with this simple scenario:
1) ping vm by floating ip
2) disable master l3-agent (which ha_state is active)
3) wait for pings to continue and another agent became active
4) check number of packages that were lost

My results are  following:
1) When max_l3_agents_per_router=2, 3 to 4 packages were lost.
2) When max_l3_agents_per_router=3 or 0 (meaning the router will be scheduled 
on every agent), 10 to 70 packages were lost.

I should mention that in both cases there was only one ha router.

It is expected that less packages will be lost when
max_l3_agents_per_router=3(0).

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ha

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

Title:
  L3 HA: Unstable rescheduling time

Status in neutron:
  New

Bug description:
  I have tested work of L3 HA on environment with 3 controllers and 1 compute 
(Kilo) with this simple scenario:
  1) ping vm by floating ip
  2) disable master l3-agent (which ha_state is active)
  3) wait for pings to continue and another agent became active
  4) check number of packages that were lost

  My results are  following:
  1) When max_l3_agents_per_router=2, 3 to 4 packages were lost.
  2) When max_l3_agents_per_router=3 or 0 (meaning the router will be scheduled 
on every agent), 10 to 70 packages were lost.

  I should mention that in both cases there was only one ha router.

  It is expected that less packages will be lost when
  max_l3_agents_per_router=3(0).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1497272/+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 1416813] Re: default security group table's name is in singular format

2015-09-04 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: In Progress => Opinion

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

Title:
  default security group table's name is in singular format

Status in neutron:
  Opinion

Bug description:
  In general, the tables' name is in plular format, but the default
  security group table's name is singular one

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1416813/+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 1464825] Re: alembic migration script for vpnaas error

2015-09-04 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: Incomplete => 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/1464825

Title:
  alembic migration script for vpnaas error

Status in neutron:
  Invalid

Bug description:
  
  5689aa52_fix_identifier_map_fk.py alembic migration script error 'Cannot 
change column 'ipsec_site_conn_id': used in a foreign key constraint 
'cisco_csr_identifier_map_ibfk_1'


  + /usr/bin/neutron-db-manage --service vpnaas --config-file 
/etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini 
upgrade head
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  INFO  [alembic.migration] Running upgrade  -> start_neutron_vpnaas, start 
neutron-vpnaas chain
  INFO  [alembic.migration] Running upgrade start_neutron_vpnaas -> 
3ea02b2a773e, add_index_tenant_id
  INFO  [alembic.migration] Running upgrade 3ea02b2a773e -> kilo, kilo
  INFO  [alembic.migration] Running upgrade kilo -> 5689aa52, fix 
identifier map fk
  Traceback (most recent call last):
File "/usr/bin/neutron-db-manage", line 10, in 
  sys.exit(main())
File "/opt/stack/neutron/neutron/db/migration/cli.py", line 238, in main
  CONF.command.func(config, CONF.command.name)
File "/opt/stack/neutron/neutron/db/migration/cli.py", line 106, in 
do_upgrade
  do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
File "/opt/stack/neutron/neutron/db/migration/cli.py", line 72, in 
do_alembic_command
  getattr(alembic_command, cmd)(config, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/alembic/command.py", line 165, in 
upgrade
  script.run_env()
File "/usr/lib/python2.7/site-packages/alembic/script.py", line 390, in 
run_env
  util.load_python_file(self.dir, 'env.py')
File "/usr/lib/python2.7/site-packages/alembic/util.py", line 243, in 
load_python_file
  module = load_module_py(module_id, path)
File "/usr/lib/python2.7/site-packages/alembic/compat.py", line 79, in 
load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py",
 line 86, in 
  run_migrations_online()
File 
"/opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py",
 line 77, in run_migrations_online
  context.run_migrations()
File "", line 7, in run_migrations
File "/usr/lib/python2.7/site-packages/alembic/environment.py", line 738, 
in run_migrations
  self.get_context().run_migrations(**kw)
File "/usr/lib/python2.7/site-packages/alembic/migration.py", line 309, in 
run_migrations
  step.migration_fn(**kw)
File 
"/opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/versions/5689aa52_fix_identifier_map_fk.py",
 line 48, in upgrade
  existing_nullable=True)
File "", line 7, in alter_column
File "", line 1, in 
File "/usr/lib/python2.7/site-packages/alembic/util.py", line 388, in go
  return fn(*arg, **kw)
File "/usr/lib/python2.7/site-packages/alembic/operations.py", line 478, in 
alter_column
  existing_autoincrement=existing_autoincrement
File "/usr/lib/python2.7/site-packages/alembic/ddl/mysql.py", line 65, in 
alter_column
  else existing_autoincrement
File "/usr/lib/python2.7/site-packages/alembic/ddl/impl.py", line 122, in 
_exec
  return conn.execute(construct, *multiparams, **params)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
841, in execute
  return meth(self, multiparams, params)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/ddl.py", line 69, 
in _execute_on_connection
  return connection._execute_ddl(self, multiparams, params)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
895, in _execute_ddl
  compiled
File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1070, in _execute_context
  context)
File 
"/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/compat/handle_error.py", 
line 155, in _handle_dbapi_exception
  e, statement, parameters, cursor, context)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1267, in _handle_dbapi_exception
  util.raise_from_cause(newraise, exc_info)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 
199, in raise_from_cause
  reraise(type(exception), exception, tb=exc_tb)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 
1063, in _execute_context
  context)
File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", 
line 442, in do_execute
  cursor.execute(statement, parameters)

[Yahoo-eng-team] [Bug 1486077] Re: VPNAAS: dsvm-functional doesn't have installed database backends

2015-08-20 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: Confirmed => 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/1486077

Title:
  VPNAAS: dsvm-functional doesn't have installed database backends

Status in neutron:
  Invalid

Bug description:
  During the work on implementing ModelMigrationsSyncTest for vpnaas it
  came up that dsvm-functional in gate does not have mysql and
  postgresql backends installed -
  http://paste.openstack.org/show/420551/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486077/+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 1486077] [NEW] VPNAAS: dsvm-functional doesn't have installed database backends

2015-08-18 Thread Ann Kamyshnikova
Public bug reported:

During the work on implementing ModelMigrationsSyncTest for vpnaas it
came up that dsvm-functional in gate does not have mysql and postgresql
backends installed - http://paste.openstack.org/show/420551/.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: db vpnaas

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

Title:
  VPNAAS: dsvm-functional doesn't have installed database backends

Status in neutron:
  New

Bug description:
  During the work on implementing ModelMigrationsSyncTest for vpnaas it
  came up that dsvm-functional in gate does not have mysql and
  postgresql backends installed -
  http://paste.openstack.org/show/420551/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1486077/+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 1484965] Re: VPNAAS: Missing model of cisco_csr_identifier_map table

2015-08-14 Thread Ann Kamyshnikova
Missing this model in
neutron_vpnaas/services/vpn/service_drivers/cisco_csr_db.py

** Changed in: neutron
   Status: New => Invalid

** Changed in: neutron
 Assignee: Ann Kamyshnikova (akamyshnikova) => (unassigned)

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

Title:
  VPNAAS: Missing model of cisco_csr_identifier_map table

Status in neutron:
  Invalid

Bug description:
  In Neutron in file external.py  the list of vnpaas external tables
  contains  'cisco_csr_identifier_map,' but model of this table is
  absent in vpn models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1484965/+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 1484965] [NEW] VPNAAS: Missing model of cisco_csr_identifier_map table

2015-08-14 Thread Ann Kamyshnikova
Public bug reported:

In Neutron in file external.py  the list of vnpaas external tables
contains  'cisco_csr_identifier_map,' but model of this table is absent
in vpn models.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: vpnaas

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

Title:
  VPNAAS: Missing model of cisco_csr_identifier_map table

Status in neutron:
  New

Bug description:
  In Neutron in file external.py  the list of vnpaas external tables
  contains  'cisco_csr_identifier_map,' but model of this table is
  absent in vpn models.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1484965/+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 1463301] [NEW] Migration 589f9237ca0e failed during upgrade on PostgreSQL

2015-06-09 Thread Ann Kamyshnikova
Public bug reported:

PostgreSQL is more sensitive with types then MySQL, so it creates
separate type when a Enum is created. In migration 589f9237ca0e type
profile_type is trying to be created, but the type with such name was
already created in havana_initial migration.

Trace with exception: http://paste.openstack.org/show/276962/

Steps to reproduce:
 
1. neutron-db-manage ... upgrade juno
2. neutron-db-manage ... upgrade head

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Migration 589f9237ca0e failed during upgrade on PostgreSQL

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  PostgreSQL is more sensitive with types then MySQL, so it creates
  separate type when a Enum is created. In migration 589f9237ca0e type
  profile_type is trying to be created, but the type with such name was
  already created in havana_initial migration.

  Trace with exception: http://paste.openstack.org/show/276962/

  Steps to reproduce:
   
  1. neutron-db-manage ... upgrade juno
  2. neutron-db-manage ... upgrade head

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1463301/+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 1461103] [NEW] Creation of juno_initial migration is required

2015-06-02 Thread Ann Kamyshnikova
Public bug reported:

havana is deprecated now, so havana_inital migration should be removed
and replaced with juno_initial.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Summary changed:

- Creation of juno_initial migration required
+ Creation of juno_initial migration is required

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Creation of juno_initial migration is required

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  havana is deprecated now, so havana_inital migration should be removed
  and replaced with juno_initial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1461103/+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 1349345] Re: Neutron does not contain checks for running migration upgrade->downgrade->upgrade

2015-04-15 Thread Ann Kamyshnikova
This is not valid bug now as we do not have downgrades in migrations.

** Changed in: neutron
   Status: In Progress => Invalid

** Changed in: neutron
 Assignee: Ann Kamyshnikova (akamyshnikova) => (unassigned)

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

Title:
  Neutron does not contain checks for running migration
  upgrade->downgrade->upgrade

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Big number of existing migrations had problems with downgrade, because
  developers forgot to test this. To make it easier a test should be
  created that will run each migration through
  upgrade->downgrade->upgrade.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1349345/+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 1405317] Re: Could not find a version that satisfies the requirement SQLAlchemy

2015-04-07 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: Confirmed => 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/1405317

Title:
  Could not find a version that satisfies the requirement SQLAlchemy

Status in devstack - openstack dev environments:
  Invalid
Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  On Ubunttu 14.04.01 LTS while installing Keystone 2014.2 get a SQLAlchemy 
version mismatch.
  The version using python import sqlalchmemy shows version as '0.9.8' but can 
not loccte where in devstack this needs fixing like one was able to do in 
~devstack/tools/fixup_stuff.sh for similar problem in prettytables by changing  
  pip_install 'prettytable>0.7' to pip_install 'prettytable>=0.7', when it 
worked for prettytable. (one might fix this too besides one I need for 
SQLAlchemy.


  2014-12-24 00:57:31.580 | Requirement already satisfied (use --upgrade to 
upgrade): Paste in /usr/lib/python2.7/dist-packages (from keystone==2014.2)
  2014-12-24 00:57:31.580 | Requirement already satisfied (use --upgrade to 
upgrade): Routes!=2.0,>=1.12.3 in /usr/local/lib/python2.7/dist-packages (from 
keystone==2014.2)
  2014-12-24 00:57:31.581 | Requirement already satisfied (use --upgrade to 
upgrade): six>=1.7.0 in /usr/local/lib/python2.7/dist-packages (from 
keystone==2014.2)
  2014-12-24 00:57:31.582 | Collecting 
SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from keystone==2014.2)
  2014-12-24 00:57:36.794 |   Could not find a version that satisfies the 
requirement SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from keystone==2014.2) 
(from versions: 0.4.2p3, 0.4.7p1, 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 
0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 
0.2.7, 0.2.8, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 
0.3.9, 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6, 
0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.7, 
0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3, 0.5.0rc4, 
0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7, 0.5.8, 0.6b1, 0.6b2, 
0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.6.7, 0.6.8, 0.6.9, 
0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 
0.8.0b2, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 
0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8)
  2014-12-24 00:57:36.796 |   No distributions matching the version for 
SQLAlchemy<=0.8.99,<=0.9.99,>=0.8.4,>=0.9.7 (from keystone==2014.2)
  2014-12-24 00:57:36.815 | + exit_trap
  2014-12-24 00:57:36.815 | + local r=1
  2014-12-24 00:57:36.816 | ++ jobs -p
  2014-12-24 00:57:36.816 | + jobs=
  2014-12-24 00:57:36.816 | + [[ -n '' ]]
  2014-12-24 00:57:36.817 | + kill_spinner
  2014-12-24 00:57:36.817 | + '[' '!' -z '' ']'
  2014-12-24 00:57:36.817 | + [[ 1 -ne 0 ]]
  2014-12-24 00:57:36.817 | + echo 'Error on exit'
  2014-12-24 00:57:36.817 | Error on exit
  2014-12-24 00:57:36.817 | + [[ -z /opt/stack/logs ]]
  2014-12-24 00:57:36.817 | + /home/epc/juno/stable/devstack/tools/worlddump.py 
-d /opt/stack/logs
  2014-12-24 00:57:36.869 | + exit 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1405317/+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 1440761] [NEW] l3 agent can be marked dead while it reschedules a lot of resources

2015-04-06 Thread Ann Kamyshnikova
Public bug reported:

If l3 agent get killed and there are a lot of resources assigned on it,
the agent on which this resources are rescheduling can be marked as dead
for neutron-server because state reports are not received in
agent_down_time*2.

This was tested with agent_down_time=15 and 100 routers for
rescheduling.

** Affects: neutron
 Importance: Low
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: Confirmed


** Tags: l3-ipam-dhcp

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  l3 agent can be marked dead while it reschedules a lot of resources

Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  If l3 agent get killed and there are a lot of resources assigned on
  it, the agent on which this resources are rescheduling can be marked
  as dead for neutron-server because state reports are not received in
  agent_down_time*2.

  This was tested with agent_down_time=15 and 100 routers for
  rescheduling.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1440761/+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 1434601] [NEW] Incorrect usage default in migration 1955efc66455

2015-03-20 Thread Ann Kamyshnikova
Public bug reported:

Migration 1955efc66455_weight_scheduler adds column with  'default'
parameter. 'default' is useless in migration, to provide default value
in db should be used server_default instead.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Incorrect usage default in migration 1955efc66455

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Migration 1955efc66455_weight_scheduler adds column with  'default'
  parameter. 'default' is useless in migration, to provide default value
  in db should be used server_default instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1434601/+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 1426383] [NEW] Listing security-groups takes long time

2015-02-27 Thread Ann Kamyshnikova
Public bug reported:

If we have a large number of security groups (more than 1000) with
security group rules (about 100 for each group) listing them could take
rather long time(more than 1 minute). Analysis shows that listing can be
made on 15% faster(with larger number of security  groups can be 2-3
times faster) by adding lazy join to backref to SecurityGroupRule model.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db juno-backport-potential

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Listing security-groups takes long time

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If we have a large number of security groups (more than 1000) with
  security group rules (about 100 for each group) listing them could
  take rather long time(more than 1 minute). Analysis shows that listing
  can be made on 15% faster(with larger number of security  groups can
  be 2-3 times faster) by adding lazy join to backref to
  SecurityGroupRule model.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1426383/+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 1423168] Re: no error when adding an already-associated security group to a running instance

2015-02-19 Thread Ann Kamyshnikova
Not a neutron bug.

** Changed in: neutron
 Assignee: Ann Kamyshnikova (akamyshnikova) => (unassigned)

** Project changed: neutron => nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1423168

Title:
  no error when adding an already-associated security group to a running
  instance

Status in OpenStack Compute (Nova):
  New

Bug description:
  I don't get any error message when I try to associate VM to security
  group when it already assigned to this  security group .

  version : 
  [root@puma15 ~(keystone_admin)]# rpm -qa | grep neu
  python-neutron-2014.2.2-2.el7ost.noarch
  openstack-neutron-openvswitch-2014.2.2-2.el7ost.noarch
  openstack-neutron-2014.2.2-2.el7ost.noarch
  openstack-neutron-ml2-2014.2.2-2.el7ost.noarch
  python-neutronclient-2.3.9-1.el7ost.noarch
  [root@puma15 ~(keystone_admin)]# rpm -qa | grep rhel 
  libreport-rhel-2.1.11-21.el7.x86_64
   rhos-release-6-rhel-7.1.repo

  1. List the security groups associated with your running instance
   
  [root@puma15 neutron(keystone_admin)]# neutron security-group-list 
  
+--+--+--+
  | id   | name | description   
   |
  
+--+--+--+
  | 09600aa9-e220-4a4c-a905-6db9c91d968b | sec_test | will associate to testing 
VM |
  | 19dfccd3-2c47-41a7-9227-d0fdc4a7284f | default  | default   
   |
  | ef948932-65e8-4939-b485-6c80bd0b7b9c | default  | default   
   |
  
+--+--+--+
   
  [root@puma15 neutron(keystone_admin)]# nova show 
29eeb6ab-55d9-421f-b530-a9a2d5f6dc75 |grep security_group 
  | security_groups  | default  
|
   
  2. Create a new security group
  $ neutron security-group-create test3 --description "will be associated to a 
testing instance twice"
  [root@puma15 neutron(keystone_admin)]# neutron security-group-list 
  
+--+-++
  | id   | name| description
|
  
+--+-++
  | 19dfccd3-2c47-41a7-9227-d0fdc4a7284f | default | default
|
  | ca017993-79f2-4091-88c5-4b48bf09adaa | test3   | will be associated to a 
testing instance twice |
  | ef948932-65e8-4939-b485-6c80bd0b7b9c | default | default
|
  
+--+-++

  
  3. Associate the newly-created security group to the running instance
  [root@puma15 neutron(keystone_admin)]# nova add-secgroup 
29eeb6ab-55d9-421f-b530-a9a2d5f6dc75 test3
   
  4. Try to associate again the same security group to the same instance
  [root@puma15 neutron(keystone_admin)]# nova add-secgroup 
29eeb6ab-55d9-421f-b530-a9a2d5f6dc75 test3

  Expected error :
  ERROR: Security group 16 is already associated with the instance 
29fe826e-7ff2-488f-9452-5b2e9bfda8b8 (HTTP 400) (Request-ID: 
req-7a216931-c7ec-47b6-a784-ac4b57c648b7)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1423168/+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 1420700] Re: Neutron is accepting same cidr for different subnet creations

2015-02-18 Thread Ann Kamyshnikova
Why is this a bug? Please, give more information

** Changed in: neutron
   Status: New => Incomplete

** Changed in: neutron
   Status: Incomplete => Opinion

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

Title:
  Neutron is accepting same cidr for different subnet creations

Status in OpenStack Neutron (virtual network service):
  Opinion
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The following are the subnets that i have already exists in my setup.

  
+--+---+--+--+
  | id   | name  | cidr 
| allocation_pools |
  
+--+---+--+--+
  | 007ac6ad-7f9a-4f1d-954e-7a0db1db8bef | oldsubnetpricate  | 10.0.0.0/24  
| {"start": "10.0.0.2", "end": "10.0.0.254"}   |
  | 84b8435f-3a95-43ef-abd8-de10b3456f43 | oldsubnetprivate  | 11.0.0.0/24  
| {"start": "11.0.0.2", "end": "11.0.0.254"}   |
  | c584e25a-d2b4-4d48-ada4-7baeaa4788ff | newsubnetpricate  | 12.0.0.0/24  
| {"start": "12.0.0.2", "end": "12.0.0.254"}   |
  
+--+---+--+--+

  Here again i am trying to create a new subnet with same
  cidr(11.0.0.0/24)

  $ neutron net-create dummy

  $ neutron subnet-create dummy --name newsubnetprivate 11.0.0.0/24
  
+--+---+--+--+
  | id   | name  | cidr 
| allocation_pools |
  
+--+---+--+--+
  | 007ac6ad-7f9a-4f1d-954e-7a0db1db8bef | oldsubnetpricate  | 10.0.0.0/24  
| {"start": "10.0.0.2", "end": "10.0.0.254"}   |
  | 84b8435f-3a95-43ef-abd8-de10b3456f43 | oldsubnetprivate  | 11.0.0.0/24  
| {"start": "11.0.0.2", "end": "11.0.0.254"}   |
  | 9319e880-2f9e-4493-88c9-8c81886ca4b3 | newsunetprivate   | 11.0.0.0/24  
| {"start": "11.0.0.2", "end": "11.0.0.254"}   |
  | c584e25a-d2b4-4d48-ada4-7baeaa4788ff | newsubnetpricate  | 12.0.0.0/24  
| {"start": "12.0.0.2", "end": "12.0.0.254"}   |
  
+--+---+--+--+

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1420700/+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 1421631] [NEW] Incorrect usage of drop_constraint in 2a1ee2fb59e0 migration

2015-02-13 Thread Ann Kamyshnikova
Public bug reported:

Downgrade for migration 2a1ee2fb59e0_add_mac_address_unique_constraint
fails as it gets wrong parameters name, source and local_cols, although
it expects name, source and type_
http://alembic.readthedocs.org/en/latest/ops.html#alembic.operations.Operations.drop_constraint

Error - http://paste.openstack.org/show/172906/

Also as MySQL create index for unique constraint  it should be used
"with migration.remove_fks_from_table", as it gets an error  -
http://paste.openstack.org/show/172907/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Incorrect usage of drop_constraint in 2a1ee2fb59e0 migration

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Downgrade for migration 2a1ee2fb59e0_add_mac_address_unique_constraint
  fails as it gets wrong parameters name, source and local_cols,
  although it expects name, source and type_
  
http://alembic.readthedocs.org/en/latest/ops.html#alembic.operations.Operations.drop_constraint

  Error - http://paste.openstack.org/show/172906/

  Also as MySQL create index for unique constraint  it should be used
  "with migration.remove_fks_from_table", as it gets an error  -
  http://paste.openstack.org/show/172907/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1421631/+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 1421618] [NEW] Broken downgrade in 26b54cf9024d migration

2015-02-13 Thread Ann Kamyshnikova
Public bug reported:

In downgrade of migration 26b54cf9024d_add_index_on_allocated is trying
to drop index 'ix_ml2_vxlan_allocations_allocated', which is not exits.

Error - http://paste.openstack.org/show/172847/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Broken downgrade in 26b54cf9024d migration

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  In downgrade of migration 26b54cf9024d_add_index_on_allocated is
  trying to drop index 'ix_ml2_vxlan_allocations_allocated', which is
  not exits.

  Error - http://paste.openstack.org/show/172847/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1421618/+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 1346658] Re: All DB model classes should be consolidated into one directory

2015-02-12 Thread Ann Kamyshnikova
Is this still needed as we have Core and Vendor code decomposition?

** Changed in: neutron
   Status: In Progress => Opinion

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

Title:
  All DB model classes should be consolidated into one directory

Status in OpenStack Neutron (virtual network service):
  Opinion

Bug description:
  We have discussed moving all models out of their current diverse
  locations to one directory, like maybe

neutron/db/models/*.py

  The idea is to move just the model classes (not the entire modules
  that they currently reside in) here. Then head.py would be able to

from neutron.db.models import *  # noqa

  and this would have much less baggage than importing all the current
  modules.

  The convention of putting all models in one directory will be quite
  easy to follow and maintain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1346658/+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 1419815] [NEW] Speed up SELECTs with filters by tenant_id

2015-02-09 Thread Ann Kamyshnikova
Public bug reported:

Adding index on tenant_id could greatly speed up SELECTs with filters by 
tenant_id when some value is selected per resource
per tenant.

Simple example with adding index on securitygrouprules show that speed could 
increase twice.
For  MySQL http://paste.openstack.org/show/169810/
For PostgreSQL http://paste.openstack.org/show/169957/

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: db

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

Title:
  Speed up SELECTs with filters by tenant_id

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Adding index on tenant_id could greatly speed up SELECTs with filters by 
tenant_id when some value is selected per resource
  per tenant.

  Simple example with adding index on securitygrouprules show that speed could 
increase twice.
  For  MySQL http://paste.openstack.org/show/169810/
  For PostgreSQL http://paste.openstack.org/show/169957/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1419815/+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 1419816] [NEW] Speed up SELECTs with filters by tenant_id

2015-02-09 Thread Ann Kamyshnikova
Public bug reported:

Adding index on tenant_id could greatly speed up SELECTs with filters by 
tenant_id when some value is selected per resource
per tenant.

Simple example with adding index on securitygrouprules show that speed could 
increase twice.
For  MySQL http://paste.openstack.org/show/169810/
For PostgreSQL http://paste.openstack.org/show/169957/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Speed up SELECTs with filters by tenant_id

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Adding index on tenant_id could greatly speed up SELECTs with filters by 
tenant_id when some value is selected per resource
  per tenant.

  Simple example with adding index on securitygrouprules show that speed could 
increase twice.
  For  MySQL http://paste.openstack.org/show/169810/
  For PostgreSQL http://paste.openstack.org/show/169957/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1419816/+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 1406253] Re: Updating default security group from non-admin user should raise error

2014-12-30 Thread Ann Kamyshnikova
I also don't see any problem with changing default security group
description  for normal user.

** Changed in: neutron
   Status: New => Opinion

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

Title:
  Updating default security group from non-admin user should raise error

Status in OpenStack Neutron (virtual network service):
  Opinion

Bug description:
  Trying to update default security group from a non-admin user should
  raise an error but the operation succeeds normally. The code should be
  updated so that it raise a conflict while updating default security
  group from a non-admin user.

  Steps to replicate (Running commands from a non-admin user) :-

  1. $ neutron security-group-list
  
+--+-+-+
  | Id| Name
| Description|
  
+--+-+--+
  | 8465d644-cc78-47c6-a699-e14a11ad9f21 | default | Default Security Group  |
  
+--+-+-+

  2. $  neutron security-group-update 8465d644-cc78-47c6-a699-e14a11ad9f21 
--description test
  
+--+-+-+
  | Id| Name
| Description|
  
+--+-+--+
  | 8465d644-cc78-47c6-a699-e14a11ad9f21 | default | test   
   |
  
+--+-+-+

  Hence, a non-admin user is able to update the default security group.

  Expected Result :-

  3. $ neutron security-group-update 8465d644-cc78-47c6-a699-e14a11ad9f21 
--description test
  Conflict (HTTP 409) (Request-ID: req-13b287c5-8ef9-4414-8263-c0c5feee9071)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1406253/+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 1405379] [NEW] DBError: UPDATE statement on table 'ports' expected to update 1 row(s); 0 were matched

2014-12-24 Thread Ann Kamyshnikova
Public bug reported:

For some reason sometimes at the same time for the same port delete_port
and update_device_down commands have been executed. This arise DBError
in update_device_down. In other situations  these commands are executed
one after another and error does't appear.

neutron-server log with trace: http://paste.openstack.org/show/154358/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  DBError: UPDATE statement on table 'ports' expected to update 1
  row(s); 0 were matched

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  For some reason sometimes at the same time for the same port
  delete_port and update_device_down commands have been executed. This
  arise DBError in update_device_down. In other situations  these
  commands are executed one after another and error does't appear.

  neutron-server log with trace: http://paste.openstack.org/show/154358/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1405379/+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 1285841] Re: db migration script should be compatible with neutron.plugins.nicira.nicira_nvp_plugin.NeutronPlugin.NvpPluginV2

2014-12-24 Thread Ann Kamyshnikova
** 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/1285841

Title:
  db migration script should be compatible with
  neutron.plugins.nicira.nicira_nvp_plugin.NeutronPlugin.NvpPluginV2

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  The port creation in NS X fail with following error. This is in latest
  HEAD 2014.1.a913.g9ca7116. Looks like the port UUID is not compatible
  with RFC 4122.

  2014-02-27 18:59:27,308 (neutron.plugins.nicira.api_client.client): ERROR 
client request Received error code: 400
  2014-02-27 18:59:27,309 (neutron.plugins.nicira.api_client.client): ERROR 
client request Server Error Message: 
LogicalSwitchPortConfig.security_profiles.$item.0: 
LogicalSwitchPortConfig.security_profiles.$arrayitems: must be an RFC 4122 UUID
  2014-02-27 18:59:27,313 (NeutronPlugin): ERROR NeutronPlugin 
_handle_create_port_exception An exception occurred while creating the quantum 
port 902c6e49-2d41-4cb7-9cf7-cc1
  64b57bd17 on the NVP plaform
  Traceback (most recent call last):
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 465, in _nvp_create_port
  True)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 426, in _nvp_create_port_helper
  port_data.get(addr_pair.ADDRESS_PAIRS))
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/nsxlib/switch.py",
 line 348, in create_lport
  cluster=cluster)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/nvplib.py",
 line 135, in do_request
  res = cluster.api_client.request(*args)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/api_client/client.py",
 line 119, in request
  exception.ERROR_MAPPINGS[status](response)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/api_client/exception.py",
 line 91, in zero
  raise NsxApiException()
  NsxApiException: An unknown exception occurred.
  2014-02-27 18:59:27,314 (NeutronPlugin): ERROR NeutronPlugin create_port 
Unable to create port or set port attachment in NVP.
  2014-02-27 18:59:27,339 (neutron.db.db_base_plugin_v2): DEBUG 
db_base_plugin_v2 _delete_ip_allocation Delete allocated IP 17.177.36.209 
(1f740648-85c5-4081-a04d-bba6a3eb6ec
  f/66ebd803-21d2-4cdf-a336-61dd421589d4)
  2014-02-27 18:59:27,373 (neutron.api.v2.resource): ERROR resource resource 
create failed
  Traceback (most recent call last):
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/api/v2/resource.py",
 line 84, in resource
  result = method(request=request, **args)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/api/v2/base.py",
 line 411, in create
  obj = obj_creator(request.context, **kwargs)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 1207, in create_port
  self._delete_port(context, neutron_port_id)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/openstack/common/excutils.py",
 line 68, in __exit__
  six.reraise(self.type_, self.value, self.tb)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 1191, in create_port
  port_create_func(context, port_data)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 480, in _nvp_create_port
  lport and lport['uuid'])
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 442, in _handle_create_port_exception
  LOG.exception(msg)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/openstack/common/excutils.py",
 line 68, in __exit__
  six.reraise(self.type_, self.value, self.tb)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 465, in _nvp_create_port
  True)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/NeutronPlugin.py",
 line 426, in _nvp_create_port_helper
  port_data.get(addr_pair.ADDRESS_PAIRS))
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/nsxlib/switch.py",
 line 348, in create_lport
  cluster=cluster)
File 
"/usr/local/csi/share/csi-neutron.venv/lib/python2.6/site-packages/neutron/plugins/nicira/nvplib.py",
 line 135, in do_request
  res = cluster.api_clie

[Yahoo-eng-team] [Bug 1404093] Re: Use of *OpportunisticTestCase causes functional tests to skip on db error

2014-12-19 Thread Ann Kamyshnikova
I'm not sure that this is a neutron bug as skip is in test_base in
oslo.db
https://github.com/openstack/oslo.db/blob/master/oslo/db/sqlalchemy/test_base.py#L61,
but at the same time I have doubts that in oslo it will be changed as
this test is used as unittest in other components. I will add oslo.db as
affected project and look forward comments from oslo.db developers.

** Project changed: neutron => oslo.db

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

Title:
  Use of *OpportunisticTestCase causes functional tests to skip on db
  error

Status in Oslo Database library:
  New

Bug description:
  Tests using oslo.db.sqlalchemy.test_base.DbFixture will skip if the
  database cannot be provisioned. In the neutron functional job we do
  not want to skip tests. The tests should fail if the environment is
  not set up correctly for the tests.

  After https://review.openstack.org/126175 is merged we should see to
  it that the migrations tests do not skip.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo.db/+bug/1404093/+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 1401424] [NEW] Enable test_migration

2014-12-11 Thread Ann Kamyshnikova
Public bug reported:

After splitting in neutron database was left a number of tables that
don't have any models. Test should be improved to skip this tables from
checking.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Enable test_migration

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  After splitting in neutron database was left a number of tables that
  don't have any models. Test should be improved to skip this tables
  from checking.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1401424/+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 1295443] Re: Handle unicode exception messages

2014-12-03 Thread Ann Kamyshnikova
I've analyzed codebase and came to conclusion that this bug is invalid for 
Neutron. Places where we have str() conversion around exceptions divide into 
two categories:
- where stringified exceptions are checked for equiality with or inclusion of 
literal strings which are of str type in both Python 2.x and 3.x, converting 
them to unicode will only add one more implicit unicode->str conversion step;
- where exceptions are immediately passed as arguments to string formatting 
operator, in these cases explicit str() conversion is not needed since %s 
substitution already does the same conversion.
Both of these cases need no special unicode handling. For the second case I've 
filed a bug here:https://bugs.launchpad.net/neutron/+bug/1398839

** Changed in: neutron
   Status: Triaged => 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/1295443

Title:
  Handle unicode exception messages

Status in Orchestration API (Heat):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  Invalid
Status in Python client library for Neutron:
  In Progress

Bug description:
  There are many places in the code that explicitly ask for byte code
  strings while using exception messages. They should be able to work
  with unicode string and use it in a way that is PY3 compatible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1295443/+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 1398839] [NEW] Avoid unnecessary explicit str() conversion around exceptions

2014-12-03 Thread Ann Kamyshnikova
Public bug reported:

There are number of places like

except Exception as exc:
LOG.error("Failed to get network: %s", str(exc))

where str() is not needed since %s substitution already does the same
conversion.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Avoid unnecessary explicit str() conversion around exceptions

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  There are number of places like

  except Exception as exc:
  LOG.error("Failed to get network: %s", str(exc))

  where str() is not needed since %s substitution already does the same
  conversion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1398839/+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 1308958] Re: Neutron net-list returns all networks for user in multiple tenants

2014-12-01 Thread Ann Kamyshnikova
Seems that wrong command was used to show all networks that belongs to
current tenant. I run

neutron net-list -- --tenant_id TENANT_ID

And it shows correctly only list of networks which belongs to that
tenant.  Flag --os-tenant-id means the authentication tenant ID, it is
not the same as list with filtering on tenant_id. Here is example of
running commands with --debug flag
http://paste.openstack.org/show/142516/. It shows that "neutron --os-
tenant-id TENANT_ID net-list" sends request without specification of
tenant_id and "neutron net-list -- --tenant_id TENANT_ID" specifies it.

** Changed in: neutron
   Status: Confirmed => Opinion

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

Title:
  Neutron net-list returns all networks for user in multiple tenants

Status in OpenStack Neutron (virtual network service):
  Opinion

Bug description:
  I have a user, who belongs to multiple tenants.

  When executing neutron net-list (specifying the tenant id), neutron
  returns all networks for all of the tenants my user belongs to; I
  would expect it to only return the networks for the specified tenant.

  e.g.

  neutron --os-tenant-id 0dc52bffe50d47f7a42674969bd29f3c net-list
  
+--++-+
  | id   | name   | subnets 
|
  
+--++-+
  | 11e304ec-5b67-4980-aa57-da10d0f057a6 | Content| 
3d550793-2da9-4354-9243-0a071a5aa5d8 172.16.0.0/24  |
  | 3942eef0-8fe8-4ec1-aa3b-77a4c40ab1fc | Internal   | 
479785e7-246d-473a-8cb1-4730240342b3 192.168.0.0/24 |
  | 3aed9b6b-387b-4b9d-a9e4-a4bdeab349b7 | Internal   | 
d6ab13ff-2de4-44f9-ac07-b4bb998d2b72 192.168.0.0/24 |
  | 3d4883f9-7b3d-4ef1-a293-419127bc958c | Content| 
22c7d766-ea8b-4e42-9830-82fe8b239b3f 172.16.0.0/24  |
  | 5bab1a18-34fa-400e-a357-cb4d16e4b0b2 | Content| 
aaa60d54-dd84-4a39-9fee-dc928ef1b532 172.16.0.0/24  |
  | 6edaf1b2-bbd1-4ae4-b3a4-faea5ebf3732 | Internal   | 
be944439-ecea-4006-9fca-c4402c461360 192.168.0.0/24 |
  | 71533970-1cb6-415c-9845-0e850f08526b | Internal   | 
c6efc50b-17ba-4dc4-9602-12e4a5dff9a7 192.168.0.0/24 |
  | 937d50a0-c07a-49e5-8d5e-277a21a79a60 | ext_net| 
|
  | 9b3cb15d-099d-4673-97b6-fbcd9181962f | Management | 
0ddb260e-1f30-4def-8304-19733a90c860 10.20.76.0/24  |
  | 9c534554-7d5d-47d8-8305-28af162c9c52 | Content| 
a73f7e75-d1eb-4f96-b25a-ba2d832c7c76 172.16.0.0/24  |
  | a2031601-6a01-4986-b984-98eb0701f393 | Management | 
803a6c01-a78b-47a8-bc51-e4e698283128 10.20.78.0/24  |
  | ac9af807-8205-4649-80c4-962202a6ac8c | Management | 
08650fa9-7fe4-481a-a0ab-357455e658ad 10.20.77.0/24  |
  
+--++-+

  The problem is in a multi-tenant environment, I deploy multiple
  networks with the same names.  This means I cannot look up networks by
  name, but must always use the unique ID.  This makes
  templating/scripting more challenging.

  If I were to execute  'nova --os-tenant-id
  0dc52bffe50d47f7a42674969bd29f3c list' as the same user, this will
  only list the instances in the specified tenant.

  Neutron should behave in the same way.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1308958/+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 1300002] Re: neutron-db-manage does not work properly when using Metaplugin

2014-11-19 Thread Ann Kamyshnikova
** 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/132

Title:
  neutron-db-manage does not work properly when using Metaplugin

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  neutron-db-manage does not create Neutron DB nor upgrade Neutron DB
  properly when using Metaplugin.

  The first cause of this problem is that 'active_plugins' parameter
  passed to migration scripts includes only metaplugin (i.e. not include
  target plugins under metaplugin).

  There some problems even if the first cause is fixed.
  For example there are multiple scripts which handles an same table (off 
course the target plugin for each script is different, but they may be used at 
the same time under metaplugin).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/132/+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 1393691] [NEW] test_migration needs some refactor due to oslo.db 1.1.0 release

2014-11-17 Thread Ann Kamyshnikova
Public bug reported:

test_migration contains some methods like overriding
compare_server_default and compare_foreign_keys that was added directly
in ModelsMigrationsSync class in oslo.db only in 1.1.0.

Also as now migrations refactoring is fully finished,  there is no need
to have separate classes for each plugin.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: unittest

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  test_migration needs some refactor due to oslo.db 1.1.0 release

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  test_migration contains some methods like overriding
  compare_server_default and compare_foreign_keys that was added
  directly in ModelsMigrationsSync class in oslo.db only in 1.1.0.

  Also as now migrations refactoring is fully finished,  there is no
  need to have separate classes for each plugin.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1393691/+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 1337216] Re: Table 'agents' is missing for bigswitch plugin

2014-11-17 Thread Ann Kamyshnikova
** 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/1337216

Title:
  Table 'agents' is missing for bigswitch plugin

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Running migrations for Bigswitch plugin got an error
  http://paste.openstack.org/show/85380/. For creating table
  'networkdhcpagentbindings'  table 'agents' is needed to exist, but
  Bigswitch plugin was not added to the migration_for_plugins list in
  migration 511471cc46b_agent_ext_model_supp.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1337216/+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 1224737] Re: alembic alter_column name arg deprecated

2014-11-17 Thread Ann Kamyshnikova
** 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/1224737

Title:
  alembic alter_column name arg deprecated

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  /usr/local/lib/python2.7/dist-packages/alembic/util.py:272: UserWarning: 
Argument 'name' is now named 'new_column_name' for function 'alter_column'
(oldname, newname, fn.__name__))

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1224737/+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 1388230] Re: Checks for DB models and migrations sync not working

2014-11-05 Thread Ann Kamyshnikova
1) If you run "db-manage revision --autogenerate" on master with
PostgreSQL it won't show any extra changes that are needed
http://paste.openstack.org/show/129531/, but on the MySQL it will show
some extra indexes http://paste.openstack.org/show/129532/. This indexes
is specific of MySQL which creates them with primary keys or foreign
keys. As it was decided earlier this should not be fixed as this dialect
specific (https://review.openstack.org/80518), so test skip this
difference.

2) I'm not sure that alembic have any checks for changing of primary
keys, and if it is so this does't expect to work as both autogenerate
and test rely on alembic with this checks. So, this is not Neutron bug.

** Changed in: neutron
   Status: New => Opinion

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

Title:
  Checks for DB models and migrations sync not working

Status in OpenStack Neutron (virtual network service):
  Opinion

Bug description:
  I noticed a couple of issues, which might be related.

  
  1. "db-manage revision --autogenerate" on master with no code changes 
generates:

  def upgrade():
  op.drop_index('idx_autoinc_vr_id', 
table_name='ha_router_vrid_allocations')

  
  2. With the following change to the IPAllocation() model, the revision is not 
detected. Also, the unit tests for model/migration sync do not give an error.

  diff --git a/neutron/db/models_v2.py b/neutron/db/models_v2.py
  --- a/neutron/db/models_v2.py
  +++ b/neutron/db/models_v2.py
  @@ -98,8 +98,8 @@ class IPAllocation(model_base.BASEV2):
   
   port_id = sa.Column(sa.String(36), sa.ForeignKey('ports.id',
ondelete="CASCADE"),
  -nullable=True)
  -ip_address = sa.Column(sa.String(64), nullable=False, primary_key=True)
  +nullable=True, primary_key=True)
  +ip_address = sa.Column(sa.String(64), nullable=False)
   subnet_id = sa.Column(sa.String(36), sa.ForeignKey('subnets.id',
  ondelete="CASCADE"),
 nullable=False, primary_key=True)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1388230/+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 1384555] Re: Openstack Neutron Database error on filling database

2014-10-24 Thread Ann Kamyshnikova
** Changed in: neutron
   Status: Confirmed => Invalid

** Changed in: neutron
   Status: Invalid => Opinion

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

Title:
  Openstack Neutron Database error on filling database

Status in OpenStack Neutron (virtual network service):
  Opinion
Status in “neutron” package in Ubuntu:
  New

Bug description:
  On a fresh installation of Juno, it seems that that the database is
  not being populated correctly on a fresh install. This is the output
  of the log (I also demonstrated the DB had no tables to begin with):

  MariaDB [(none)]> use neutron
  Database changed
  MariaDB [neutron]> show tables;
  Empty set (0.00 sec)

  MariaDB [neutron]> quit
  Bye
  root@vm-1:~# neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugin.ini current
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  Current revision for mysql://neutron:X@10.10.10.1/neutron: None
  root@vm-1:~# neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugin.ini upgrade head
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  INFO  [alembic.migration] Running upgrade None -> havana, havana_initial
  INFO  [alembic.migration] Running upgrade havana -> e197124d4b9, add unique 
constraint to members
  INFO  [alembic.migration] Running upgrade e197124d4b9 -> 1fcfc149aca4, Add a 
unique constraint on (agent_type, host) columns to prevent a race condition 
when an agent entry is 'upserted'.
  INFO  [alembic.migration] Running upgrade 1fcfc149aca4 -> 50e86cb2637a, 
nsx_mappings
  INFO  [alembic.migration] Running upgrade 50e86cb2637a -> 1421183d533f, NSX 
DHCP/metadata support
  INFO  [alembic.migration] Running upgrade 1421183d533f -> 3d3cb89d84ee, 
nsx_switch_mappings
  INFO  [alembic.migration] Running upgrade 3d3cb89d84ee -> 4ca36cfc898c, 
nsx_router_mappings
  INFO  [alembic.migration] Running upgrade 4ca36cfc898c -> 27cc183af192, 
ml2_vnic_type
  INFO  [alembic.migration] Running upgrade 27cc183af192 -> 50d5ba354c23, ml2 
binding:vif_details
  INFO  [alembic.migration] Running upgrade 50d5ba354c23 -> 157a5d299379, ml2 
binding:profile
  INFO  [alembic.migration] Running upgrade 157a5d299379 -> 3d2585038b95, 
VMware NSX rebranding
  INFO  [alembic.migration] Running upgrade 3d2585038b95 -> abc88c33f74f, lb 
stats
  INFO  [alembic.migration] Running upgrade abc88c33f74f -> 1b2580001654, 
nsx_sec_group_mapping
  INFO  [alembic.migration] Running upgrade 1b2580001654 -> e766b19a3bb, 
nuage_initial
  INFO  [alembic.migration] Running upgrade e766b19a3bb -> 2eeaf963a447, 
floatingip_status
  INFO  [alembic.migration] Running upgrade 2eeaf963a447 -> 492a106273f8, 
Brocade ML2 Mech. Driver
  INFO  [alembic.migration] Running upgrade 492a106273f8 -> 24c7ea5160d7, Cisco 
CSR VPNaaS
  INFO  [alembic.migration] Running upgrade 24c7ea5160d7 -> 81c553f3776c, 
bsn_consistencyhashes
  INFO  [alembic.migration] Running upgrade 81c553f3776c -> 117643811bca, nec: 
delete old ofc mapping tables
  INFO  [alembic.migration] Running upgrade 117643811bca -> 19180cf98af6, 
nsx_gw_devices
  INFO  [alembic.migration] Running upgrade 19180cf98af6 -> 33dd0a9fa487, 
embrane_lbaas_driver
  INFO  [alembic.migration] Running upgrade 33dd0a9fa487 -> 2447ad0e9585, Add 
IPv6 Subnet properties
  INFO  [alembic.migration] Running upgrade 2447ad0e9585 -> 538732fa21e1, NEC 
Rename quantum_id to neutron_id
  INFO  [alembic.migration] Running upgrade 538732fa21e1 -> 5ac1c354a051, n1kv 
segment allocs for cisco n1kv plugin
  INFO  [alembic.migration] Running upgrade 5ac1c354a051 -> icehouse, icehouse
  INFO  [alembic.migration] Running upgrade icehouse -> 54f7549a0e5f, 
set_not_null_peer_address
  INFO  [alembic.migration] Running upgrade 54f7549a0e5f -> 1e5dd1d09b22, 
set_not_null_fields_lb_stats
  INFO  [alembic.migration] Running upgrade 1e5dd1d09b22 -> b65aa907aec, 
set_length_of_protocol_field
  INFO  [alembic.migration] Running upgrade b65aa907aec -> 33c3db036fe4, 
set_length_of_description_field_metering
  INFO  [alembic.migration] Running upgrade 33c3db036fe4 -> 4eca4a84f08a, 
Remove ML2 Cisco Credentials DB
  INFO  [alembic.migration] Running upgrade 4eca4a84f08a -> d06e871c0d5, 
set_admin_state_up_not_null_ml2
  INFO  [alembic.migration] Running upgrade d06e871c0d5 -> 6be312499f9, 
set_not_null_vlan_id_cisco
  INFO  [alembic.migration] Running upgrade 6be312499f9 -> 1b837a7125a9, Cisco 
APIC Mechanism Driver
  INFO  [alembic.migration] Running upgrade 1b837a7125a9 -> 10cd28e692e9, 
nuage_extraroute
  INFO  [alembic.migration] Running upgrade 10cd28e692e9 -> 2db5203cb7a9, 
nuage_floatingip
  INFO  [alembic.migration] Running upgrade 2db5203cb7a9 -> 5446f2a45467, 
set_server_default
  INFO  [alembic.migration] Runn

[Yahoo-eng-team] [Bug 1384555] Re: Openstack Neutron Database error on filling database

2014-10-23 Thread Ann Kamyshnikova
Checked this on MySQL and MariaDB. In both cases this error does not appear.
Logs of running with MariaDB - http://paste.openstack.org/show/123532/. 
I used Juno and master neutron code also, both works fine.

** 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/1384555

Title:
  Openstack Neutron Database error on filling database

Status in OpenStack Neutron (virtual network service):
  Invalid
Status in “neutron” package in Ubuntu:
  New

Bug description:
  On a fresh installation of Juno, it seems that that the database is
  not being populated correctly on a fresh install. This is the output
  of the log (I also demonstrated the DB had no tables to begin with):

  MariaDB [(none)]> use neutron
  Database changed
  MariaDB [neutron]> show tables;
  Empty set (0.00 sec)

  MariaDB [neutron]> quit
  Bye
  root@vm-1:~# neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugin.ini current
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  Current revision for mysql://neutron:X@10.10.10.1/neutron: None
  root@vm-1:~# neutron-db-manage --config-file /etc/neutron/neutron.conf 
--config-file /etc/neutron/plugin.ini upgrade head
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  INFO  [alembic.migration] Running upgrade None -> havana, havana_initial
  INFO  [alembic.migration] Running upgrade havana -> e197124d4b9, add unique 
constraint to members
  INFO  [alembic.migration] Running upgrade e197124d4b9 -> 1fcfc149aca4, Add a 
unique constraint on (agent_type, host) columns to prevent a race condition 
when an agent entry is 'upserted'.
  INFO  [alembic.migration] Running upgrade 1fcfc149aca4 -> 50e86cb2637a, 
nsx_mappings
  INFO  [alembic.migration] Running upgrade 50e86cb2637a -> 1421183d533f, NSX 
DHCP/metadata support
  INFO  [alembic.migration] Running upgrade 1421183d533f -> 3d3cb89d84ee, 
nsx_switch_mappings
  INFO  [alembic.migration] Running upgrade 3d3cb89d84ee -> 4ca36cfc898c, 
nsx_router_mappings
  INFO  [alembic.migration] Running upgrade 4ca36cfc898c -> 27cc183af192, 
ml2_vnic_type
  INFO  [alembic.migration] Running upgrade 27cc183af192 -> 50d5ba354c23, ml2 
binding:vif_details
  INFO  [alembic.migration] Running upgrade 50d5ba354c23 -> 157a5d299379, ml2 
binding:profile
  INFO  [alembic.migration] Running upgrade 157a5d299379 -> 3d2585038b95, 
VMware NSX rebranding
  INFO  [alembic.migration] Running upgrade 3d2585038b95 -> abc88c33f74f, lb 
stats
  INFO  [alembic.migration] Running upgrade abc88c33f74f -> 1b2580001654, 
nsx_sec_group_mapping
  INFO  [alembic.migration] Running upgrade 1b2580001654 -> e766b19a3bb, 
nuage_initial
  INFO  [alembic.migration] Running upgrade e766b19a3bb -> 2eeaf963a447, 
floatingip_status
  INFO  [alembic.migration] Running upgrade 2eeaf963a447 -> 492a106273f8, 
Brocade ML2 Mech. Driver
  INFO  [alembic.migration] Running upgrade 492a106273f8 -> 24c7ea5160d7, Cisco 
CSR VPNaaS
  INFO  [alembic.migration] Running upgrade 24c7ea5160d7 -> 81c553f3776c, 
bsn_consistencyhashes
  INFO  [alembic.migration] Running upgrade 81c553f3776c -> 117643811bca, nec: 
delete old ofc mapping tables
  INFO  [alembic.migration] Running upgrade 117643811bca -> 19180cf98af6, 
nsx_gw_devices
  INFO  [alembic.migration] Running upgrade 19180cf98af6 -> 33dd0a9fa487, 
embrane_lbaas_driver
  INFO  [alembic.migration] Running upgrade 33dd0a9fa487 -> 2447ad0e9585, Add 
IPv6 Subnet properties
  INFO  [alembic.migration] Running upgrade 2447ad0e9585 -> 538732fa21e1, NEC 
Rename quantum_id to neutron_id
  INFO  [alembic.migration] Running upgrade 538732fa21e1 -> 5ac1c354a051, n1kv 
segment allocs for cisco n1kv plugin
  INFO  [alembic.migration] Running upgrade 5ac1c354a051 -> icehouse, icehouse
  INFO  [alembic.migration] Running upgrade icehouse -> 54f7549a0e5f, 
set_not_null_peer_address
  INFO  [alembic.migration] Running upgrade 54f7549a0e5f -> 1e5dd1d09b22, 
set_not_null_fields_lb_stats
  INFO  [alembic.migration] Running upgrade 1e5dd1d09b22 -> b65aa907aec, 
set_length_of_protocol_field
  INFO  [alembic.migration] Running upgrade b65aa907aec -> 33c3db036fe4, 
set_length_of_description_field_metering
  INFO  [alembic.migration] Running upgrade 33c3db036fe4 -> 4eca4a84f08a, 
Remove ML2 Cisco Credentials DB
  INFO  [alembic.migration] Running upgrade 4eca4a84f08a -> d06e871c0d5, 
set_admin_state_up_not_null_ml2
  INFO  [alembic.migration] Running upgrade d06e871c0d5 -> 6be312499f9, 
set_not_null_vlan_id_cisco
  INFO  [alembic.migration] Running upgrade 6be312499f9 -> 1b837a7125a9, Cisco 
APIC Mechanism Driver
  INFO  [alembic.migration] Running upgrade 1b837a7125a9 -> 10cd28e692e9, 
nuage_extraroute
  INFO  [alembic.migration] Running upgrade 10cd28e692e9 -> 2db5203cb7a9

[Yahoo-eng-team] [Bug 1372792] Re: Inconsistent timestamp formats in ceilometer metering messages

2014-10-14 Thread Ann Kamyshnikova
Seems that this problem appear because of usage Elasticsearch, as there
is no such problem running devstack with Neutron and Ceilometer with
both publishers (rpc, upd). I'm not sure where this should be fixed as
in basic case everything works fine.

** Changed in: neutron
   Status: Incomplete => Opinion

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

Title:
  Inconsistent timestamp formats in ceilometer metering messages

Status in OpenStack Neutron (virtual network service):
  Opinion

Bug description:
  The messages generated by neutron-metering-agent contain timestamps in
  a different format than the other messages received through UDP from
  ceilometer-agent-notification. This creates unnecessary troubles for
  whoever is trying to decode the messages and do something useful with
  them.

  I particular, up to now, I found out about the timestamp field in the
  bandwidth message.

  They contain UTC dates (I hope), but there is no Z at the end, and
  they contain a space instead of a T between date and time. In short,
  they are not in ISO8601 as the timestamps in the other messages. I
  found out about them because elasticsearch tries to parse them and
  fails, throwing away the message.

  This bug was filed against Ceilometer, but I have been redirected here:
  https://bugs.launchpad.net/ceilometer/+bug/1370607

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1372792/+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 1374398] [NEW] Non admin user can update router port

2014-09-26 Thread Ann Kamyshnikova
Public bug reported:

Non admin user can update router's port http://paste.openstack.org/show/115575/.
This can caused problems as server's won't get information about this change 
until next DHCP request so connectivity to and from this network will be lost.

** Affects: neutron
 Importance: Undecided
     Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Non admin user can update router port

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Non admin user can update router's port 
http://paste.openstack.org/show/115575/.
  This can caused problems as server's won't get information about this change 
until next DHCP request so connectivity to and from this network will be lost.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1374398/+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 1372810] Re: Incorrect declaration plugin's name in setup.cfg

2014-09-23 Thread Ann Kamyshnikova
** Project changed: python-neutronclient => neutron

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

Title:
  Incorrect declaration plugin's name in setup.cfg

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  In setup.cfg name of OneConvergencePlugin is set incorrectly. Used '.'
  instead of ':'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1372810/+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 1367757] Re: nuage_net_partition_router_mapping model does not match migration

2014-09-11 Thread Ann Kamyshnikova
This bug seems to be invalid. Checked on master on MySQL and PostgreSQL
http://paste.openstack.org/show/11/ Primary is already created from
(`net_partition_id`,`router_id`).

** 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/1367757

Title:
  nuage_net_partition_router_mapping model does not match migration

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  class NetPartitionRouter(model_base.BASEV2):
  __tablename__ = "nuage_net_partition_router_mapping"
  net_partition_id = sa.Column(sa.String(36),
   sa.ForeignKey('nuage_net_partitions.id',
   ondelete="CASCADE"),
   primary_key=True)
  router_id = sa.Column(sa.String(36),
sa.ForeignKey('routers.id', ondelete="CASCADE"),
primary_key=True)
  nuage_router_id = sa.Column(sa.String(36))

  
  op.create_table(
  'net_partition_router_mapping',
  sa.Column('net_partition_id', sa.String(length=36), nullable=False),
  sa.Column('router_id', sa.String(length=36), nullable=False),
  sa.Column('nuage_router_id', sa.String(length=36), nullable=True),
  sa.ForeignKeyConstraint(['net_partition_id'], ['net_partitions.id'],
  ondelete='CASCADE'),
  sa.ForeignKeyConstraint(['router_id'], ['routers.id'],
  ondelete='CASCADE'),
  sa.PrimaryKeyConstraint('router_id'),
  )

  The migration is missing PK constraint on net_partition_id.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1367757/+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 1342507] Re: healing migration doesn't work for ryu CI

2014-08-20 Thread Ann Kamyshnikova
There is a problem with version of alembic. With alembic>=0.6.4 for all
plugins heal script worked normal. I tested locally and I got such error
only with alembic versions 0.6.2 and older. Global requirements already
updated with  alembic>=0.6.4. So the problem should get fixed with
alembic version upgrade.


** Changed in: neutron
   Status: Confirmed => 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/1342507

Title:
  healing migration doesn't work for ryu CI

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  ryu CI started failing after healing migration change
  (https://review.openstack.org/#/c/96438/)

  http://180.37.183.32/ryuci/38/96438/41/check/check-tempest-dsvm-
  ryuplugin/e457d80/logs/devstacklog.txt.gz

  2014-07-15 11:27:55.722 | Traceback (most recent call last):
  2014-07-15 11:27:55.722 |   File "/usr/local/bin/neutron-db-manage", line 10, 
in 
  2014-07-15 11:27:55.722 | sys.exit(main())
  2014-07-15 11:27:55.722 |   File 
"/opt/stack/new/neutron/neutron/db/migration/cli.py", line 171, in main
  2014-07-15 11:27:55.722 | CONF.command.func(config, CONF.command.name)
  2014-07-15 11:27:55.722 |   File 
"/opt/stack/new/neutron/neutron/db/migration/cli.py", line 85, in 
do_upgrade_downgrade
  2014-07-15 11:27:55.722 | do_alembic_command(config, cmd, revision, 
sql=CONF.command.sql)
  2014-07-15 11:27:55.722 |   File 
"/opt/stack/new/neutron/neutron/db/migration/cli.py", line 63, in 
do_alembic_command
  2014-07-15 11:27:55.723 | getattr(alembic_command, cmd)(config, *args, 
**kwargs)
  2014-07-15 11:27:55.723 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/command.py", line 124, in 
upgrade
  2014-07-15 11:27:55.733 | script.run_env()
  2014-07-15 11:27:55.734 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/script.py", line 199, in run_env
  2014-07-15 11:27:55.736 | util.load_python_file(self.dir, 'env.py')
  2014-07-15 11:27:55.737 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/util.py", line 205, in 
load_python_file
  2014-07-15 11:27:55.737 | module = load_module_py(module_id, path)
  2014-07-15 11:27:55.738 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/compat.py", line 58, in 
load_module_py
  2014-07-15 11:27:55.738 | mod = imp.load_source(module_id, path, fp)
  2014-07-15 11:27:55.738 |   File 
"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/env.py", line 
106, in 
  2014-07-15 11:27:55.738 | run_migrations_online()
  2014-07-15 11:27:55.738 |   File 
"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/env.py", line 
90, in run_migrations_online
  2014-07-15 11:27:55.738 | options=build_options())
  2014-07-15 11:27:55.738 |   File "", line 7, in run_migrations
  2014-07-15 11:27:55.739 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/environment.py", line 681, in 
run_migrations
  2014-07-15 11:27:55.740 | self.get_context().run_migrations(**kw)
  2014-07-15 11:27:55.740 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/migration.py", line 225, in 
run_migrations
  2014-07-15 11:27:55.741 | change(**kw)
  2014-07-15 11:27:55.741 |   File 
"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/versions/1d6ee1ae5da5_db_healing.py",
 line 32, in upgrade
  2014-07-15 11:27:55.741 | heal_script.heal()
  2014-07-15 11:27:55.741 |   File 
"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py",
 line 78, in heal
  2014-07-15 11:27:55.741 | execute_alembic_command(el)
  2014-07-15 11:27:55.741 |   File 
"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py",
 line 93, in execute_alembic_command
  2014-07-15 11:27:55.741 | parse_modify_command(command)
  2014-07-15 11:27:55.741 |   File 
"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py",
 line 126, in parse_modify_command
  2014-07-15 11:27:55.741 | op.alter_column(table, column, **kwargs)
  2014-07-15 11:27:55.741 |   File "", line 7, in alter_column
  2014-07-15 11:27:55.742 |   File "", line 1, in 
  2014-07-15 11:27:55.742 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/util.py", line 322, in go
  2014-07-15 11:27:55.742 | return fn(*arg, **kw)
  2014-07-15 11:27:55.742 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/operations.py", line 300, in 
alter_column
  2014-07-15 11:27:55.743 | existing_autoincrement=existing_autoincrement
  2014-07-15 11:27:55.743 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/ddl/mysql.py", line 42, in 
alter_column
  2014-07-15 11:27:55.743 | else existing_autoincrement
  2014-07-15 11:27:55.743 |   File 
"/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 76, in _exec
  2014-07-15 11:27:55.744 | conn.execute(construct, *multiparams, **params)
  2014-07-15 11

[Yahoo-eng-team] [Bug 1349810] [NEW] Wrong order of tables for dropping in downgrade

2014-07-29 Thread Ann Kamyshnikova
Public bug reported:

Heal migration fix bug https://bugs.launchpad.net/neutron/+bug/1336177.
Now table ml2_brocadenetworks has foreign key and downgrade of
492a106273f8_brocade_ml2_mech_dri fails. Error log:
http://paste.openstack.org/show/88898/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

** Description changed:

- Heal script fix bug https://bugs.launchpad.net/neutron/+bug/1336177. Now
- table ml2_brocadenetworks has foreign key and downgrade of
+ Heal migration fix bug https://bugs.launchpad.net/neutron/+bug/1336177.
+ Now table ml2_brocadenetworks has foreign key and downgrade of
  492a106273f8_brocade_ml2_mech_dri fails. Error log:
  http://paste.openstack.org/show/88898/

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

Title:
  Wrong order of tables for dropping in downgrade

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Heal migration fix bug
  https://bugs.launchpad.net/neutron/+bug/1336177. Now table
  ml2_brocadenetworks has foreign key and downgrade of
  492a106273f8_brocade_ml2_mech_dri fails. Error log:
  http://paste.openstack.org/show/88898/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1349810/+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 1349437] [NEW] check-neutron-dsvm-functional constantly fails with MySQL-python in test-requirements

2014-07-28 Thread Ann Kamyshnikova
Public bug reported:

In change https://review.openstack.org/76520 MySQL-python was added to
test-requirements. After that check-neutron-dsvm-functional started to
constantly fail with this error log:
http://paste.openstack.org/show/88702/

** 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/1349437

Title:
  check-neutron-dsvm-functional constantly fails with MySQL-python in
  test-requirements

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In change https://review.openstack.org/76520 MySQL-python was added to
  test-requirements. After that check-neutron-dsvm-functional started to
  constantly fail with this error log:
  http://paste.openstack.org/show/88702/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1349437/+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 1349345] [NEW] Neutron does not contain checks for running migration upgrade->downgrade->upgrade

2014-07-28 Thread Ann Kamyshnikova
Public bug reported:

Big number of existing migrations had problems with downgrade, because
developers forgot to test this. To make it easier a test should be
created that will run each migration through
upgrade->downgrade->upgrade.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Neutron does not contain checks for running migration
  upgrade->downgrade->upgrade

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Big number of existing migrations had problems with downgrade, because
  developers forgot to test this. To make it easier a test should be
  created that will run each migration through
  upgrade->downgrade->upgrade.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1349345/+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 1348138] [NEW] Migration set_length_of_description_field_metering does not work for Postgres older that 9.1.13

2014-07-24 Thread Ann Kamyshnikova
Public bug reported:

Migration set_length_of_description_field_metering fails on Postgres if
its version is less then 9.1.13. Error log
http://paste.openstack.org/show/87920/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Migration set_length_of_description_field_metering does not work for
  Postgres older that 9.1.13

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Migration set_length_of_description_field_metering fails on Postgres
  if its version is less then 9.1.13. Error log
  http://paste.openstack.org/show/87920/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1348138/+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 1346966] [NEW] Heal migration fails if MySQL is using MyISAM engine

2014-07-22 Thread Ann Kamyshnikova
Public bug reported:

If in MySQL default engine is set to  MyISAM, heal migration fails with
such error log http://paste.openstack.org/show/87625/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Heal migration fails if MySQL is using MyISAM engine

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If in MySQL default engine is set to  MyISAM, heal migration fails
  with such error log http://paste.openstack.org/show/87625/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1346966/+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 1346245] [NEW] Incorrect downgrade in migration b7a8863760e_rm_cisco_vlan_bindin

2014-07-21 Thread Ann Kamyshnikova
Public bug reported:

Downgrade in migration b7a8863760e_rm_cisco_vlan_bindin fails
http://paste.openstack.org/show/87396/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: cisco db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Incorrect downgrade in migration b7a8863760e_rm_cisco_vlan_bindin

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Downgrade in migration b7a8863760e_rm_cisco_vlan_bindin fails
  http://paste.openstack.org/show/87396/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1346245/+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 1248501] Re: Models are not in sync with migrations

2014-07-16 Thread Ann Kamyshnikova
** 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/1248501

Title:
  Models are not in sync with migrations

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Some migrations are not synchronized with models. In some models wrong
  parameter for 'nullable' parameter in columns, wrong length of String
  values is set and  __table_args__  for indexes and unique constraints
  is used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1248501/+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 1341518] [NEW] Incorrect default value on integer column

2014-07-14 Thread Ann Kamyshnikova
Public bug reported:

Migration 5446f2a45467_set_server_default try to set incorrect default
boolean value on Integer column cisco_network_profiles.

http://paste.openstack.org/show/86383/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress


** Tags: cisco db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Incorrect default value on integer column

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  Migration 5446f2a45467_set_server_default try to set incorrect default
  boolean value on Integer column cisco_network_profiles.

  http://paste.openstack.org/show/86383/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1341518/+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 1337216] [NEW] Table 'agents' is missing for bigswitch plugin

2014-07-03 Thread Ann Kamyshnikova
Public bug reported:

Running migrations for Bigswitch plugin got an error
http://paste.openstack.org/show/85380/. For creating table
'networkdhcpagentbindings'  table 'agents' is needed to exist, but
Bigswitch plugin was not added to the migration_for_plugins list in
migration 511471cc46b_agent_ext_model_supp.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: bigswitch db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Table 'agents' is missing for bigswitch plugin

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Running migrations for Bigswitch plugin got an error
  http://paste.openstack.org/show/85380/. For creating table
  'networkdhcpagentbindings'  table 'agents' is needed to exist, but
  Bigswitch plugin was not added to the migration_for_plugins list in
  migration 511471cc46b_agent_ext_model_supp.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1337216/+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 1337185] [NEW] Brocadeport table is not up to models

2014-07-03 Thread Ann Kamyshnikova
Public bug reported:

In models for brocadeport for columns admin_state_up and  network_id
have nullable=False, but it was skipped in migrations. Also vlan_id have
type Sring(10) instead of String(36) and there is a missing foreign key
on network_id column.

Difference is shown here http://paste.openstack.org/show/85376/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Brocadeport table is not up to models

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In models for brocadeport for columns admin_state_up and  network_id
  have nullable=False, but it was skipped in migrations. Also vlan_id
  have type Sring(10) instead of String(36) and there is a missing
  foreign key on network_id column.

  Difference is shown here http://paste.openstack.org/show/85376/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1337185/+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 1336177] [NEW] Foreign key was set in model, but was skipped in migration

2014-07-01 Thread Ann Kamyshnikova
Public bug reported:

Foreign key for network_id column was set in model ML2_BrocadePort , but
it was not added in migration 492a106273f8_brocade_ml2_mech_dri for this
column.


Database content http://paste.openstack.org/show/85201/

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Foreign key was set in model, but was skipped in migration

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Foreign key for network_id column was set in model ML2_BrocadePort ,
  but it was not added in migration 492a106273f8_brocade_ml2_mech_dri
  for this column.

  
  Database content http://paste.openstack.org/show/85201/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1336177/+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 1312124] [NEW] Downgrade doesn't work in 4eca4a84f08a_remove_ml2_cisco_cred_db migration

2014-04-24 Thread Ann Kamyshnikova
Public bug reported:

In downgrade for 4eca4a84f08a_remove_ml2_cisco_cred_db there is a
mistake in usage SQLAlchemy String type. Used sa.string instead of
sa.String

akamyshnikova@akamyshnikova:/opt/stack/neutron$ neutron-db-manage --config-file 
/etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini 
downgrade -10
INFO  [alembic.migration] Context impl MySQLImpl.
INFO  [alembic.migration] Will assume non-transactional DDL.
INFO  [alembic.migration] Running downgrade 1dde83e0359e -> 26a933acf533, 
add_index_psql_cisco
INFO  [alembic.migration] Running downgrade 26a933acf533 -> 30231c78a878, 
add_index_psql_packetfilter
INFO  [alembic.migration] Running downgrade 30231c78a878 -> 168ce7333432, 
add_index_psql_metering
INFO  [alembic.migration] Running downgrade 168ce7333432 -> 6be312499f9, 
add_index_psql_fwaas
INFO  [alembic.migration] Running downgrade 6be312499f9 -> d06e871c0d5, 
set_not_null_vlan_id_cisco
INFO  [alembic.migration] Running downgrade d06e871c0d5 -> 4eca4a84f08a, 
set_admin_state_up_not_null_ml2
INFO  [alembic.migration] Running downgrade 4eca4a84f08a -> 33c3db036fe4, 
Remove ML2 Cisco Credentials DB
Traceback (most recent call last):
  File "/usr/local/bin/neutron-db-manage", line 10, in 
sys.exit(main())
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 167, in main
CONF.command.func(config, CONF.command.name)
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 81, in 
do_upgrade_downgrade
do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 59, in 
do_alembic_command
getattr(alembic_command, cmd)(config, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/alembic/command.py", line 150, 
in downgrade
script.run_env()
  File "/usr/local/lib/python2.7/dist-packages/alembic/script.py", line 199, in 
run_env
util.load_python_file(self.dir, 'env.py')
  File "/usr/local/lib/python2.7/dist-packages/alembic/util.py", line 205, in 
load_python_file
module = load_module_py(module_id, path)
  File "/usr/local/lib/python2.7/dist-packages/alembic/compat.py", line 58, in 
load_module_py
mod = imp.load_source(module_id, path, fp)
  File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", 
line 103, in 
run_migrations_online()
  File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", 
line 87, in run_migrations_online
options=build_options())
  File "", line 7, in run_migrations
  File "/usr/local/lib/python2.7/dist-packages/alembic/environment.py", line 
681, in run_migrations
self.get_context().run_migrations(**kw)
  File "/usr/local/lib/python2.7/dist-packages/alembic/migration.py", line 225, 
in run_migrations
change(**kw)
  File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/4eca4a84f08a_remove_ml2_cisco_cred_db.py",
 line 53, in downgrade
sa.Column('credential_id', sa.string(length=255), nullable=True),
AttributeError: 'module' object has no attribute 'string'

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Downgrade doesn't work in 4eca4a84f08a_remove_ml2_cisco_cred_db
  migration

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In downgrade for 4eca4a84f08a_remove_ml2_cisco_cred_db there is a
  mistake in usage SQLAlchemy String type. Used sa.string instead of
  sa.String

  akamyshnikova@akamyshnikova:/opt/stack/neutron$ neutron-db-manage 
--config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/plugins/ml2/ml2_conf.ini downgrade -10
  INFO  [alembic.migration] Context impl MySQLImpl.
  INFO  [alembic.migration] Will assume non-transactional DDL.
  INFO  [alembic.migration] Running downgrade 1dde83e0359e -> 26a933acf533, 
add_index_psql_cisco
  INFO  [alembic.migration] Running downgrade 26a933acf533 -> 30231c78a878, 
add_index_psql_packetfilter
  INFO  [alembic.migration] Running downgrade 30231c78a878 -> 168ce7333432, 
add_index_psql_metering
  INFO  [alembic.migration] Running downgrade 168ce7333432 -> 6be312499f9, 
add_index_psql_fwaas
  INFO  [alembic.migration] Running downgrade 6be312499f9 -> d06e871c0d5, 
set_not_null_vlan_id_cisco
  INFO  [alembic.migration] Running downgrade d06e871c0d5 -> 4eca4a84f08a, 
set_admin_state_up_not_null_ml2
  INFO  [alembic.migration] Running downgrade 4eca4a84f08a -> 33c3db036fe4, 
Remove ML2 Cisco Credential

[Yahoo-eng-team] [Bug 1301396] [NEW] Enum type is changed incorrectly in migration 1341ed32cc1e_nvp_netbinding_update for

2014-04-02 Thread Ann Kamyshnikova
Public bug reported:

In migration 1341ed32cc1e_nvp_netbinding_update Enum type had been
changed incorrectly from ('flat', 'vlan', 'stt', 'gre') to ('flat',
'vlan', 'stt', 'gre', 'l3_ext')  for PostgeSQL so in database this type
was not changed.

This could be checked as it shown there
http://paste.openstack.org/show/74835/.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
     Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Enum type is changed incorrectly in migration
  1341ed32cc1e_nvp_netbinding_update for

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In migration 1341ed32cc1e_nvp_netbinding_update Enum type had been
  changed incorrectly from ('flat', 'vlan', 'stt', 'gre') to ('flat',
  'vlan', 'stt', 'gre', 'l3_ext')  for PostgeSQL so in database this
  type was not changed.

  This could be checked as it shown there
  http://paste.openstack.org/show/74835/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1301396/+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 1296282] [NEW] Incorrect nullable parameter in models

2014-03-23 Thread Ann Kamyshnikova
Public bug reported:

In some models value of 'nullable' parameter in columns is wrong. The following 
models are incorrect:
NULL for PoolLoadbalancerAgentBinding agent_id
NULL for NexusPortBinding switch_ip and instance_id
NULL for LsnPort lsn_id
NULL for NeutronNsxPortMapping nsx_port_id
NULL for TzNetworkBinding phy_uuid and vlan_id as they are primary keys
Migration 492a106273f8_brocade_ml2_mech_dri sets admin_state_up NULL in 
ml2_brocadeports instead of NOT NULL.

This can be checked as it is shown there
http://paste.openstack.org/show/74091/.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

** Description changed:

  In some models value of 'nullable' parameter in columns is wrong. The 
following models are incorrect:
  NULL for PoolLoadbalancerAgentBinding agent_id
  NULL for NexusPortBinding switch_ip and instance_id
  NULL for LsnPort lsn_id
  NULL for NeutronNsxPortMapping nsx_port_id
  NULL for TzNetworkBinding phy_uuid and vlan_id as they are primary keys
  Migration 492a106273f8_brocade_ml2_mech_dri sets admin_state_up NULL in 
ml2_brocadeports instead of NOT NULL.
  
- This can be checked as it shown there
+ This can be checked as it is shown there
  http://paste.openstack.org/show/74091/.

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

Title:
  Incorrect nullable parameter in models

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  In some models value of 'nullable' parameter in columns is wrong. The 
following models are incorrect:
  NULL for PoolLoadbalancerAgentBinding agent_id
  NULL for NexusPortBinding switch_ip and instance_id
  NULL for LsnPort lsn_id
  NULL for NeutronNsxPortMapping nsx_port_id
  NULL for TzNetworkBinding phy_uuid and vlan_id as they are primary keys
  Migration 492a106273f8_brocade_ml2_mech_dri sets admin_state_up NULL in 
ml2_brocadeports instead of NOT NULL.

  This can be checked as it is shown there
  http://paste.openstack.org/show/74091/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1296282/+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 1295539] [NEW] Inconsistent usage of 'server_default' parameter in models and migrations

2014-03-21 Thread Ann Kamyshnikova
Public bug reported:

In ml2 models parameter 'default' is used for vnic_type, profile and
vif_details, but in migrations  27cc183af192_ml2_vnic_type,
157a5d299379_ml2_binding_profile and
50d5ba354c23_ml2_binding_vif_details is used 'server_default' parameter.

Also MySQL sets  server_default parameter for some columns
automatically, but this is not mentioned in models and migrations. This
is happening for columns:

ml2_gre_endpoints.ip_address
ml2_vxlan_endpoints.ip_address  
networkgatewaydevicereferences.interface_name
networkgatewaydevicereferences.network_gateway_id
neutron_nsx_network_mappings.nsx_id
tz_network_bindings.phy_uuid
tz_network_bindings.vlan_id
cisco_credentials.credential_name
cisco_qos_policies.qos_name
cisco_qos_policies.tenant_id

This can be checked as it is shown there
http://paste.openstack.org/show/73972/.

This caused differences in models and migrations and MySQL and
PostgreSQL usage.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
   Inconsistent  usage of 'server_default' parameter in models and
  migrations

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In ml2 models parameter 'default' is used for vnic_type, profile and
  vif_details, but in migrations  27cc183af192_ml2_vnic_type,
  157a5d299379_ml2_binding_profile and
  50d5ba354c23_ml2_binding_vif_details is used 'server_default'
  parameter.

  Also MySQL sets  server_default parameter for some columns
  automatically, but this is not mentioned in models and migrations.
  This is happening for columns:

  ml2_gre_endpoints.ip_address
  ml2_vxlan_endpoints.ip_address
  networkgatewaydevicereferences.interface_name
  networkgatewaydevicereferences.network_gateway_id
  neutron_nsx_network_mappings.nsx_id
  tz_network_bindings.phy_uuid
  tz_network_bindings.vlan_id
  cisco_credentials.credential_name
  cisco_qos_policies.qos_name
  cisco_qos_policies.tenant_id

  This can be checked as it is shown there
  http://paste.openstack.org/show/73972/.

  This caused differences in models and migrations and MySQL and
  PostgreSQL usage.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1295539/+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 1292397] [NEW] Difference in index creation for foreign key in MySQL and Postgres

2014-03-14 Thread Ann Kamyshnikova
Public bug reported:

In some migration such as  39cf3f799352_fwaas_havana_2_model,
569e98a8132b_metering, 1064e98b7917_nec_pf_port_del.
ForeignKeyConstraint is created with name, but in models this name isn't
mentioned. MySQL creates index when it creates ForeignKeyConstraint.
This cause difference between models and migrations and between database
content for MySQL and Postgres.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: db

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

Title:
  Difference in index creation for foreign key in MySQL and Postgres

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In some migration such as  39cf3f799352_fwaas_havana_2_model,
  569e98a8132b_metering, 1064e98b7917_nec_pf_port_del.
  ForeignKeyConstraint is created with name, but in models this name
  isn't mentioned. MySQL creates index when it creates
  ForeignKeyConstraint. This cause difference between models and
  migrations and between database content for MySQL and Postgres.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1292397/+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 1289256] [NEW] Incorrect usage of sqlalchemy type Integer

2014-03-07 Thread Ann Kamyshnikova
Public bug reported:

In migration folsom_initial in cisco_upgrade function table nexusport_bindings 
create column vlan_id with incorrect type Integer(255). It causes the following 
exception:
  File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/folsom_initial.py",
 line 87, in upgrade
upgrade_cisco()
  File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/folsom_initial.py",
 line 455, in upgrade_cisco
sa.Column('vlan_id', sa.Integer(255)),
TypeError: object() takes no parameters

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress


** Tags: cisco db

** Changed in: neutron
     Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Incorrect usage of sqlalchemy type Integer

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  In migration folsom_initial in cisco_upgrade function table 
nexusport_bindings create column vlan_id with incorrect type Integer(255). It 
causes the following exception:
File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/folsom_initial.py",
 line 87, in upgrade
  upgrade_cisco()
File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/folsom_initial.py",
 line 455, in upgrade_cisco
  sa.Column('vlan_id', sa.Integer(255)),
  TypeError: object() takes no parameters

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1289256/+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 1288681] [NEW] Migration with alter_column function reset nullable parameter for columns

2014-03-06 Thread Ann Kamyshnikova
Public bug reported:

Migrations 338d7508968c_vpnaas_peer_address_.py and
abc88c33f74f_lb_stats_needs_bigint.py correct columns' length and types,
but nullable=False parameter is lost after its upgrade() :

mysql> explain ipsec_site_connections;
++-+--+-+-+---+
| Field  | Type
| Null | Key | Default | Extra |
++-+--+-+-+---+
| tenant_id  | varchar(255)
| YES  | | NULL|   |
| id | varchar(36) 
| NO   | PRI | NULL|   |
| name   | varchar(255)
| YES  | | NULL|   |
| description| varchar(255)
| YES  | | NULL|   |
| peer_address   | varchar(255)
| YES  | | NULL|   |
| peer_id| varchar(255)
| NO   | | NULL|   |
| route_mode | varchar(8)  
| NO   | | NULL|   |
| mtu| int(11) 
| NO   | | NULL|   |
| initiator  | enum('bi-directional','response-only')  
| NO   | | NULL|   |
| auth_mode  | varchar(16) 
| NO   | | NULL|   |
| psk| varchar(255)
| NO   | | NULL|   |
| dpd_action | enum('hold','clear','restart','disabled','restart-by-peer') 
| NO   | | NULL|   |
| dpd_interval   | int(11) 
| NO   | | NULL|   |
| dpd_timeout| int(11) 
| NO   | | NULL|   |
| status | varchar(16) 
| NO   | | NULL|   |
| admin_state_up | tinyint(1)  
| NO   | | NULL|   |
| vpnservice_id  | varchar(36) 
| NO   | MUL | NULL|   |
| ipsecpolicy_id | varchar(36) 
| NO   | MUL | NULL|   |
| ikepolicy_id   | varchar(36) 
| NO   | MUL | NULL|   |
++-+--+-+-+---+
19 rows in set (0.00 sec)


mysql> explain poolstatisticss;
++-+--+-+-+---+
| Field  | Type| Null | Key | Default | Extra |
++-+--+-+-+---+
| pool_id| varchar(36) | NO   | PRI | NULL|   |
| bytes_in   | bigint(20)  | YES  | | NULL|   |
| bytes_out  | bigint(20)  | YES  | | NULL|   |
| active_connections | bigint(20)  | YES  | | NULL|   |
| total_connections  | bigint(20)  | YES  | | NULL|   |
++-+--+-+-----+---+

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: New


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Migration with alter_column function reset nullable parameter for
  columns

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Migrations 338d7508968c_vpnaas_peer_address_.py and
  abc88c33f74f_lb_stats_needs_bigint.py correct columns' length and
  types, but nullable=False parameter is lost after its upgrade() :

  mysql> explain ipsec_site_connections;
  
++-+--+-+-+---+
  | Field  | Type   
 | Null | Key | Default | Extra |
  
++-+--+-+-+---+
  | tenant_id  | varchar(255)   
 | YES  | | NULL|   |
  | id | varchar(36)
 | NO   | PRI | NULL|   |
  | name 

[Yahoo-eng-team] [Bug 1285641] [NEW] different fully qualified class name for VPNaaS migrations

2014-02-27 Thread Ann Kamyshnikova
> 86cf4d88bd3, remove 
bigswitch port tracking table
INFO  [alembic.migration] Running upgrade 86cf4d88bd3 -> 3c6e57a23db4, add 
multiprovider
INFO  [alembic.migration] Running upgrade 3c6e57a23db4 -> 63afba73813, Add 
unique constraint for id column of TunnelEndpoint
INFO  [alembic.migration] Running upgrade 63afba73813 -> 40dffbf4b549, 
nvp_dist_router
INFO  [alembic.migration] Running upgrade 40dffbf4b549 -> 53bbd27ec841, Extra 
dhcp opts support
INFO  [alembic.migration] Running upgrade 53bbd27ec841 -> 46a0efbd8f0, 
cisco_n1kv_multisegment_trunk
INFO  [alembic.migration] Running upgrade 46a0efbd8f0 -> 2a3bae1ceb8, NEC Port 
Binding
INFO  [alembic.migration] Running upgrade 2a3bae1ceb8 -> 14f24494ca31, DB 
Migration for Arista ml2 mechanism driver
INFO  [alembic.migration] Running upgrade 14f24494ca31 -> 32a65f71af51, ml2 
portbinding
INFO  [alembic.migration] Running upgrade 32a65f71af51 -> 66a59a7f516, NEC 
OpenFlow Router
INFO  [alembic.migration] Running upgrade 66a59a7f516 -> 51b4de912379, Cisco 
Nexus ML2 mechanism driver
INFO  [alembic.migration] Running upgrade 51b4de912379 -> 1efb85914233, 
allowedaddresspairs
INFO  [alembic.migration] Running upgrade 1efb85914233 -> 38fc1f6789f8, Cisco 
N1KV overlay support
INFO  [alembic.migration] Running upgrade 38fc1f6789f8 -> 4a666eb208c2, service 
router
INFO  [alembic.migration] Running upgrade 4a666eb208c2 -> 338d7508968c, vpnaas 
peer_address size increase
Traceback (most recent call last):
  File "/usr/local/bin/neutron-db-manage", line 10, in 
sys.exit(main())
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 145, in main
CONF.command.func(config, CONF.command.name)
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 80, in 
do_upgrade_downgrade
do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 59, in 
do_alembic_command
getattr(alembic_command, cmd)(config, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/alembic/command.py", line 124, 
in upgrade
script.run_env()
  File "/usr/local/lib/python2.7/dist-packages/alembic/script.py", line 199, in 
run_env
util.load_python_file(self.dir, 'env.py')
  File "/usr/local/lib/python2.7/dist-packages/alembic/util.py", line 205, in 
load_python_file
module = load_module_py(module_id, path)
  File "/usr/local/lib/python2.7/dist-packages/alembic/compat.py", line 58, in 
load_module_py
mod = imp.load_source(module_id, path, fp)
  File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", 
line 105, in 
run_migrations_online()
  File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", 
line 89, in run_migrations_online
options=build_options())
  File "", line 7, in run_migrations
  File "/usr/local/lib/python2.7/dist-packages/alembic/environment.py", line 
681, in run_migrations
self.get_context().run_migrations(**kw)
  File "/usr/local/lib/python2.7/dist-packages/alembic/migration.py", line 225, 
in run_migrations
change(**kw)
  File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/338d7508968c_vpnaas_peer_address_.py",
 line 48, in upgrade
type_=sa.String(255), existing_type=sa.String(64))
  File "", line 7, in alter_column
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/alembic/util.py", line 322, in go
return fn(*arg, **kw)
  File "/usr/local/lib/python2.7/dist-packages/alembic/operations.py", line 
300, in alter_column
existing_autoincrement=existing_autoincrement
  File "/usr/local/lib/python2.7/dist-packages/alembic/ddl/mysql.py", line 42, 
in alter_column
else existing_autoincrement
  File "/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 76, 
in _exec
conn.execute(construct, *multiparams, **params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 
1449, in execute
params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 
1542, in _execute_ddl
compiled
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 
1698, in _execute_context
context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 
1691, in _execute_context
context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", 
line 331, in do_execute
cursor.execute(statement, parameters)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in 
execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in 
defaulterrorhandler

[Yahoo-eng-team] [Bug 1257607] [NEW] Mistake in usage drop_constraint parameters

2013-12-03 Thread Ann Kamyshnikova
Public bug reported:

In miration e197124d4b9_add_unique_constrain mistake in usage drop_constraint 
parameter type_ and positional agruments name
and table_name.

File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/e197124d4b9_add_unique_constrain.py",
 line 64, in downgrade
type='unique'
TypeError: drop_constraint() takes at least 2 arguments (1 given)

The same mistake was already fixed in miration
63afba73813_ovs_tunnelendpoints_id_unique.

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Kamyshnikova (akamyshnikova)
 Status: In Progress


** Tags: db

** Changed in: neutron
 Assignee: (unassigned) => Ann Kamyshnikova (akamyshnikova)

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

Title:
  Mistake in usage drop_constraint parameters

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  In miration e197124d4b9_add_unique_constrain mistake in usage drop_constraint 
parameter type_ and positional agruments name
  and table_name.

  File 
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/e197124d4b9_add_unique_constrain.py",
 line 64, in downgrade
  type='unique'
  TypeError: drop_constraint() takes at least 2 arguments (1 given)

  The same mistake was already fixed in miration
  63afba73813_ovs_tunnelendpoints_id_unique.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1257607/+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