[Yahoo-eng-team] [Bug 1441164] [NEW] Error in migration 066_fixup_service_name_value.py
Public bug reported: Migration script 066_fixup_service_name_value.py select all data from `service` table and call jsonutils.loads to `extra` column value. This column was created in migration 044 as nullable, so it may be a situation, when this script tries to call jsonutils.loads(None). In this case, migration will fail with the following traceback File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py, line 186, in upgrade return _migrate(url, repository, version, upgrade=True, err=err, **opts) File string, line 2, in _migrate File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py, line 160, in with_engine return f(*a, **kw) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py, line 366, in _migrate schema.runchange(ver, change, changeset.step) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py, line 93, in runchange change.run(self.engine, step) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py, line 148, in run script_func(engine) File /home/vsergeev/sandbox/keystone/keystone/common/sql/migrate_repo/versions/066_fixup_service_name_value.py, line 25, in upgrade extra_dict = jsonutils.loads(service.extra) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/oslo_serialization/jsonutils.py, line 215, in loads return json.loads(encodeutils.safe_decode(s, encoding), **kwargs) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/encodeutils.py, line 33, in safe_decode raise TypeError(%s can't be decoded % type(text)) TypeError: type 'NoneType' can't be decoded ** Affects: keystone Importance: Undecided Status: New ** Tags: db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1441164 Title: Error in migration 066_fixup_service_name_value.py Status in OpenStack Identity (Keystone): New Bug description: Migration script 066_fixup_service_name_value.py select all data from `service` table and call jsonutils.loads to `extra` column value. This column was created in migration 044 as nullable, so it may be a situation, when this script tries to call jsonutils.loads(None). In this case, migration will fail with the following traceback File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py, line 186, in upgrade return _migrate(url, repository, version, upgrade=True, err=err, **opts) File string, line 2, in _migrate File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py, line 160, in with_engine return f(*a, **kw) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py, line 366, in _migrate schema.runchange(ver, change, changeset.step) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py, line 93, in runchange change.run(self.engine, step) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py, line 148, in run script_func(engine) File /home/vsergeev/sandbox/keystone/keystone/common/sql/migrate_repo/versions/066_fixup_service_name_value.py, line 25, in upgrade extra_dict = jsonutils.loads(service.extra) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/oslo_serialization/jsonutils.py, line 215, in loads return json.loads(encodeutils.safe_decode(s, encoding), **kwargs) File /home/vsergeev/sandbox/keystone/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/encodeutils.py, line 33, in safe_decode raise TypeError(%s can't be decoded % type(text)) TypeError: type 'NoneType' can't be decoded To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1441164/+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 1397890] Re: Missing primary key constraint at endpoint_group.id column
*** This bug is a duplicate of bug 1399768 *** https://bugs.launchpad.net/bugs/1399768 ** This bug has been marked a duplicate of bug 1399768 migration of endpoint_filter fails due to foreign key constraint -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1397890 Title: Missing primary key constraint at endpoint_group.id column Status in OpenStack Identity (Keystone): In Progress Bug description: Most tables should have a primary key, and each table can have only ONE primary key. The PRIMARY KEY constraint uniquely identifies each record in a database table. The endpoint_group has no primary key. But project_endpoint_group table provides a primary key constraint pointed to endpoint_group.id column. Such a migration can't be applied with any sql backend except SQLite. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1397890/+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 1393633] Re: test_postgresql_opportunistically fails with database openstack_citest is being accessed by other users
** Changed in: oslo.db Status: Fix Committed = Fix Released ** Changed in: oslo.db Milestone: next-juno = 1.1.0 -- 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/1393633 Title: test_postgresql_opportunistically fails with database openstack_citest is being accessed by other users Status in OpenStack Compute (Nova): Fix Committed Status in Oslo Database library: Fix Released Bug description: Looks like this was previously fixed under bug 1328997 but this is back: http://logs.openstack.org/72/135072/1/check/gate-nova- python27/ba44ca9/console.html#_2014-11-17_22_51_24_244 2014-11-17 22:51:24.244 | Captured traceback: 2014-11-17 22:51:24.244 | ~~~ 2014-11-17 22:51:24.244 | Traceback (most recent call last): 2014-11-17 22:51:24.244 | File nova/tests/unit/db/test_migrations.py, line 138, in test_postgresql_opportunistically 2014-11-17 22:51:24.245 | self._test_postgresql_opportunistically() 2014-11-17 22:51:24.245 | File nova/tests/unit/db/test_migrations.py, line 429, in _test_postgresql_opportunistically 2014-11-17 22:51:24.245 | self._reset_database(database) 2014-11-17 22:51:24.245 | File nova/tests/unit/db/test_migrations.py, line 336, in _reset_database 2014-11-17 22:51:24.245 | self._reset_pg(conn_pieces) 2014-11-17 22:51:24.245 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/oslo/concurrency/lockutils.py, line 311, in inner 2014-11-17 22:51:24.245 | return f(*args, **kwargs) 2014-11-17 22:51:24.245 | File nova/tests/unit/db/test_migrations.py, line 245, in _reset_pg 2014-11-17 22:51:24.245 | self.execute_cmd(droptable) 2014-11-17 22:51:24.245 | File nova/tests/unit/db/test_migrations.py, line 228, in execute_cmd 2014-11-17 22:51:24.245 | Failed to run: %s\n%s % (cmd, output)) 2014-11-17 22:51:24.246 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py, line 348, in assertEqual 2014-11-17 22:51:24.246 | self.assertThat(observed, matcher, message) 2014-11-17 22:51:24.246 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py, line 433, in assertThat 2014-11-17 22:51:24.246 | raise mismatch_error 2014-11-17 22:51:24.246 | MismatchError: !=: 2014-11-17 22:51:24.246 | reference = '' 2014-11-17 22:51:24.246 | actual= u'''\ 2014-11-17 22:51:24.246 | Unexpected error while running command. 2014-11-17 22:51:24.246 | Command: psql -w -U openstack_citest -h localhost -c 'drop database if exists openstack_citest;' -d postgres 2014-11-17 22:51:24.246 | Exit code: 1 2014-11-17 22:51:24.246 | Stdout: u'' 2014-11-17 22:51:24.247 | Stderr: u'ERROR: database openstack_citest is being accessed by other users\\nDETAIL: There is 1 other session using the database.\\n\ 2014-11-17 22:51:24.247 | : Failed to run: psql -w -U openstack_citest -h localhost -c 'drop database if exists openstack_citest;' -d postgres 2014-11-17 22:51:24.247 | Unexpected error while running command. 2014-11-17 22:51:24.247 | Command: psql -w -U openstack_citest -h localhost -c 'drop database if exists openstack_citest;' -d postgres 2014-11-17 22:51:24.247 | Exit code: 1 2014-11-17 22:51:24.247 | Stdout: u'' 2014-11-17 22:51:24.247 | Stderr: u'ERROR: database openstack_citest is being accessed by other users\nDETAIL: There is 1 other session using the database.\n' 2014-11-17 22:51:24.247 | Traceback (most recent call last): 2014-11-17 22:51:24.247 | _StringException: Empty attachments: 2014-11-17 22:51:24.247 | pythonlogging:'' 2014-11-17 22:51:24.247 | stderr 2014-11-17 22:51:24.248 | stdout http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiQ29tbWFuZDogcHNxbCAtdyAtVSBvcGVuc3RhY2tfY2l0ZXN0IC1oIGxvY2FsaG9zdCAtYyAnZHJvcCBkYXRhYmFzZSBpZiBleGlzdHMgb3BlbnN0YWNrX2NpdGVzdDsnIC1kIHBvc3RncmVzXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5vdmEtcHl0aG9uMjdcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQxNjI3NTg1MDI4MSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== 516 hits in 7 days, check and gate, all failures. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1393633/+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 1227321] Re: DBDuplicateEntry not being translated for DB2
This bug was fixed in common DB code. Glance use it, so this but is not affects Glance ** Changed in: glance Status: Triaged = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1227321 Title: DBDuplicateEntry not being translated for DB2 Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): Fix Released Status in OpenStack Compute (Nova): Fix Released Status in The Oslo library incubator: Fix Released Bug description: The tempest.api.compute.keypairs.test_keypairs.test_create_keypair_with_duplicate_name test fails if you're running with a DB2 backend because the nova code is not currently translating the db integrity error if the backing engine is DB2 (ibm_db_sa) in nova.openstack.common.db.sqlalchemy.session._raise_if_duplicate_entry_error. Per full disclosure, nova is not claiming support for DB2 and there is a lot of work that would need to be done for that which my team is planning for icehouse and there is a blueprint here: https://blueprints.launchpad.net/nova/+spec/db2-database My team does have DB2 10.5 working with nova trunk but we have changes to the migration scripts to support that. Also, you have to run with the DB2 patch for sqlalchemy-migrate posted here: https://code.google.com/p/sqlalchemy-migrate/issues/detail?id=151 And you must run with the ibm-db/ibm-db-sa drivers: https://code.google.com/p/ibm-db/source/clones?repo=ibm-db-sa We're trying to get the sqlalchemy-migrate support for DB2 accepted in the icehouse timeframe but need to show the migrate maintainer that he can use the free express-c version of DB2 in ubuntu for the test backend. Anyway, having said all that, fixing the DBDuplicateEntry translation is part of the story so I'm opening a bug to track it and get the patch up to get the ball rolling. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1227321/+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 1374497] Re: change in oslo.db ping handling is causing issues in projects that are not using transactions
** Changed in: oslo.db Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1374497 Title: change in oslo.db ping handling is causing issues in projects that are not using transactions Status in OpenStack Identity (Keystone): Triaged Status in Oslo Database library: Fix Released Status in oslo.db juno series: Fix Released Bug description: in https://review.openstack.org/#/c/106491/, the ping listener which emits SELECT 1 at connection start was moved from being a connection pool checkout handler to a transaction on begin handler. Apparently Keystone and possibly others are using the Session in autocommit mode, despite that this is explicitly warned against in SQLAlchemy's docs (see http://docs.sqlalchemy.org/en/rel_0_9/orm/session.html#autocommit- mode), and for these projects they are seeing failed connections not transparently recovered (see https://bugs.launchpad.net/keystone/+bug/1361378). Alternatives include: 1. move the ping listener back to being a checkout handler 2. fix downstream projects to not use the session in autocommit mode In all likelihood, the fix here should involve both. I have a longer term plan to fix EngineFacade once and for all so that the correct use patterns are explicit, but that still has to be blueprinted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1374497/+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 1376211] Re: Retry mechanism does not work on startup when used with MySQL
** Changed in: oslo.db
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1376211
Title:
Retry mechanism does not work on startup when used with MySQL
Status in OpenStack Neutron (virtual network service):
Confirmed
Status in Oslo Database library:
Fix Released
Status in oslo.db juno series:
Confirmed
Bug description:
This is initially revealed as Red Hat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1144181
The problem shows up when Neutron or any other oslo.db based projects
start while MySQL server is not up yet. Instead of retrying connection
as per max_retries and retry_interval, service just crashes with
return code 1.
This is because during engine initialization, engine.execute(SHOW
VARIABLES LIKE 'sql_mode') is called, which opens the connection,
*before* _test_connection() succeeds. So the server just bail out to
sys.exit() at the top of the stack.
This behaviour was checked for both oslo.db 0.4.0 and 1.0.1.
I suspect this is a regression from the original db code from oslo-
incubator though I haven't checked it specifically.
The easiest way to reproduce the traceback is:
1. stop MariaDB.
2. execute the following Python script:
'''
import oslo.db.sqlalchemy.session
url = 'mysql://neutron:123456@10.35.161.235/neutron'
engine = oslo.db.sqlalchemy.session.EngineFacade(url)
'''
The following traceback can be seen in service log:
2014-10-01 13:46:10.588 5812 TRACE neutron Traceback (most recent call last):
2014-10-01 13:46:10.588 5812 TRACE neutron File /usr/bin/neutron-server,
line 10, in module
2014-10-01 13:46:10.588 5812 TRACE neutron sys.exit(main())
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/server/__init__.py, line 47, in main
2014-10-01 13:46:10.588 5812 TRACE neutron neutron_api =
service.serve_wsgi(service.NeutronApiService)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/service.py, line 105, in serve_wsgi
2014-10-01 13:46:10.588 5812 TRACE neutron LOG.exception(_('Unrecoverable
error: please check log '
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/openstack/common/excutils.py, line
82, in __exit__
2014-10-01 13:46:10.588 5812 TRACE neutron six.reraise(self.type_,
self.value, self.tb)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/service.py, line 102, in serve_wsgi
2014-10-01 13:46:10.588 5812 TRACE neutron service.start()
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/service.py, line 73, in start
2014-10-01 13:46:10.588 5812 TRACE neutron self.wsgi_app =
_run_wsgi(self.app_name)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/service.py, line 168, in _run_wsgi
2014-10-01 13:46:10.588 5812 TRACE neutron app =
config.load_paste_app(app_name)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/neutron/common/config.py, line 182, in
load_paste_app
2014-10-01 13:46:10.588 5812 TRACE neutron app =
deploy.loadapp(config:%s % config_path, name=app_name)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 247, in
loadapp
2014-10-01 13:46:10.588 5812 TRACE neutron return loadobj(APP, uri,
name=name, **kw)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 272, in
loadobj
2014-10-01 13:46:10.588 5812 TRACE neutron return context.create()
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 710, in create
2014-10-01 13:46:10.588 5812 TRACE neutron return
self.object_type.invoke(self)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke
2014-10-01 13:46:10.588 5812 TRACE neutron **context.local_conf)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/deploy/util.py, line 56, in fix_call
2014-10-01 13:46:10.588 5812 TRACE neutron val = callable(*args, **kw)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/urlmap.py, line 25, in urlmap_factory
2014-10-01 13:46:10.588 5812 TRACE neutron app = loader.get_app(app_name,
global_conf=global_conf)
2014-10-01 13:46:10.588 5812 TRACE neutron File
/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py, line 350, in
get_app
2014-10-01 13:46:10.588 5812 TRACE neutron name=name,
global_conf=global_conf).create()
2014-10-01 13:46:10.588 5812 TRACE neutron File
[Yahoo-eng-team] [Bug 1340793] Re: DB2 deadlock error not detected
Glance is using oslo.db, so if it's fixed there then it's fixed in glance as well. ** Changed in: glance Status: New = Invalid ** Changed in: heat 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/1340793 Title: DB2 deadlock error not detected Status in Cinder: Confirmed Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Status in Orchestration API (Heat): Invalid Status in OpenStack Identity (Keystone): Invalid Status in OpenStack Neutron (virtual network service): Confirmed Status in OpenStack Compute (Nova): Confirmed Status in The Oslo library incubator: Fix Released Bug description: Currently, only mysql and postgresql deadlock errors are properly handled. The error message for DB2 looks like: 'SQL0911N The current transaction has been rolled back because of a deadlock or timeout. deadlock details' Olso.db needs to include a regex to detect this deadlock. Essentially the same as https://bugs.launchpad.net/nova/+bug/1270725 but for DB2 This is an example error: 2014-07-01 19:52:16.574 2710 TRACE nova.openstack.common.db.sqlalchemy.session ProgrammingError: (ProgrammingError) ibm_db_dbi::ProgrammingError: Statement Execute Failed: [IBM][CLI Driver][DB2/LINUXX8664] SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code 2. SQLSTATE=40001 SQLCODE=-911 'UPDATE reservations SET updated_at=updated_at, deleted_at=?, deleted=id WHERE reservations.deleted = ? AND reservations.uuid IN (?, ?, ?)' (datetime.datetime(2014, 7, 1, 23, 52, 10, 774722), 0, 'e2353f5e-f444-4a94-b7bf-f877402c15ab', 'c4b22c95-284a-4ce3-810b- 5d9bbe6dd7b7', 'ab0294cb-c317-4594-9b19-911589228aa5') To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1340793/+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 1330763] Re: PostgrestSQLOpportunisticFixture fails with no attribute named _details
Proposed fix was merged and included to oslo.db 1.0.1 ** Changed in: oslo.db Status: In Progress = Fix Released -- 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/1330763 Title: PostgrestSQLOpportunisticFixture fails with no attribute named _details Status in OpenStack Compute (Nova): Invalid Status in Oslo Database library: Fix Released Bug description: 2014-06-16 22:13:11.783 | == 2014-06-16 22:13:11.783 | FAIL: nova.tests.db.test_db_api.TestPostgreSQLSqlalchemyTypesRepr.test_cidr_repr 2014-06-16 22:13:11.783 | tags: worker-7 2014-06-16 22:13:11.784 | -- 2014-06-16 22:13:11.784 | Empty attachments: 2014-06-16 22:13:11.784 | stderr 2014-06-16 22:13:11.784 | stdout 2014-06-16 22:13:11.784 | 2014-06-16 22:13:11.784 | Traceback (most recent call last): 2014-06-16 22:13:11.784 | File nova/tests/db/test_db_api.py, line 7227, in setUp 2014-06-16 22:13:11.784 | super(TestSqlalchemyTypesRepr, self).setUp() 2014-06-16 22:13:11.784 | File nova/openstack/common/db/sqlalchemy/test_base.py, line 149, in setUp 2014-06-16 22:13:11.785 | super(OpportunisticTestCase, self).setUp() 2014-06-16 22:13:11.785 | File nova/openstack/common/db/sqlalchemy/test_base.py, line 68, in setUp 2014-06-16 22:13:11.785 | self.useFixture(self.FIXTURE(self)) 2014-06-16 22:13:11.785 | File /home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py, line 630, in useFixture 2014-06-16 22:13:11.785 | gather_details(fixture.getDetails(), self.getDetails()) 2014-06-16 22:13:11.785 | File /home/jenkins/workspace/gate-nova-python26/.tox/py26/lib/python2.6/site-packages/fixtures/fixture.py, line 148, in getDetails 2014-06-16 22:13:11.785 | result = dict(self._details) 2014-06-16 22:13:11.785 | AttributeError: 'PostgreSQLOpportunisticFixture' object has no attribute '_details' http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnUG9zdGdyZVNRTE9wcG9ydHVuaXN0aWNGaXh0dXJlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnX2RldGFpbHMnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDI5NjI5NTU0MTZ9 This happens occasionally, but not super frequently. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1330763/+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 1367354] Re: oslo.db's master breaks unittest in OS projects
** Changed in: oslo.db Status: Fix Committed = Fix Released -- 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/1367354 Title: oslo.db's master breaks unittest in OS projects Status in OpenStack Identity (Keystone): Fix Committed Status in OpenStack Compute (Nova): Confirmed Status in Oslo Database library: Fix Released Bug description: When I run the unittests in different OpennStack projects using the latest oslo.db there were a lot of failures on Nova, Neutron and Keystone. The lot of tests raises OperationalError: (OperationalError) cannot start a transaction within a transaction 'BEGIN' () The right approach is to fix these projects, but we are in the end of J release, so I'm not sure, that we can merge these fixes fast. This issue was caused by commit [1], so the faster and simplest approach is - to revert this commit an continue our fork on this in K [1] https://github.com/openstack/oslo.db/commit/78fd290a89545de31e5c13f3085df23368a8afaa To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1367354/+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 1361378] Re: MySQL server has gone away again
** Project changed: oslo-incubator = oslo.db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1361378 Title: MySQL server has gone away again Status in OpenStack Identity (Keystone): New Status in Oslo Database library: Incomplete Bug description: This is a regression of an old issue, which I thought was resolved by the SELECT 1; hack, but perhaps recently reintroduced with oslo.db? [Mon Aug 25 14:30:54.403538 2014] [:error] [pid 25778:tid 139886259214080] 25778 ERROR keystone.common.wsgi [-] (OperationalError) (2003, Can't connect to MySQL server on '127.0.0.1' (111)) None None [Mon Aug 25 14:30:54.403562 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi Traceback (most recent call last): [Mon Aug 25 14:30:54.403570 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/common/wsgi.py, line 214, in __call__ [Mon Aug 25 14:30:54.403575 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi result = method(context, **params) [Mon Aug 25 14:30:54.403581 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/token/controllers.py, line 99, in authenticate [Mon Aug 25 14:30:54.403589 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi context, auth) [Mon Aug 25 14:30:54.403594 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/token/controllers.py, line 308, in _authenticate_local [Mon Aug 25 14:30:54.403600 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi username, CONF.identity.default_domain_id) [Mon Aug 25 14:30:54.403606 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/identity/core.py, line 182, in wrapper [Mon Aug 25 14:30:54.403612 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi return f(self, *args, **kwargs) [Mon Aug 25 14:30:54.403618 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/identity/core.py, line 193, in wrapper [Mon Aug 25 14:30:54.403624 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi return f(self, *args, **kwargs) [Mon Aug 25 14:30:54.403630 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/identity/core.py, line 579, in get_user_by_name [Mon Aug 25 14:30:54.403637 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi ref = driver.get_user_by_name(user_name, domain_id) [Mon Aug 25 14:30:54.403644 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /opt/stack/new/keystone/keystone/identity/backends/sql.py, line 140, in get_user_by_name [Mon Aug 25 14:30:54.403650 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi user_ref = query.one() [Mon Aug 25 14:30:54.403656 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2310, in one [Mon Aug 25 14:30:54.403662 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi ret = list(self) [Mon Aug 25 14:30:54.403667 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2353, in __iter__ [Mon Aug 25 14:30:54.403673 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi return self._execute_and_instances(context) [Mon Aug 25 14:30:54.403680 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2366, in _execute_and_instances [Mon Aug 25 14:30:54.403731 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi close_with_result=True) [Mon Aug 25 14:30:54.403740 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line 2357, in _connection_from_session [Mon Aug 25 14:30:54.403746 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi **kw) [Mon Aug 25 14:30:54.403752 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi File /usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 799, in connection [Mon Aug 25 14:30:54.403757 2014] [:error] [pid 25778:tid 139886259214080] 25778 TRACE keystone.common.wsgi
[Yahoo-eng-team] [Bug 1268875] Re: Oslo migrate.py does not have functionality to compute path to `migrate_repo`s
** Project changed: oslo-incubator = oslo.db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1268875 Title: Oslo migrate.py does not have functionality to compute path to `migrate_repo`s Status in OpenStack Identity (Keystone): Incomplete Status in Oslo Database library: Triaged Bug description: Oslo migrate.py does not have functionality corresponding to `keystone.common.sql.migration.find_migrate_repo`, for example. Synchronization is impossible without this functionality because the functionality is required. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268875/+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 1283987] Re: Query Deadlock when creating 200 servers at once in sqlalchemy
** Project changed: oslo-incubator = oslo.db -- 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/1283987 Title: Query Deadlock when creating 200 servers at once in sqlalchemy Status in OpenStack Compute (Nova): In Progress Status in Oslo Database library: In Progress Bug description: Query Deadlock when creating 200 servers at once in sqlalchemy. This bug occurred when I test this bug: https://bugs.launchpad.net/nova/+bug/1270725 The original info is logged here: http://paste.openstack.org/show/61534/ -- After checking the error-log, we can notice that the deadlock function is 'all()' in sqlalchemy framework. Previously, we use '@retry_on_dead_lock' function to retry requests when deadlock occurs. But it's only available for session deadlock(query/flush/execute). It doesn't cover some 'Query' actions in sqlalchemy. So, we need to add the same protction for 'all()' in sqlalchemy. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1283987/+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 1214341] Re: Not all db.sqal.session methods are wrapped by wrap_db_error
This bug also affects Keystone and Ironic, because these project checks for the sqlalchemy.exc.IntegrityError exception (instead of oslo.db.exception.DBDuplicateEntry), when they checks unit constrains in migration testing. ** Also affects: ironic Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1214341 Title: Not all db.sqal.session methods are wrapped by wrap_db_error Status in OpenStack Bare Metal Provisioning Service (Ironic): New Status in OpenStack Identity (Keystone): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: first(), all(), begin(), commit() and other public methods could produce amount of exceptions, that should be wrapped in exception in any case. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1214341/+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 1280055] Re: Replace nova.db.sqlalchemy.utils with openstack.common.db.sqlalchemy.utils
** Changed in: oslo Status: Fix Committed = Fix Released -- 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/1280055 Title: Replace nova.db.sqlalchemy.utils with openstack.common.db.sqlalchemy.utils Status in OpenStack Compute (Nova): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Released Bug description: Most of the code in nova.db.sqlalchemy.utils is also in oslo- incubator.openstack.common.db.sqlalchemy.utils, except for the modify_indexes method which is not actually even used in the nova db migration code anymore now that it's been compacted in icehouse. Also, the oslo.db code has been getting synced over to nova more frequently lately so rather than keep all of this duplicate code around we should move nova to using the oslo utils code and drop the internal nova one, with maybe moving the modify_indexes method to oslo first, then sync back to nova and then drop nova.db.sqlalchemy.utils from nova. We will have to make sure that there are no behavior differences in the oslo code such that it would change the nova db schema, but we should be able to use Dan Prince's nova/tools/db/schema_diff.py script to validate that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1280055/+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 1270725] Re: Quota Deadlock when creating 200 servers at once under Psql
** Changed in: oslo Status: Fix Committed = Fix Released -- 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/1270725 Title: Quota Deadlock when creating 200 servers at once under Psql Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Bug description: When you create 200 servers at once under psql, it's easier to meet a deadlock exception in quota process(reserve/commit). Like this: http://paste.openstack.org/show/61534/ The '@retry_on_dead_lock' function, is not available for matching psql. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1270725/+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 1252693] Re: Running of unit tests fails if SQLAlchemy = 0.8.3 is used
** Changed in: oslo
Status: Fix Committed = Fix Released
--
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/1252693
Title:
Running of unit tests fails if SQLAlchemy = 0.8.3 is used
Status in OpenStack Compute (Nova):
Fix Released
Status in Oslo - a Library of Common OpenStack Code:
Fix Released
Bug description:
If SQLAlchemy = 0.8.3 is used, running of unit tests fails. The
following error is printed to stderr multiple times:
DBError: (IntegrityError) constraint failed u'UPDATE
instance_system_metadata SET updated_at=?, deleted_at=?, deleted=?
WHERE instance_system_metadata.id = ?' ('2013- 11-19
10:37:44.378444', '2013-11-19 10:37:44.377819', 11, 11)
A few of our migrations change the type of deleted column from boolean
to int. MySQL and SQLite don't have native boolean data type.
SQLAlchemy uses int columns (e.g. in case of MySQL - tinyint) + CHECK
constraint (something like CHECK (deleted in (0, 1))) to emulate
boolean data type.
In our migrations when the type of column `deleted` is changed from
boolean to int, the corresponding CHECK constraint is dropped too. But
starting from SQLAlchemy version 0.8.3, those CHECK constraints aren't
dropped anymore. So despite the fact that column deleted is of type
int now, we still restrict its values to be either 0 or 1.
Migrations changing the data type of deleted columns rely on SQL
rendered for CHECK constraints (e.g.
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/152_change_type_of_deleted_column.py#L172).
There was a patch in SQLAlchemy 0.8.3 release that slightly changed
the way DDL statements are rendered
((http://docs.sqlalchemy.org/en/latest/changelog/changelog_08.html
#change-487183f04e6da9aa27d8817bca9906d1)). Unfortunately, due to the
fact that nova migrations depend on such implementation details, this
change to SQLAlchemy broke our code.
We must fix our migrations to work properly with new SQLAlchemy
versions too (0.8.3+).
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1252693/+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 1328997] Re: Unit test failure: openstack_citest is being accessed by other users\nDETAIL: There are 1 other session(s) using the database.
** Also affects: oslo Importance: Undecided Status: New ** Changed in: oslo Status: New = Confirmed ** Changed in: oslo Importance: Undecided = High -- 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/1328997 Title: Unit test failure: openstack_citest is being accessed by other users\nDETAIL: There are 1 other session(s) using the database. Status in OpenStack Bare Metal Provisioning Service (Ironic): Confirmed Status in OpenStack Compute (Nova): Confirmed Status in Oslo - a Library of Common OpenStack Code: Confirmed Bug description: We are periodically seeing this nova unit test failure in our CI system: openstack_citest is being accessed by other users\nDETAIL: There are 1 other session(s) using the database. http://logs.openstack.org/76/98376/1/gate/gate-nova- python27/d2a0593/console.html 2014-06-11 06:26:40.002 | FAIL: nova.tests.db.test_migrations.TestNovaMigrations.test_postgresql_opportunistically 2014-06-11 06:26:40.002 | tags: worker-6 2014-06-11 06:26:40.003 | -- 2014-06-11 06:26:40.003 | Empty attachments: 2014-06-11 06:26:40.003 | pythonlogging:'' 2014-06-11 06:26:40.003 | stderr 2014-06-11 06:26:40.003 | stdout 2014-06-11 06:26:40.003 | 2014-06-11 06:26:40.004 | Traceback (most recent call last): 2014-06-11 06:26:40.004 | File nova/tests/db/test_migrations.py, line 139, in test_postgresql_opportunistically 2014-06-11 06:26:40.004 | self._test_postgresql_opportunistically() 2014-06-11 06:26:40.004 | File nova/tests/db/test_migrations.py, line 428, in _test_postgresql_opportunistically 2014-06-11 06:26:40.004 | self._reset_database(database) 2014-06-11 06:26:40.004 | File nova/tests/db/test_migrations.py, line 335, in _reset_database 2014-06-11 06:26:40.004 | self._reset_pg(conn_pieces) 2014-06-11 06:26:40.005 | File nova/openstack/common/lockutils.py, line 249, in inner 2014-06-11 06:26:40.005 | return f(*args, **kwargs) 2014-06-11 06:26:40.005 | File nova/tests/db/test_migrations.py, line 244, in _reset_pg 2014-06-11 06:26:40.005 | self.execute_cmd(droptable) 2014-06-11 06:26:40.005 | File nova/tests/db/test_migrations.py, line 227, in execute_cmd 2014-06-11 06:26:40.005 | Failed to run: %s\n%s % (cmd, output)) 2014-06-11 06:26:40.005 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py, line 321, in assertEqual 2014-06-11 06:26:40.006 | self.assertThat(observed, matcher, message) 2014-06-11 06:26:40.006 | File /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py, line 406, in assertThat 2014-06-11 06:26:40.006 | raise mismatch_error 2014-06-11 06:26:40.006 | MismatchError: !=: 2014-06-11 06:26:40.006 | reference = '' 2014-06-11 06:26:40.006 | actual= '''\ 2014-06-11 06:26:40.007 | Unexpected error while running command. 2014-06-11 06:26:40.007 | Command: psql -w -U openstack_citest -h localhost -c 'drop database if exists openstack_citest;' -d template1 2014-06-11 06:26:40.007 | Exit code: 1 2014-06-11 06:26:40.007 | Stdout: '' 2014-06-11 06:26:40.007 | Stderr: 'ERROR: database openstack_citest is being accessed by other users\\nDETAIL: There are 1 other session(s) using the database.\\n\ 2014-06-11 06:26:40.007 | : Failed to run: psql -w -U openstack_citest -h localhost -c 'drop database if exists openstack_citest;' -d template1 elastic-search query: message:Stderr: \'ERROR: database \openstack_citest\ is being accessed by other users\\nDETAIL: There are 1 other session(s) using the database.\\n\' AND project:openstack/nova To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1328997/+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 1309297] Re: oslo removal of use_tpool conf option
** Changed in: nova Status: New = Fix Committed ** Changed in: nova Assignee: (unassigned) = Victor Sergeyev (vsergeyev) ** Changed in: oslo Status: New = Invalid ** Tags added: icehouse-backport-potential -- 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/1309297 Title: oslo removal of use_tpool conf option Status in OpenStack Compute (Nova): Fix Committed Status in Oslo - a Library of Common OpenStack Code: Invalid Bug description: Details here on the Mailing list: http://markmail.org/message/wwhd4qwrbynkzeax Here are the Oslo and Nova reviews: https://review.openstack.org/#/c/60031/ https://review.openstack.org/#/c/59760/ The Oslo review made it, but Nova did not make it in time. So we lost a config option in the shuffle. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1309297/+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 1296333] Re: Keystone docs fail to build with SQLAlchemy 0.9
** Also affects: oslo Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1296333 Title: Keystone docs fail to build with SQLAlchemy 0.9 Status in OpenStack Identity (Keystone): In Progress Status in Oslo - a Library of Common OpenStack Code: New Bug description: When using SQLAlchemy 0.9, the docs fail to build. This is preventing Keystone from moving up to SQLAlchemy 0.9. There's a commit to update keystone's requirements to SQLAlchemy 0.9 which is failing the docs build: https://review.openstack.org/#/c/82231/ The log there only shows the first failure. When I generate docs on my build system I get the following errors: sphinx.errors.SphinxWarning: /opt/stack/keystone/keystone/common/sql/__init__.py:docstring of keystone.common.sql.relationship:53: ERROR: Unknown interpreted text role paramref. sphinx.errors.SphinxWarning: /opt/stack/keystone/keystone/openstack/common/db/sqlalchemy/utils.py: docstring of keystone.openstack.common.db.sqlalchemy.utils.or_:26: WARNING: more than one target found for cross-reference u'and_': keystone.common.sql.core.and_, keystone.common.sql.and_ sphinx.errors.SphinxWarning: /opt/stack/keystone/keystone/openstack/common/db/sqlalchemy/utils.py: docstring of keystone.openstack.common.db.sqlalchemy.utils.select:12: WARNING: undefined label: coretutorial_selecting (if the link has no caption the label must precede a section header) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1296333/+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 1171601] Re: dbapi_use_tpool exposes problems in eventlet
After the patch https://review.openstack.org/#/c/60031/ (Remove eventlet tpool from common db.api) was merged, eventlet tpool is not used for work with database in Oslo code ** No longer affects: oslo -- 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/1171601 Title: dbapi_use_tpool exposes problems in eventlet Status in OpenStack Compute (Nova): Confirmed Bug description: The dbapi_use_tpool option doesn't work completely because of problems in eventlet. Even though this is technically an eventlet issue, it's important for Nova so this bug is to track the issue getting fixed in eventlet. There is a patch in progress here: https://bitbucket.org/eventlet/eventlet/pull-request/29/fix-use-of- semaphore-with-tpool-issue-137/diff To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1171601/+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 1288846] Re: Common context module missed in Glance
Agree, it sounds reasonable. ** Also affects: oslo Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1288846 Title: Common context module missed in Glance Status in OpenStack Image Registry and Delivery Service (Glance): Triaged Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: Common module glance.openstack.common.db.sqlalchemy.utils requires common context module [1] but this module missed in glance, so we get an error, when we try to use sqlalchemy.utils module. See an example at [2] [1] https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/utils.py#L41 [2] http://logs.openstack.org/77/43277/19/check/gate-glance-python27/a4b3b56/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1288846/+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 1288846] [NEW] Common context module missed in Glance
Public bug reported: Common module glance.openstack.common.db.sqlalchemy.utils requires common context module [1] but this module missed in glance, so we get an error, when we try to use sqlalchemy.utils module. See an example at [2] [1] https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/utils.py#L41 [2] http://logs.openstack.org/77/43277/19/check/gate-glance-python27/a4b3b56/console.html ** Affects: glance Importance: Undecided Status: New ** Tags: context db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1288846 Title: Common context module missed in Glance Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Common module glance.openstack.common.db.sqlalchemy.utils requires common context module [1] but this module missed in glance, so we get an error, when we try to use sqlalchemy.utils module. See an example at [2] [1] https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/utils.py#L41 [2] http://logs.openstack.org/77/43277/19/check/gate-glance-python27/a4b3b56/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1288846/+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 1252693] Re: Running of unit tests fails if SQLAlchemy = 0.8.3 is used
We have a similar code in Oslo-incubator, so we should fix it there as
well
** Also affects: oslo
Importance: Undecided
Status: New
--
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/1252693
Title:
Running of unit tests fails if SQLAlchemy = 0.8.3 is used
Status in OpenStack Compute (Nova):
In Progress
Status in Oslo - a Library of Common OpenStack Code:
New
Bug description:
If SQLAlchemy = 0.8.3 is used, running of unit tests fails. The
following error is printed to stderr multiple times:
DBError: (IntegrityError) constraint failed u'UPDATE
instance_system_metadata SET updated_at=?, deleted_at=?, deleted=?
WHERE instance_system_metadata.id = ?' ('2013- 11-19
10:37:44.378444', '2013-11-19 10:37:44.377819', 11, 11)
A few of our migrations change the type of deleted column from boolean
to int. MySQL and SQLite don't have native boolean data type.
SQLAlchemy uses int columns (e.g. in case of MySQL - tinyint) + CHECK
constraint (something like CHECK (deleted in (0, 1))) to emulate
boolean data type.
In our migrations when the type of column `deleted` is changed from
boolean to int, the corresponding CHECK constraint is dropped too. But
starting from SQLAlchemy version 0.8.3, those CHECK constraints aren't
dropped anymore. So despite the fact that column deleted is of type
int now, we still restrict its values to be either 0 or 1.
Migrations changing the data type of deleted columns rely on SQL
rendered for CHECK constraints (e.g.
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/152_change_type_of_deleted_column.py#L172).
There was a patch in SQLAlchemy 0.8.3 release that slightly changed
the way DDL statements are rendered
((http://docs.sqlalchemy.org/en/latest/changelog/changelog_08.html
#change-487183f04e6da9aa27d8817bca9906d1)). Unfortunately, due to the
fact that nova migrations depend on such implementation details, this
change to SQLAlchemy broke our code.
We must fix our migrations to work properly with new SQLAlchemy
versions too (0.8.3+).
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1252693/+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 1258166] Re: N310 check recommends function that doesn't exist
** Also affects: oslo Importance: Undecided Status: New -- 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/1258166 Title: N310 check recommends function that doesn't exist Status in OpenStack Compute (Nova): New Status in Oslo - a Library of Common OpenStack Code: New Bug description: Check N310 can return N310 timeutils.now() must be used instead of datetime.now(), but timeutils.now() does not exist. Only utcnow() does. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1258166/+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
