[Yahoo-eng-team] [Bug 1654409] [NEW] Duplicate users (federated and sql) results in 401
Public bug reported: Release: Mitaka I setup federation (saml2) with a product called vIDM which automatically has a user named "admin". I also have keystone configured to use a sql backend and have a user named "admin". These users exist on different domains (Federated) and (default), and have different user_ids, yet I cannot login with this federated user without a hard error: 2017-01-05 21:59:56.448 19546 DEBUG keystone.federation.utils [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] identity_values: [{u'group': {u'domain': {u'name': u'Default'}, u'name': u'Federated Users'}, u'user': {u'name': u'admin'}}] process /usr/lib/python2.7/dist-packages/keystone/federation/utils.py:543 2017-01-05 21:59:56.448 19546 DEBUG keystone.federation.utils [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] mapped_properties: {'group_ids': [], 'user': {'domain': {'id': 'Federated'}, 'type': 'ephemeral', u'name': u'admin'}, 'group_names': [{u'domain': {u'name': u'Default'}, u'name': u'Federated Users'}]} process /usr/lib/python2.7/dist-packages/keystone/federation/utils.py:545 2017-01-05 21:59:56.482 19546 WARNING keystone.common.wsgi [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] Authorization failed. Unable to reconcile identity attribute user_id as it has conflicting values 9b2dde9538864fc0ab7992bdbeb1f877 and e38f2348129a41d0940a29287c06a130 (Disable insecure_debug mode to suppress these details.) (Disable insecure_debug mode to suppress these details.) from 10.146.29.206 http://paste.openstack.org/show/594063/ ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1654409 Title: Duplicate users (federated and sql) results in 401 Status in OpenStack Identity (keystone): New Bug description: Release: Mitaka I setup federation (saml2) with a product called vIDM which automatically has a user named "admin". I also have keystone configured to use a sql backend and have a user named "admin". These users exist on different domains (Federated) and (default), and have different user_ids, yet I cannot login with this federated user without a hard error: 2017-01-05 21:59:56.448 19546 DEBUG keystone.federation.utils [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] identity_values: [{u'group': {u'domain': {u'name': u'Default'}, u'name': u'Federated Users'}, u'user': {u'name': u'admin'}}] process /usr/lib/python2.7/dist-packages/keystone/federation/utils.py:543 2017-01-05 21:59:56.448 19546 DEBUG keystone.federation.utils [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] mapped_properties: {'group_ids': [], 'user': {'domain': {'id': 'Federated'}, 'type': 'ephemeral', u'name': u'admin'}, 'group_names': [{u'domain': {u'name': u'Default'}, u'name': u'Federated Users'}]} process /usr/lib/python2.7/dist-packages/keystone/federation/utils.py:545 2017-01-05 21:59:56.482 19546 WARNING keystone.common.wsgi [req-1f592d70-2b6b-431f-9939-c2edd9a79a7f - - - - -] Authorization failed. Unable to reconcile identity attribute user_id as it has conflicting values 9b2dde9538864fc0ab7992bdbeb1f877 and e38f2348129a41d0940a29287c06a130 (Disable insecure_debug mode to suppress these details.) (Disable insecure_debug mode to suppress these details.) from 10.146.29.206 http://paste.openstack.org/show/594063/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1654409/+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 1657978] [NEW] Internal Server Error: KeyError: 'domain'
Public bug reported: I get the following message in Horizon when trying to authenticate a federated user with a misconfigured mapping (in Mitaka) {"error": {"message": "An unexpected error prevented the server from fulfilling your request: 'domain' (Disable insecure_debug mode to suppress these details.)", "code": 500, "title": "Internal Server Error"}} This is my mapping.json. Notice no domain is part of the "group" parameter (even though there is one at one level higher). [ { "local": [ { "domain": { "name": "Default" }, "group": { "name": "Federated Users" }, "user": { "name": "{0}", "email": "{1}" }, "groups": "{2}" } ], "remote": [ { "type": "REMOTE_USER" }, { "type": "MELLON_userEmail" }, { "type": "MELLON_groups" } ] } ] This is the log output of the keyerror containing the assertion. http://paste.openstack.org/show/595730/ ** Affects: keystone Importance: Undecided Assignee: Eric Brown (ericwb) Status: New ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1657978 Title: Internal Server Error: KeyError: 'domain' Status in OpenStack Identity (keystone): New Bug description: I get the following message in Horizon when trying to authenticate a federated user with a misconfigured mapping (in Mitaka) {"error": {"message": "An unexpected error prevented the server from fulfilling your request: 'domain' (Disable insecure_debug mode to suppress these details.)", "code": 500, "title": "Internal Server Error"}} This is my mapping.json. Notice no domain is part of the "group" parameter (even though there is one at one level higher). [ { "local": [ { "domain": { "name": "Default" }, "group": { "name": "Federated Users" }, "user": { "name": "{0}", "email": "{1}" }, "groups": "{2}" } ], "remote": [ { "type": "REMOTE_USER" }, { "type": "MELLON_userEmail" }, { "type": "MELLON_groups" } ] } ] This is the log output of the keyerror containing the assertion. http://paste.openstack.org/show/595730/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1657978/+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 1629460] Re: python35 values for http status codes not ints
Thanks Tin Lam, I'll mark invalid. ** Changed in: keystone Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1629460 Title: python35 values for http status codes not ints Status in OpenStack Identity (keystone): Invalid Bug description: The values of Python 3.5 http status codes via http_client.OK, for example, are enums not ints like in py27 and py34. This can cause potential trouble and the unit tests are catching the difference. Python 2.7/3.4 >>> from six.moves import http_client >>> http_client.BAD_REQUEST 400 Python 3.5 >>> from six.moves import http_client >>> http_client.BAD_REQUEST https://bitbucket.org/gutworth/six/issues/161/inconsistent-value-returned-from https://bugs.python.org/issue26123 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1629460/+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 1649440] Re: [vmware] vspere 6.5 have add some new OS type
6.5 OS updates was in https://review.openstack.org/#/c/403492 ** Changed in: nova Status: In Progress => Fix Released ** Changed in: nova Assignee: xhzhf (guoyongxhzhf) => Eric Brown (ericwb) ** Changed in: nova Importance: Undecided => Low -- 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/1649440 Title: [vmware] vspere 6.5 have add some new OS type Status in OpenStack Compute (nova): Fix Released Bug description: Description === vspere 6.5 have add some new OS type. Nova should support vsphere 6.5 and add constants Steps to reproduce == None Expected result === None Actual result = None Environment === vsphere 6.5 Logs & Configs == None To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1649440/+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 1622035] [NEW] Dead link in schema migration doc
Public bug reported: The online_schema_migration_examples.rst refers to a Database Schema Migrations doc which doesn't exist. In particular: For documentation on how to make online migrations move on to :ref:`Database Schema Migrations `. I could also not find any appropriate keystone doc for this to link to. Probably best to remove the sentence altogether. ** Affects: keystone Importance: Low Assignee: Eric Brown (ericwb) Status: New ** Changed in: keystone Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1622035 Title: Dead link in schema migration doc Status in OpenStack Identity (keystone): New Bug description: The online_schema_migration_examples.rst refers to a Database Schema Migrations doc which doesn't exist. In particular: For documentation on how to make online migrations move on to :ref:`Database Schema Migrations `. I could also not find any appropriate keystone doc for this to link to. Probably best to remove the sentence altogether. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1622035/+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 1629460] [NEW] python35 values for http status codes not ints
Public bug reported: The values of Python 3.5 http status codes via http_client.OK, for example, are enums not ints like in py27 and py35. This can cause potential trouble and the unit tests are catching the difference. Python 2.7/3.4 >>> from six.moves import http_client >>> http_client.BAD_REQUEST 400 Python 3.5 >>> from six.moves import http_client >>> http_client.BAD_REQUEST https://bitbucket.org/gutworth/six/issues/161/inconsistent-value-returned-from https://bugs.python.org/issue26123 ** Affects: keystone Importance: Undecided Assignee: Eric Brown (ericwb) Status: New ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1629460 Title: python35 values for http status codes not ints Status in OpenStack Identity (keystone): New Bug description: The values of Python 3.5 http status codes via http_client.OK, for example, are enums not ints like in py27 and py35. This can cause potential trouble and the unit tests are catching the difference. Python 2.7/3.4 >>> from six.moves import http_client >>> http_client.BAD_REQUEST 400 Python 3.5 >>> from six.moves import http_client >>> http_client.BAD_REQUEST https://bitbucket.org/gutworth/six/issues/161/inconsistent-value-returned-from https://bugs.python.org/issue26123 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1629460/+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 1599983] [NEW] Python 3.5 gate exposes issue in webob.response status code type
Public bug reported: Unit test keystone.tests.unit.test_wsgi.ApplicationTest.test_render_response_custom_status fails with the following error: ft274.18: keystone.tests.unit.test_wsgi.ApplicationTest.test_render_response_custom_status_StringException: pythonlogging:'': {{{ Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend. Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend. Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend. }}} Traceback (most recent call last): File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/webob/response.py", line 271, in _status__set status_code = int(value.split()[0]) ValueError: invalid literal for int() with base 10: 'HTTPStatus.NOT_IMPLEMENTED' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/tests/unit/test_wsgi.py", line 110, in test_render_response_custom_status status=(http_client.NOT_IMPLEMENTED, 'Not Implemented')) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/common/wsgi.py", line 770, in render_response headerlist=headers) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/webob/response.py", line 107, in __init__ self.status = status File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/webob/response.py", line 273, in _status__set raise ValueError('Invalid status code, integer required.') ValueError: Invalid status code, integer required. In some places we pass the status code as a str and others as an int http://logs.openstack.org/42/339142/2/check/gate-keystone-python35-db-nv/847ed7d/testr_results.html.gz ** Affects: keystone Importance: Undecided Assignee: Eric Brown (ericwb) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1599983 Title: Python 3.5 gate exposes issue in webob.response status code type Status in OpenStack Identity (keystone): In Progress Bug description: Unit test keystone.tests.unit.test_wsgi.ApplicationTest.test_render_response_custom_status fails with the following error: ft274.18: keystone.tests.unit.test_wsgi.ApplicationTest.test_render_response_custom_status_StringException: pythonlogging:'': {{{ Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend. Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend. Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend. }}} Traceback (most recent call last): File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/webob/response.py", line 271, in _status__set status_code = int(value.split()[0]) ValueError: invalid literal for int() with base 10: 'HTTPStatus.NOT_IMPLEMENTED' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/tests/unit/test_wsgi.py", line 110, in test_render_response_custom_status status=(http_client.NOT_IMPLEMENTED, 'Not Implemented')) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/common/wsgi.py", line 770, in render_response headerlist=headers) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/webob/response.py", line 107, in __init__ self.status = status File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/webob/response.py", line 273, in _status__set raise ValueError('Invalid status code, integer required.') ValueError: Invalid status code, integer required. In some places we pass the status code as a str and others as an int http://logs.openstack.org/42/339142/2/check/gate-keystone-python35-db-nv/847ed7d/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1599983/+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 1600393] [NEW] AttributeError: 'list' object has no attribute 'items'
Public bug reported: During a Rally test of our deployment using Mitaka keystone we observed the following traceback in the logs. It seems that the v3 catalog is returned as a list whereas the v2.0 catalog is a dict. But the format_catalog() function always expects a dict. 2016-07-06 03:00:55.171 18314 INFO eventlet.wsgi.server [req-5ebbe11b-5efb-4606-a46c-58f100a8a550 5716d29278b8438a95f718ea926e4e7a 954d6157b061441197b228ac7b4dd6ee - default default] 10.111.109.191,10.111.109.89 - - [06/Jul/2016 03:00:55] "DELETE /v2.0/tenants/37b1a3bad0e54dc2a9824ac51ba02a9f HTTP/1.1" 204 212 0.070017 2016-07-06 03:00:55.779 18323 DEBUG keystone.middleware.auth [req-9843ab92-0f8f-42b9-8b56-a5fc6d011569 - - - - -] There is either no auth token in the request or the certificate issuer is not trusted. No auth context will be set. _build_auth_context /usr/lib/python2.7/dist-packages/keystone/middleware/auth.py:71 2016-07-06 03:00:55.781 18323 INFO keystone.common.wsgi [req-9843ab92-0f8f-42b9-8b56-a5fc6d011569 - - - - -] POST http://10.111.109.81:5000/v2.0/tokens 2016-07-06 03:00:55.879 18323 INFO keystone.token.providers.fernet.utils [req-9843ab92-0f8f-42b9-8b56-a5fc6d011569 - - - - -] Loaded 2 encryption keys (max_active_keys=3) from: /etc/keystone/fernet-keys/ 2016-07-06 03:00:55.882 18323 INFO eventlet.wsgi.server [req-9843ab92-0f8f-42b9-8b56-a5fc6d011569 - - - - -] 10.111.109.191,10.111.109.89 - - [06/Jul/2016 03:00:55] "POST /v2.0/tokens HTTP/1.1" 200 3585 0.102872 2016-07-06 03:00:57.450 18323 DEBUG keystone.middleware.auth [req-57632939-e139-4dc7-a1f4-833ce4e84665 - - - - -] There is either no auth token in the request or the certificate issuer is not trusted. No auth context will be set. _build_auth_context /usr/lib/python2.7/dist-packages/keystone/middleware/auth.py:71 2016-07-06 03:00:57.452 18323 INFO keystone.common.wsgi [req-57632939-e139-4dc7-a1f4-833ce4e84665 - - - - -] POST http://10.111.109.81:5000/v2.0/tokens 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi [req-57632939-e139-4dc7-a1f4-833ce4e84665 - - - - -] 'list' object has no attribute 'items' 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 249, in __call__ 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi result = method(context, **params) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/oslo_log/versionutils.py", line 165, in wrapped 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi return func_or_cls(*args, **kwargs) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/controllers.py", line 144, in authenticate 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi auth_token_data, roles_ref=roles_ref, catalog_ref=catalog_ref) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/manager.py", line 124, in wrapped 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 360, in issue_v2_token 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi token_ref, roles_ref, catalog_ref) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/core.py", line 38, in issue_v2_token 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi *args, **kwargs) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 570, in issue_v2_token 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi token_ref, roles_ref, catalog_ref, trust_ref) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 163, in format_token 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi catalog_ref) 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 214, in format_catalog 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi for region, region_ref in catalog_ref.items(): 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi AttributeError: 'list' object has no attribute 'items' 2016-07-06 03:00:57.565 18323 ERROR keystone.common.wsgi 2016-07-06 03:00:57.570 18323 INFO eventlet.wsgi.server [req-57632939-e139-4dc7-a1f4-833ce4e84665 - - - - -] 10.111.109.191,10.111.109.89 - - [06/Jul/2016 03:00:57] "POST /v2.0/tokens HTTP/1.1" 500 400 0.120986 2016-07-06 03:00:58.181 18317 INFO keystone.token.providers.fernet.utils [req-7e2abf43-3cee-4335-a
[Yahoo-eng-team] [Bug 1600394] [NEW] ValueError: too many values to unpack
Public bug reported: Found the following error in the keystone logs of our Mitaka deployment. 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi [req-b256411d-ba72-4076-b644-ef08a5400ab2 66725b90caea4963b1b4f91f90ab1dee ab149973d5b84459bd3ece44074ec2aa - default default] too many values to unpack 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 249, in __call__ 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi result = method(context, **params) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line 156, in inner 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi context['subject_token_id'])) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/manager.py", line 124, in wrapped 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 208, in validate_token 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi token = self._validate_token(unique_id) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1053, in decorate 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi should_cache_fn) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 657, in get_or_create 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi async_creator) as value: 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, in __enter__ 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi return self._enter() 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98, in _enter 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi generated = self._enter_create(createdtime) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 149, in _enter_create 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi created = self.creator() 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 625, in gen_value 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi created_value = creator() 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1049, in creator 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi return fn(*arg, **kw) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 298, in _validate_token 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi return self.driver.validate_non_persistent_token(token_id) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 772, in validate_non_persistent_token 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi audit_info=audit_ids) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 526, in get_token_data 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi project_id, trust) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 469, in _populate_service_catalog 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi user_id, project_id) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/manager.py", line 124, in wrapped 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1053, in decorate 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi should_cache_fn) 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 657, in get_or_create 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi async_creator) as value: 2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, in __enter__ 2016-07-06 05:14:30.311 18314 ERROR keys
[Yahoo-eng-team] [Bug 1600395] [NEW] AttributeError: 'object' object has no attribute 'payload'
Public bug reported: When running Rally against our Mitaka deployment we found the following traceback in the logs. 2016-07-06 06:44:14.631 18323 DEBUG keystone.middleware.auth [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8b34ce - - - - -] There is either no auth token in the request or the certificate issuer is not trusted. No auth context will be set. _build_auth_context /usr/lib/python2.7/dist-packages/keystone/middleware/auth.py:71 2016-07-06 06:44:14.633 18323 INFO keystone.common.wsgi [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8b34ce - - - - -] POST http://10.111.109.81:5000/v2.0/tokens 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8b34ce - - - - -] 'object' object has no attribute 'payload' 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi Traceback (most recent call last): 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 249, in __call__ 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi result = method(context, **params) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/oslo_log/versionutils.py", line 165, in wrapped 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi return func_or_cls(*args, **kwargs) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/token/controllers.py", line 130, in authenticate 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi user_ref['id'], tenant_ref['id']) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/manager.py", line 124, in wrapped 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi __ret_val = __f(*args, **kwargs) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1053, in decorate 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi should_cache_fn) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 657, in get_or_create 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi async_creator) as value: 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, in __enter__ 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi return self._enter() 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 91, in _enter 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi value = value_fn() 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 610, in get_value 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi value = self.backend.get(key) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/cache/_context_cache.py", line 98, in get 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi self._set_local_cache(key, value) 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi File "/usr/lib/python2.7/dist-packages/keystone/common/cache/_context_cache.py", line 66, in _set_local_cache 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi serialize = {'payload': value.payload, 'metadata': value.metadata} 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi AttributeError: 'object' object has no attribute 'payload' 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi 2016-07-06 06:44:14.732 18323 INFO eventlet.wsgi.server [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8b34ce - - - - -] 10.111.109.191,10.111.109.89 - - [06/Jul/2016 06:44:14] "POST /v2.0/tokens HTTP/1.1" 500 400 0.102036 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1600395 Title: AttributeError: 'object' object has no attribute 'payload' Status in OpenStack Identity (keystone): New Bug description: When running Rally against our Mitaka deployment we found the following traceback in the logs. 2016-07-06 06:44:14.631 18323 DEBUG keystone.middleware.auth [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8b34ce - - - - -] There is either no auth token in the request or the certificate issuer is not trusted. No auth context will be set. _build_auth_context /usr/lib/python2.7/dist-packages/keystone/middleware/auth.py:71 2016-07-06 06:44:14.633 18323 INFO keystone.common.wsgi [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8b34ce - - - - -] POST http://10.111.109.81:5000/v2.0/tokens 2016-07-06 06:44:14.729 18323 ERROR keystone.common.wsgi [req-9b8bc44b-e7fa-4a6f-92fd-7a443d8
[Yahoo-eng-team] [Bug 1603236] [NEW] py35: TestCheckForMutableDefaultArgs fails
Public bug reported: The py35 gate fails on TestCheckForMutableDefaultArgs. http://logs.openstack.org/52/337952/7/check/gate-keystone-python35-db-nv/2e9682b/testr_results.html.gz ft125.1: keystone.tests.unit.test_hacking_checks.TestCheckForMutableDefaultArgs.test_StringException: Traceback (most recent call last): File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/tests/unit/test_hacking_checks.py", line 64, in test self.assert_has_errors(code, expected_errors=errors) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/tests/unit/test_hacking_checks.py", line 53, in assert_has_errors self.assertItemsEqual(expected_errors or [], actual_errors) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/unittest2/case.py", line 1182, in assertItemsEqual return self.assertSequenceEqual(expected, actual, msg=msg) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/unittest2/case.py", line 1014, in assertSequenceEqual self.fail(msg) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/unittest2/case.py", line 690, in fail raise self.failureException(msg) AssertionError: Sequences differ: [(7, [201 chars] 'K001'), (28, 27, 'K001'), (29, 21, 'K001'), (32, 11, 'K001')] != [(7, [201 chars] 'K001'), (28, 26, 'K001'), (29, 21, 'K001'), (32, 10, 'K001')] First differing element 12: (28, 27, 'K001') (28, 26, 'K001') [(7, 10, 'K001'), (10, 15, 'K001'), (10, 29, 'K001'), (13, 15, 'K001'), (16, 15, 'K001'), (16, 31, 'K001'), (22, 14, 'K001'), (22, 31, 'K001'), (22, 53, 'K001'), (25, 14, 'K001'), (25, 36, 'K001'), (28, 10, 'K001'), - (28, 27, 'K001'), ?^ + (28, 26, 'K001'), ?^ (29, 21, 'K001'), - (32, 11, 'K001')] ?^ + (32, 10, 'K001')] ?^ The root cause is a difference the in the ast node col_offset value. Python 3.4 and earlier were incorrect whereas 3.5 is fixed. It only affected two of the function definitions in the code sample. Here is a sample piece of code that illustrates the difference in the ast module between Pythong 3.5 and earlier versions: http://paste.openstack.org/show/532929/ ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1603236 Title: py35: TestCheckForMutableDefaultArgs fails Status in OpenStack Identity (keystone): New Bug description: The py35 gate fails on TestCheckForMutableDefaultArgs. http://logs.openstack.org/52/337952/7/check/gate-keystone-python35-db-nv/2e9682b/testr_results.html.gz ft125.1: keystone.tests.unit.test_hacking_checks.TestCheckForMutableDefaultArgs.test_StringException: Traceback (most recent call last): File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/tests/unit/test_hacking_checks.py", line 64, in test self.assert_has_errors(code, expected_errors=errors) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/keystone/tests/unit/test_hacking_checks.py", line 53, in assert_has_errors self.assertItemsEqual(expected_errors or [], actual_errors) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/unittest2/case.py", line 1182, in assertItemsEqual return self.assertSequenceEqual(expected, actual, msg=msg) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/unittest2/case.py", line 1014, in assertSequenceEqual self.fail(msg) File "/home/jenkins/workspace/gate-keystone-python35-db-nv/.tox/py35/lib/python3.5/site-packages/unittest2/case.py", line 690, in fail raise self.failureException(msg) AssertionError: Sequences differ: [(7, [201 chars] 'K001'), (28, 27, 'K001'), (29, 21, 'K001'), (32, 11, 'K001')] != [(7, [201 chars] 'K001'), (28, 26, 'K001'), (29, 21, 'K001'), (32, 10, 'K001')] First differing element 12: (28, 27, 'K001') (28, 26, 'K001') [(7, 10, 'K001'), (10, 15, 'K001'), (10, 29, 'K001'), (13, 15, 'K001'), (16, 15, 'K001'), (16, 31, 'K001'), (22, 14, 'K001'), (22, 31, 'K001'), (22, 53, 'K001'), (25, 14, 'K001'), (25, 36, 'K001'), (28, 10, 'K001'), - (28, 27, 'K001'), ?^ + (28, 26, 'K001'), ?^ (29, 21, 'K001'), - (32, 11, 'K001')] ?^ + (32, 10, 'K001')] ?^ The root cause is a difference the in the ast node col_offset value. Python 3.4 and earlier were incorrect whereas 3.5 is fixed. It only affected two of the function definitions in the code sample. Here is a sample piece of code that illustrates the difference in the ast module between Pythong 3.5 and earlier ver
[Yahoo-eng-team] [Bug 1607567] [NEW] domain configuration API docs missing domain config creation
Public bug reported: The domain configuration API documentation is missing information on how to create a domain config. The help for domain config mentions a PUT request, but the API for the PUT is missing. http://developer.openstack.org/api-ref/identity/v3/index.html?expanded =update-domain-configuration-detail#domain-configuration I also checked the code and there is support for creating a domain config via a PUT request. ** Affects: keystone Importance: Undecided Assignee: Eric Brown (ericwb) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1607567 Title: domain configuration API docs missing domain config creation Status in OpenStack Identity (keystone): In Progress Bug description: The domain configuration API documentation is missing information on how to create a domain config. The help for domain config mentions a PUT request, but the API for the PUT is missing. http://developer.openstack.org/api-ref/identity/v3/index.html?expanded =update-domain-configuration-detail#domain-configuration I also checked the code and there is support for creating a domain config via a PUT request. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1607567/+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 1473567] [NEW] Fernet tokens fail tempest runs
Public bug reported: It seems testing an OpenStack instance that was deployed with Fernet tokens fails on some of the tempest tests. In my case these tests failed: http://paste.openstack.org/show/363017/ bknudson also found similar in a test patch: https://review.openstack.org/#/c/195780 ** Affects: keystone Importance: Undecided Status: New ** Tags: fernet -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1473567 Title: Fernet tokens fail tempest runs Status in Keystone: New Bug description: It seems testing an OpenStack instance that was deployed with Fernet tokens fails on some of the tempest tests. In my case these tests failed: http://paste.openstack.org/show/363017/ bknudson also found similar in a test patch: https://review.openstack.org/#/c/195780 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1473567/+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 1474501] [NEW] Bad search filter: None in query
Public bug reported: Environment: Ubuntu 14.04 with stable/kilo openstack packages installed I configured keystone to have one domain ('Default') configured with SQL as the backend to service the service users. I configured a secondary domain ('ldap.vmware.com') to service all of the LDAP users. I did this using the multi-domain backend support. I was successful in creating users for the services (nova, cinder, glance, neutron, etc) and creating grants with admin role on service tenant. Then I need to grant the admin role on a admin project on the ldap domain. This is where things broke. In order to assign the admin role to the ldap user, I need to know the user id for the openstackclient. To do this, I used: openstack --os-identity-api-version 3 --os-url "http://localhost:35357/v3"; --os-token 52c6706iDcaDAf7u45se user show --domain ldap.vmware.com vio-autou...@vmware.com This command results in a 500 error from keystone. http://paste.openstack.org/show/375004/ The root cause is that there is a 'None' in the search filter. "(&None(userPrincipalName=vio-autou...@vmware.com))" Strangely, everything works perfectly if I stick with a single 'Default' domain with LDAP backend. It might be related to using the openstack CLI since that is also new in this environment. ** Affects: keystone 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/1474501 Title: Bad search filter: None in query Status in Keystone: New Bug description: Environment: Ubuntu 14.04 with stable/kilo openstack packages installed I configured keystone to have one domain ('Default') configured with SQL as the backend to service the service users. I configured a secondary domain ('ldap.vmware.com') to service all of the LDAP users. I did this using the multi-domain backend support. I was successful in creating users for the services (nova, cinder, glance, neutron, etc) and creating grants with admin role on service tenant. Then I need to grant the admin role on a admin project on the ldap domain. This is where things broke. In order to assign the admin role to the ldap user, I need to know the user id for the openstackclient. To do this, I used: openstack --os-identity-api-version 3 --os-url "http://localhost:35357/v3"; --os-token 52c6706iDcaDAf7u45se user show --domain ldap.vmware.com vio-autou...@vmware.com This command results in a 500 error from keystone. http://paste.openstack.org/show/375004/ The root cause is that there is a 'None' in the search filter. "(&None(userPrincipalName=vio-autou...@vmware.com))" Strangely, everything works perfectly if I stick with a single 'Default' domain with LDAP backend. It might be related to using the openstack CLI since that is also new in this environment. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1474501/+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 1474501] Re: Bad search filter: None in query
*** This bug is a duplicate of bug 1454309 *** https://bugs.launchpad.net/bugs/1454309 I have verified the fix in https://review.openstack.org/#/c/184824/ does fix my problem. Sorry, I missed the dup. Thanks again. ** This bug has been marked a duplicate of bug 1454309 Keystone v3 user/tenant lookup by name via OpenStack CLI client fails -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1474501 Title: Bad search filter: None in query Status in Keystone: Triaged Bug description: Environment: Ubuntu 14.04 with stable/kilo openstack packages installed I configured keystone to have one domain ('Default') configured with SQL as the backend to service the service users. I configured a secondary domain ('ldap.vmware.com') to service all of the LDAP users. I did this using the multi-domain backend support. I was successful in creating users for the services (nova, cinder, glance, neutron, etc) and creating grants with admin role on service tenant. Then I need to grant the admin role on a admin project on the ldap domain. This is where things broke. In order to assign the admin role to the ldap user, I need to know the user id for the openstackclient. To do this, I used: openstack --os-identity-api-version 3 --os-url "http://localhost:35357/v3"; --os-token 52c6706iDcaDAf7u45se user show --domain ldap.vmware.com vio-autou...@vmware.com This command results in a 500 error from keystone. http://paste.openstack.org/show/375004/ The root cause is that there is a 'None' in the search filter. "(&None(userPrincipalName=vio-autou...@vmware.com))" Strangely, everything works perfectly if I stick with a single 'Default' domain with LDAP backend. It might be related to using the openstack CLI since that is also new in this environment. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1474501/+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 1487960] [NEW] ValueError when creating a user
Public bug reported: The keystone.conf gives no guidelines as to the minimum and maximum values of crypt_strength in keystone.conf. If set too high or low, the user creation will fail. The min, max is defined in https://pythonhosted.org/passlib/lib/passlib.hash.sha512_crypt.html, but this info is not indicated in keystone. To recreate: - install devstack (I ran keystone without mod_wsgi in my case, don't think its relevant though) - change crypt_strength value to 500 in keystone.conf - login to horizon - click on Identity -> Users - click Create User - enter any values you want for the new user - Notice the creation of the user fails. The keystone log contains the following ValueError. http://paste.openstack.org/show/425692/ I believe similar errors would occur when setting admin_port, public_port, and pydev-debug-port outside the range of 1-65535 ** Affects: keystone Importance: Undecided Assignee: Eric Brown (ericwb) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1487960 Title: ValueError when creating a user Status in Keystone: In Progress Bug description: The keystone.conf gives no guidelines as to the minimum and maximum values of crypt_strength in keystone.conf. If set too high or low, the user creation will fail. The min, max is defined in https://pythonhosted.org/passlib/lib/passlib.hash.sha512_crypt.html, but this info is not indicated in keystone. To recreate: - install devstack (I ran keystone without mod_wsgi in my case, don't think its relevant though) - change crypt_strength value to 500 in keystone.conf - login to horizon - click on Identity -> Users - click Create User - enter any values you want for the new user - Notice the creation of the user fails. The keystone log contains the following ValueError. http://paste.openstack.org/show/425692/ I believe similar errors would occur when setting admin_port, public_port, and pydev-debug-port outside the range of 1-65535 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1487960/+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 1495645] [NEW] keystone-manage and keystone-all man pages incorrect versions/dates
Public bug reported: The manpages for keystone-manage and keystone-all still refer to older versions and release dates. The keystone-manage man page lists version as 2015.1 and date of 2015-10-15. The keystone-all man page lists version as 2014.2 and date of 2014-10-16. This is a Juno date, so there should probably also be a cherry-pick fix in Kilo. ** Affects: keystone Importance: Low Assignee: Eric Brown (ericwb) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) ** Changed in: keystone Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1495645 Title: keystone-manage and keystone-all man pages incorrect versions/dates Status in Keystone: In Progress Bug description: The manpages for keystone-manage and keystone-all still refer to older versions and release dates. The keystone-manage man page lists version as 2015.1 and date of 2015-10-15. The keystone-all man page lists version as 2014.2 and date of 2014-10-16. This is a Juno date, so there should probably also be a cherry-pick fix in Kilo. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1495645/+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 1497461] [NEW] Fernet tokens fail for some users with LDAP identity backend
Public bug reported: The following bug fixed most situations where when using Fernet + LDAP identify backend. https://bugs.launchpad.net/keystone/+bug/1459382 However, some users have trouble, resulting in a UserNotFound exception in the logs with a UUID. Here's the error: 2015-09-18 20:04:47.313 12979 WARNING keystone.common.wsgi [-] Could not find user: 457269632042726f776e203732363230 So the issue is this. The user DN query + filter will return my user as: CN=Eric Brown 72620,OU=PAO_Users,OU=PaloAlto_California_USA,OU=NALA,OU=SITES,OU=Engineering,DC=vmware,DC=com Therefore, I have to use CN as the user id attribute. My user id would therefore be "Eric Brown 72620". The fernet token_formatters.py attempts to convert this user id into a UUID. And in my case that is successful. It results in UUID of 457269632042726f776e203732363230. Of course, a user id of 457269632042726f776e203732363230 doesn't exist in LDAP, so as a result I get a UserNotFound. So I don't understand why the convert_uuid_bytes_to_hex is ever used in the case of LDAP backend. For other users, the token_formatters.convert_uuid_bytes_to_hex() raises a ValueError and everything works. Here's an example that illustrates the behavior >>> import uuid >>> uuid_obj = uuid.UUID(bytes='Eric Brown 72620') >>> uuid_obj.hex '457269632042726f776e203732363230' >>> import uuid >>> uuid_obj = uuid.UUID(bytes='Your Mama') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/uuid.py", line 144, in __init__ raise ValueError('bytes is not a 16-char string') ValueError: bytes is not a 16-char string Here's the complete traceback (after adding some additional debug): 2015-09-18 20:04:47.312 12979 WARNING keystone.common.wsgi [-] EWB Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 449, in __call__ response = self.process_request(request) File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line 238, in process_request auth_context = self._build_auth_context(request) File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line 218, in _build_auth_context token_data=self.token_provider_api.validate_token(token_id)) File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 198, in validate_token token = self._validate_token(unique_id) File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013, in decorate should_cache_fn) File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640, in get_or_create async_creator) as value: File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, in __enter__ return self._enter() File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98, in _enter generated = self._enter_create(createdtime) File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 149, in _enter_create created = self.creator() File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 612, in gen_value created_value = creator() File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1009, in creator return fn(*arg, **kw) File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 261, in _validate_token return self.driver.validate_v3_token(token_id) File "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/core.py", line 258, in validate_v3_token audit_info=audit_ids) File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 441, in get_token_data self._populate_user(token_data, user_id, trust) File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 275, in _populate_user user_ref = self.identity_api.get_user(user_id) File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line 342, in wrapper return f(self, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line 353, in wrapper return f(self, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013, in decorate should_cache_fn) File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640, in get_or_create async_creator) as value: File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, in __enter__ return self._enter() File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98, in _enter generated = self._enter_create(createdtime) File "/usr/lib/pytho
[Yahoo-eng-team] [Bug 1500631] [NEW] ldap url option actually supports multiple URIs
Public bug reported: The help text for the ldap.url config option states: "URL for connecting to the LDAP server." This implies only one URL can be specified. But actually, multiple may be specified due to the python-ldap module being used. The python-ldap module is basically a wrapper for the openldap client library. And if you look into the source, ldap.initialize() calls ldap_initialize() which supports multiple URIs in the URI string. And is easily found in the man page for ldap_initialize: ldap_initialize() acts like ldap_init(), but it returns an integer indicating either suc‐ cess or the failure reason, and it allows to specify details for the connection in the schema portion of the URI. The uri parameter may be a comma- or whitespace-separated list of URIs containing only the schema, the host, and the port fields. . So I did try comma separated ldap URLs in keystone, which worked as I would expect. It attempts connections with the first host and tries the next if it fails to bind. My simple example using python-ldap where there is no ldap server at localhost, but there is at ldaps.company.com l = ldap.initialize('ldap://localhost:389,ldaps://ldaps.company.com:636') l.simple_bind_s() (97, [], 1, []) The same works in keystone, so the keystone config help should be updated to show this is actually a supported option. Its very useful for deployers using AD where there is commonly redundancy using many domain controllers behind that one domain. Note: the whitespace-separated list did not work for me, only comma. ** Affects: keystone Importance: Low Assignee: Eric Brown (ericwb) Status: In Progress ** Tags: ldap ** Tags added: ldap -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1500631 Title: ldap url option actually supports multiple URIs Status in Keystone: In Progress Bug description: The help text for the ldap.url config option states: "URL for connecting to the LDAP server." This implies only one URL can be specified. But actually, multiple may be specified due to the python- ldap module being used. The python-ldap module is basically a wrapper for the openldap client library. And if you look into the source, ldap.initialize() calls ldap_initialize() which supports multiple URIs in the URI string. And is easily found in the man page for ldap_initialize: ldap_initialize() acts like ldap_init(), but it returns an integer indicating either suc‐ cess or the failure reason, and it allows to specify details for the connection in the schema portion of the URI. The uri parameter may be a comma- or whitespace-separated list of URIs containing only the schema, the host, and the port fields. . So I did try comma separated ldap URLs in keystone, which worked as I would expect. It attempts connections with the first host and tries the next if it fails to bind. My simple example using python-ldap where there is no ldap server at localhost, but there is at ldaps.company.com l = ldap.initialize('ldap://localhost:389,ldaps://ldaps.company.com:636') l.simple_bind_s() (97, [], 1, []) The same works in keystone, so the keystone config help should be updated to show this is actually a supported option. Its very useful for deployers using AD where there is commonly redundancy using many domain controllers behind that one domain. Note: the whitespace-separated list did not work for me, only comma. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1500631/+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 1393958] [NEW] VMware: HTTPInternalServerError (HTTP 500) using --location vsphere://
Public bug reported: If I run the following command to create a new image using glance CLI, the glance API server will throw a 500 error and exception in the logs. Looks like the code needs to be more robust on handling junk in the URI. glance image-create --location "vsphere://10.1.1.1/folder/images /openstack-template/openstack-template.vmdk" I think this occurs because I did not include ?dcpath=Datacenter/&dsName in the URI 2014-11-18 21:59:05.266 11866 INFO glance.wsgi.server [1dd339bd-bb0d-4ae1-a6cc-b3abc64a0644 3380f60eedc54f6eab23ed465b57b24c acbc0289cb974fee9e96e22674b7847f - - -] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 384, in handle_one_response result = self.application(self.environ, start_response) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func return self.func(req, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/glance/common/wsgi.py", line 378, in __call__ response = req.get_response(self.application) File "/usr/lib/python2.7/dist-packages/webob/request.py", line 1320, in send application, catch_exc_info=False) File "/usr/lib/python2.7/dist-packages/webob/request.py", line 1284, in call_application app_iter = application(self.environ, start_response) File "/usr/lib/python2.7/dist-packages/keystoneclient/middleware/auth_token.py", line 582, in __call__ return self.app(env, start_response) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func return self.func(req, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/glance/common/wsgi.py", line 378, in __call__ response = req.get_response(self.application) File "/usr/lib/python2.7/dist-packages/webob/request.py", line 1320, in send application, catch_exc_info=False) File "/usr/lib/python2.7/dist-packages/webob/request.py", line 1284, in call_application app_iter = application(self.environ, start_response) File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 206, in __call__ return app(environ, start_response) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ return resp(environ, start_response) File "/usr/lib/python2.7/dist-packages/routes/middleware.py", line 131, in __call__ response = self.app(environ, start_response) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 144, in __call__ return resp(environ, start_response) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 130, in __call__ resp = self.call_func(req, *args, **self.kwargs) File "/usr/lib/python2.7/dist-packages/webob/dec.py", line 195, in call_func return self.func(req, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/glance/common/wsgi.py", line 644, in __call__ request, **action_args) File "/usr/lib/python2.7/dist-packages/glance/common/wsgi.py", line 668, in dispatch return method(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/glance/common/utils.py", line 438, in wrapped return func(self, req, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/glance/api/v1/images.py", line 795, in create image_meta = self._reserve(req, image_meta) File "/usr/lib/python2.7/dist-packages/glance/api/v1/images.py", line 504, in _reserve store = get_store_from_location(location) File "/usr/lib/python2.7/dist-packages/glance/store/__init__.py", line 314, in get_store_from_location loc = location.get_location_from_uri(uri) File "/usr/lib/python2.7/dist-packages/glance/store/location.py", line 75, in get_location_from_uri store_location_class=scheme_info['location_class']) File "/usr/lib/python2.7/dist-packages/glance/store/location.py", line 116, in __init__ self.store_location.parse_uri(uri) File "/usr/lib/python2.7/dist-packages/glance/store/vmware_datastore.py", line 398, in parse_uri self.query = path[1] IndexError: list index out of range ** Affects: glance Importance: Undecided Status: New ** Tags: vmware -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1393958 Title: VMware: HTTPInternalServerError (HTTP 500) using --location vsphere:// Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: If I run the following command to create a new image using glance CLI, the glance API server will throw a 500 error and exception in the logs. Looks like the code needs to be more robust on handling junk in the URI. glance image-create --location "vsphere://10.1.1.1/folder/images /openstack-template/openstack-temp
[Yahoo-eng-team] [Bug 1253058] Re: Is there a way to make entire group as admin?
This bug is really a question. ** Changed in: keystone Status: New => Invalid ** Converted to question: https://answers.launchpad.net/keystone/+question/239528 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1253058 Title: Is there a way to make entire group as admin? Status in OpenStack Identity (Keystone): Invalid Bug description: Consider an use case, i have a group called "group1" in keystone and there are 1000 users and having a requirement to make every member as "admin" then should i go and map the admin role to every member in the group. Is there a way to make entire group as admin? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1253058/+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 1443598] [NEW] backend_argument containing a password leaked in logs
*** This bug is a security vulnerability *** Public security bug reported: The keystone.conf has an option backend_argument to set various options for the caching backend. As documented, some of the potential values can contain a password. Snippet from http://docs.openstack.org/developer/keystone/developing.html#dogpile- cache-based-mongodb-nosql-backend [cache] # Global cache functionality toggle. enabled = True # Referring to specific cache backend backend = keystone.cache.mongo # Backend specific configuration arguments backend_argument = db_hosts:localhost:27017 backend_argument = db_name:ks_cache backend_argument = cache_collection:cache backend_argument = username:test_user backend_argument = password:test_password As a result, passwords can be leaked to the keystone logs since the config options is not marked secret. ** Affects: keystone Importance: Undecided Assignee: Eric Brown (ericwb) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1443598 Title: backend_argument containing a password leaked in logs Status in OpenStack Identity (Keystone): In Progress Bug description: The keystone.conf has an option backend_argument to set various options for the caching backend. As documented, some of the potential values can contain a password. Snippet from http://docs.openstack.org/developer/keystone/developing.html#dogpile- cache-based-mongodb-nosql-backend [cache] # Global cache functionality toggle. enabled = True # Referring to specific cache backend backend = keystone.cache.mongo # Backend specific configuration arguments backend_argument = db_hosts:localhost:27017 backend_argument = db_name:ks_cache backend_argument = cache_collection:cache backend_argument = username:test_user backend_argument = password:test_password As a result, passwords can be leaked to the keystone logs since the config options is not marked secret. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1443598/+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 1443697] [NEW] VMware: resize always fails for image with capacity larger than 1 GB
aging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 298, in decorated_function 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 3506, in resize_instance 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher self.instance_events.clear_events_for_instance(instance) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/contextlib.py", line 35, in __exit__ 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher self.gen.throw(type, value, traceback) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 5613, in _error_out_instance_on_exception 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher raise error.inner_exception 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher ResizeError: Resize error: Unable to shrink disk. 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher 2015-04-13 23:32:10.678 9404 ERROR oslo.messaging._drivers.common [-] Returning exception Resize error: Unable to shrink disk. to caller It appears that nova compute will throw an error when attempting to resize an instance _from_ a flavor with disk size of 0 _to_ a flavor with disk size 0. The trick to reproducing this error is using any image that has a disk greater than 1 GB. I initially tested with cirros, tiny-iso, etc which are all less than 1 GB. The root cause of the problem is this code in vmops.py:1332 # Checks if the migration needs a disk resize down. if (flavor['root_gb'] < instance['root_gb'] or flavor['root_gb'] < vmdk.capacity_in_bytes / units.Gi): reason = _("Unable to shrink disk.") raise exception.InstanceFaultRollback( exception.ResizeError(reason=reason)) Dividing the capacity by 1 GB will result in 0 for any number less than 1 GB. However anything larger will be a positive integer. And the flavor size is always 0, so this exception is always raised in a resize of any image with capacity larger than 1 GB (which is most images). ** Affects: nova Importance: Undecided Assignee: Eric Brown (ericwb) 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/1443697 Title: VMware: resize always fails for image with capacity larger than 1 GB Status in OpenStack Compute (Nova): New Bug description: Resize will fail if using 0 disk flavors in combination with images that have disks larger than 1 GB. Steps to reproduce: 1. Create two new flavors with disk sizes of 0. tiny and small will do 2. Create an image with a disk larger than 1 GB 3. Boot this image with tiny.0 4. Resize this image to small.0 5. Notice Horizon says nothing and the resize does nothing 6. An exception is in the Nova compute logs (stacktrace from Icehouse, but believe also an issue in Kilo) 2015-04-13 23:32:10.676 9404 ERROR oslo.messaging.rpc.dispatcher [-] Exception during message handling: Resize error: Unable to shrink disk. 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 133, in _dispatch_and_reply 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 176, in _dispatch 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 122, in _do_dispatch 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/exception.py", line 88, in wrapped 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher payload) 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py", line 68, in __exit__ 2015-04-13 23:32:10.676 9404 TRACE oslo.messaging.rpc.dispatcher si
[Yahoo-eng-team] [Bug 1451605] [NEW] Ironic admin_auth_token option should be deprecated
Public bug reported: The ironic driver has config options for admin_username, admin_password, admin_auth_token so that the ironic client can authenticate using the keystoneclient. >From nova/virt/ironic/driver.py: cfg.StrOpt('admin_auth_token', help='Ironic keystone auth token.'), The keystoneclient has deprecated admin_auth_token since Icehouse (at least) and thus the ironic driver option should similarly be deprecated. The keystone admin token is intended only for bootstrapping keystone, no for other services to utilize. https://github.com/openstack/python- keystoneclient/blob/stable/icehouse/keystoneclient/middleware/auth_token.py#L244 cfg.StrOpt('admin_token', secret=True, help='This option is deprecated and may be removed in a future' ' release. Single shared secret with the Keystone configuration' ' used for bootstrapping a Keystone installation, or otherwise' ' bypassing the normal authentication process. This option' ' should not be used, use `admin_user` and `admin_password`' ' instead.'), ** Affects: nova Importance: Low Assignee: Eric Brown (ericwb) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Eric Brown (ericwb) ** Changed in: nova Importance: Undecided => Low -- 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/1451605 Title: Ironic admin_auth_token option should be deprecated Status in OpenStack Compute (Nova): In Progress Bug description: The ironic driver has config options for admin_username, admin_password, admin_auth_token so that the ironic client can authenticate using the keystoneclient. From nova/virt/ironic/driver.py: cfg.StrOpt('admin_auth_token', help='Ironic keystone auth token.'), The keystoneclient has deprecated admin_auth_token since Icehouse (at least) and thus the ironic driver option should similarly be deprecated. The keystone admin token is intended only for bootstrapping keystone, no for other services to utilize. https://github.com/openstack/python- keystoneclient/blob/stable/icehouse/keystoneclient/middleware/auth_token.py#L244 cfg.StrOpt('admin_token', secret=True, help='This option is deprecated and may be removed in a future' ' release. Single shared secret with the Keystone configuration' ' used for bootstrapping a Keystone installation, or otherwise' ' bypassing the normal authentication process. This option' ' should not be used, use `admin_user` and `admin_password`' ' instead.'), To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451605/+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 1276207] Re: vmware driver does not validate server certificates
** Also affects: glance Importance: Undecided Status: New ** Also affects: ceilometer 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/1276207 Title: vmware driver does not validate server certificates Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: Fix Committed Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Bug description: The VMware driver establishes connections to vCenter over HTTPS, yet the vCenter server certificate is not verified as part of the connection process. I know this because my vCenter server is using a self-signed certificate which always fails certification verification. As a result, someone could use a man-in-the-middle attack to spoof the vcenter host to nova. The vmware driver has a dependency on Suds, which I believe also does not validate certificates because hartsock and I noticed it uses urllib. For reference, here is a link on secure connections in OpenStack: https://wiki.openstack.org/wiki/SecureClientConnections Assuming Suds is fixed to provide an option for certificate verification, next step would be to modify the vmware driver to provide an option to override invalid certificates (such as self- signed). In other parts of OpenStack, there are options to bypass the certificate check with a "insecure" option set, or you could put the server's certificate in the CA store. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1276207/+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 1452066] [NEW] neutron-db-manage fails using mariadb fresh deployment
Public bug reported: In our deployment configuration we use ansible to deploy kilo neutron with a mariadb cluster. The neutron-db-manage command fails on 57086602ca0a, scrap_nsx_adv_svcs_models TASK: [config-controller | initialize neutron database] *** failed: [controller1] => {"changed": true, "cmd": ["neutron-db-manage", "--config-file", "/etc/neutron/neutron.conf", "--config-file", "/etc/neutron/plugins/vmware/dvs.ini", "upgrade", "head"], "delta": "0:00:04.490216", "end": "2015-05-05 22:36:24.185528", "rc": 1, "start": "2015-05-05 22:36:19.695312", "warnings": []} stderr: 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 28c0ffb8ebbd -> 57086602ca0a, scrap_nsx_adv_svcs_models 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 238, in main CONF.command.func(config, CONF.command.name) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 106, in do_upgrade do_alembic_command(config, cmd, revision, sql=CONF.command.sql) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 72, in do_alembic_command getattr(alembic_command, cmd)(config, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/alembic/command.py", line 165, in upgrade script.run_env() File "/usr/lib/python2.7/dist-packages/alembic/script.py", line 382, in run_env util.load_python_file(self.dir, 'env.py') File "/usr/lib/python2.7/dist-packages/alembic/util.py", line 241, in load_python_file module = load_module_py(module_id, path) File "/usr/lib/python2.7/dist-packages/alembic/compat.py", line 79, in load_module_py mod = imp.load_source(module_id, path, fp) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 109, in run_migrations_online() File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 100, in run_migrations_online context.run_migrations() File "", line 7, in run_migrations File "/usr/lib/python2.7/dist-packages/alembic/environment.py", line 742, in run_migrations self.get_context().run_migrations(**kw) File "/usr/lib/python2.7/dist-packages/alembic/migration.py", line 305, in run_migrations step.migration_fn(**kw) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/versions/57086602ca0a_scrap_nsx_adv_svcs_models.py", line 32, in upgrade op.drop_table('vcns_edge_pool_bindings') File "", line 7, in drop_table File "/usr/lib/python2.7/dist-packages/alembic/operations.py", line 962, in drop_table self._table(name, **kw) File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 191, in drop_table self._exec(schema.DropTable(table)) File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 106, in _exec return conn.execute(construct, *multiparams, **params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 729, in execute return meth(self, multiparams, params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/sql/ddl.py", line 69, in _execute_on_connection return connection._execute_ddl(self, multiparams, params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 783, in _execute_ddl compiled File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 958, in _execute_context context) File "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/compat/handle_error.py", line 261, in _handle_dbapi_exception e, statement, parameters, cursor, context) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1155, in _handle_dbapi_exception util.raise_from_cause(newraise, exc_info) File "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 199, in raise_from_cause reraise(type(exception), exception, tb=exc_tb) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 951, in _execute_context context) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 436, in do_execute cursor.execute(statement, parameters) File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py&q
[Yahoo-eng-team] [Bug 1460839] [NEW] bandit: blacklist_functions not a valid plugin
Public bug reported: Keystone currently has the keystone_conservative profile in bandit.yaml defined as follows: keystone_conservative: include: - blacklist_functions - blacklist_imports - request_with_no_cert_validation - exec_used - set_bad_file_permissions - subprocess_popen_with_shell_equals_true - linux_commands_wildcard_injection - ssl_with_bad_version The keystone_conservative profile is the default profile run when using bandit in the keystone project. The problem is that blacklist_functions is not actually a bandit plugin. There is a plugin called blacklist_calls, but not blacklist_functions. To recreate: - Edit bandit.yaml, comment out - '/tests/' in the exclude_dirs - Run 'tox -e bandit' - Notice you get no errors - Edit bandit.yaml again, search/replace blacklist_functions to blacklist_calls - Rerun 'tox -e bandit' - Notice you get an error now: >> Issue: Use of possibly insecure function - consider using safer >> ast.literal_eval. Severity: Medium Confidence: High Location: keystone/tests/unit/test_wsgi.py:104 103 resp = req.get_response(app) 104 self.assertIn('X-Foo', eval(resp.body)) 105 So basically, the blacklist_calls are never checked. ** Affects: keystone Importance: Low Assignee: Eric Brown (ericwb) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1460839 Title: bandit: blacklist_functions not a valid plugin Status in OpenStack Identity (Keystone): In Progress Bug description: Keystone currently has the keystone_conservative profile in bandit.yaml defined as follows: keystone_conservative: include: - blacklist_functions - blacklist_imports - request_with_no_cert_validation - exec_used - set_bad_file_permissions - subprocess_popen_with_shell_equals_true - linux_commands_wildcard_injection - ssl_with_bad_version The keystone_conservative profile is the default profile run when using bandit in the keystone project. The problem is that blacklist_functions is not actually a bandit plugin. There is a plugin called blacklist_calls, but not blacklist_functions. To recreate: - Edit bandit.yaml, comment out - '/tests/' in the exclude_dirs - Run 'tox -e bandit' - Notice you get no errors - Edit bandit.yaml again, search/replace blacklist_functions to blacklist_calls - Rerun 'tox -e bandit' - Notice you get an error now: >> Issue: Use of possibly insecure function - consider using safer ast.literal_eval. Severity: Medium Confidence: High Location: keystone/tests/unit/test_wsgi.py:104 103 resp = req.get_response(app) 104 self.assertIn('X-Foo', eval(resp.body)) 105 So basically, the blacklist_calls are never checked. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1460839/+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 1466957] [NEW] keystone configuration docs missing some keystone-manage commands
Public bug reported: The keystone configuration docs are missing info on all of the keystone- manage commands. See http://docs.openstack.org/developer/keystone/configuration.html #initializing-keystone Missing are: domain_config_upload fernet_rotate fernet_setup However, the man page for keystone-manage does contain info. ? domain_config_upload: Upload domain configuration file. ? fernet_rotate: Rotate keys in the Fernet key repository. ? fernet_setup: Setup a Fernet key repository. ** Affects: keystone Importance: Low Assignee: Eric Brown (ericwb) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Eric Brown (ericwb) ** Changed in: keystone Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1466957 Title: keystone configuration docs missing some keystone-manage commands Status in OpenStack Identity (Keystone): In Progress Bug description: The keystone configuration docs are missing info on all of the keystone-manage commands. See http://docs.openstack.org/developer/keystone/configuration.html #initializing-keystone Missing are: domain_config_upload fernet_rotate fernet_setup However, the man page for keystone-manage does contain info. ? domain_config_upload: Upload domain configuration file. ? fernet_rotate: Rotate keys in the Fernet key repository. ? fernet_setup: Setup a Fernet key repository. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1466957/+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 1339342] [NEW] VMware: boot from sparse image results in OS not found
Public bug reported: I am attempting to boot an instance from the cirros image found here: http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.2-i386-disk.vmdk So I originally imported the image without setting any of the vmware properties. So when I go to boot from this image, I get "Operating System not found" in the VM. This was my user error, so I then used the glance command line image- update to set those properties after the image was already created. Then I tried another boot from this image. I got the same result, "Operating System not found". However, if I set the properties for the image at image-create time, everything works. It also works if I do not boot the image before doing an image-update. So definitely seems as though some of the metadata is cached. To Recreate: - use glance image-create to import image: http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.2-i386-disk.vmdk (do not set any of the vmware_* properties. - boot from this image, notice it fails to find the OS as expected - use glance image-update to modify the image metadata so that it properly has the --property vmware_adaptertype="ide" --property vmware_disktype="sparse" set. - boot from this image again, notice it still fails, which is unexpected. ** Affects: nova Importance: Medium Assignee: Arnaud Legendre (arnaudleg) Status: New ** Tags: vmware -- 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/1339342 Title: VMware: boot from sparse image results in OS not found Status in OpenStack Compute (Nova): New Bug description: I am attempting to boot an instance from the cirros image found here: http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.2-i386-disk.vmdk So I originally imported the image without setting any of the vmware properties. So when I go to boot from this image, I get "Operating System not found" in the VM. This was my user error, so I then used the glance command line image- update to set those properties after the image was already created. Then I tried another boot from this image. I got the same result, "Operating System not found". However, if I set the properties for the image at image-create time, everything works. It also works if I do not boot the image before doing an image-update. So definitely seems as though some of the metadata is cached. To Recreate: - use glance image-create to import image: http://partnerweb.vmware.com/programs/vmdkimage/cirros-0.3.2-i386-disk.vmdk (do not set any of the vmware_* properties. - boot from this image, notice it fails to find the OS as expected - use glance image-update to modify the image metadata so that it properly has the --property vmware_adaptertype="ide" --property vmware_disktype="sparse" set. - boot from this image again, notice it still fails, which is unexpected. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1339342/+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 1274294] [NEW] vmware section of nova.conf describes host_ip as url but is not
Public bug reported: In nova.conf, the host_ip of the vmware section describes it as being a URL. But the expected input is a hostname or IP address, not a URL. A URL is composed of a scheme, two colons, etc. See http://en.wikipedia.org/wiki/Uniform_resource_locator https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L3265 [vmware] # # Options defined in nova.virt.vmwareapi.driver # # URL for connection to VMware ESX/VC host. (string value) #host_ip= # Username for connection to VMware ESX/VC host. (string # value) #host_username= # Password for connection to VMware ESX/VC host. (string # value) #host_password= Also here: https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L49 ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1274294 Title: vmware section of nova.conf describes host_ip as url but is not Status in OpenStack Compute (Nova): New Bug description: In nova.conf, the host_ip of the vmware section describes it as being a URL. But the expected input is a hostname or IP address, not a URL. A URL is composed of a scheme, two colons, etc. See http://en.wikipedia.org/wiki/Uniform_resource_locator https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L3265 [vmware] # # Options defined in nova.virt.vmwareapi.driver # # URL for connection to VMware ESX/VC host. (string value) #host_ip= # Username for connection to VMware ESX/VC host. (string # value) #host_username= # Password for connection to VMware ESX/VC host. (string # value) #host_password= Also here: https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/driver.py#L49 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1274294/+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 1276207] [NEW] vmware driver does not validate server certificates
Public bug reported: The VMware driver establishes connections to vCenter over HTTPS, yet the vCenter server certificate is not verified as part of the connection process. I know this because my vCenter server is using a self-signed certificate which always fails certification verification. As a result, someone could use a man-in-the-middle attack to spoof the vcenter host to nova. The vmware driver has a dependency on Suds, which I believe also does not validate certificates because hartsock and I noticed it uses urllib. For reference, here is a link on secure connections in OpenStack: https://wiki.openstack.org/wiki/SecureClientConnections Assuming Suds is fixed to provide an option for certificate verification, next step would be to modify the vmware driver to provide an option to override invalid certificates (such as self-signed). In other parts of OpenStack, there are options to bypass the certificate check with a "insecure" option set, or you could put the server's certificate in the CA store. ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1276207 Title: vmware driver does not validate server certificates Status in OpenStack Compute (Nova): New Bug description: The VMware driver establishes connections to vCenter over HTTPS, yet the vCenter server certificate is not verified as part of the connection process. I know this because my vCenter server is using a self-signed certificate which always fails certification verification. As a result, someone could use a man-in-the-middle attack to spoof the vcenter host to nova. The vmware driver has a dependency on Suds, which I believe also does not validate certificates because hartsock and I noticed it uses urllib. For reference, here is a link on secure connections in OpenStack: https://wiki.openstack.org/wiki/SecureClientConnections Assuming Suds is fixed to provide an option for certificate verification, next step would be to modify the vmware driver to provide an option to override invalid certificates (such as self- signed). In other parts of OpenStack, there are options to bypass the certificate check with a "insecure" option set, or you could put the server's certificate in the CA store. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1276207/+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 1229941] Re: Generate sample config file
Looks like this bug was resolved with: https://review.openstack.org/#/c/73698/ ** Changed in: keystone Status: Confirmed => Fix Released ** Changed in: keystone Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1229941 Title: Generate sample config file Status in OpenStack Identity (Keystone): Fix Committed Bug description: Nova has the ability to generate it's equivalent of etc/keystone.conf.sample based on the default values set in the config files. Keystone should look at porting this. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1229941/+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 1287209] [NEW] VMware: boot from image: exception on close
Public bug reported: Noticed the following exception in the logs when booting from an image. I didn't observe any actual problems with the spawn itself. It works as expected, so not sure when this exception occurs. 2014-03-03 06:55:48.840 DEBUG nova.virt.vmwareapi.read_write_util [req- b1cb95b5-e250-4258-83bd-267a481174d1 admin demo] Exception during HTTP connection close in VMwareHTTPWrite. Exception is from (pid=4533) close /opt/stack/nova/nova/virt/vmwareapi/read_write_util.py:150 Also the exception stack trace isn't printed. To recreate: - create a glance image using glance image-create --name cirros-sparse --is-public=True --container-format=bare --disk-format=vmdk --property vmware_disktype="sparse" < disk-vmdk.vmdk https://www.dropbox.com/s/793n37blb4ra3t6/disk-vmdk.vmdk - login to horizon and boot from the newly created image. - wait for the instance to turn to active and examine the logs ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1287209 Title: VMware: boot from image: exception on close Status in OpenStack Compute (Nova): New Bug description: Noticed the following exception in the logs when booting from an image. I didn't observe any actual problems with the spawn itself. It works as expected, so not sure when this exception occurs. 2014-03-03 06:55:48.840 DEBUG nova.virt.vmwareapi.read_write_util [req-b1cb95b5-e250-4258-83bd-267a481174d1 admin demo] Exception during HTTP connection close in VMwareHTTPWrite. Exception is from (pid=4533) close /opt/stack/nova/nova/virt/vmwareapi/read_write_util.py:150 Also the exception stack trace isn't printed. To recreate: - create a glance image using glance image-create --name cirros-sparse --is-public=True --container-format=bare --disk-format=vmdk --property vmware_disktype="sparse" < disk-vmdk.vmdk https://www.dropbox.com/s/793n37blb4ra3t6/disk-vmdk.vmdk - login to horizon and boot from the newly created image. - wait for the instance to turn to active and examine the logs To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1287209/+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 1287292] [NEW] VMware: vim.get_soap_url improper IPv6 address
Public bug reported: The vim.get_soap_url function incorrectly builds an IPv6 using hostname/IP address and port. https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/vim.py#L151 The result of this line would create an address as follows: https://[2001:db8:85a3:8d3:1319:8a2e:370:7348:443]/sdk Ports should be outside the square brackets, not inside, as follows: https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/sdk For reference see: http://en.wikipedia.org/wiki/IPv6_address section Literal IPv6 addresses in network resource identifiers ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1287292 Title: VMware: vim.get_soap_url improper IPv6 address Status in OpenStack Compute (Nova): New Bug description: The vim.get_soap_url function incorrectly builds an IPv6 using hostname/IP address and port. https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/vim.py#L151 The result of this line would create an address as follows: https://[2001:db8:85a3:8d3:1319:8a2e:370:7348:443]/sdk Ports should be outside the square brackets, not inside, as follows: https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/sdk For reference see: http://en.wikipedia.org/wiki/IPv6_address section Literal IPv6 addresses in network resource identifiers To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1287292/+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 1287209] Re: VMware: boot from image: exception on close
After updating my devstack, I could no longer reproduce it. But I'll keep an eye out for it. ** Changed in: nova Status: In Progress => Invalid ** Changed in: nova Assignee: Eric Brown (ericwb) => (unassigned) -- 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/1287209 Title: VMware: boot from image: exception on close Status in OpenStack Compute (Nova): Invalid Bug description: Noticed the following exception in the logs when booting from an image. I didn't observe any actual problems with the spawn itself. It works as expected, so not sure when this exception occurs. 2014-03-03 06:55:48.840 DEBUG nova.virt.vmwareapi.read_write_util [req-b1cb95b5-e250-4258-83bd-267a481174d1 admin demo] Exception during HTTP connection close in VMwareHTTPWrite. Exception is from (pid=4533) close /opt/stack/nova/nova/virt/vmwareapi/read_write_util.py:150 Also the exception stack trace isn't printed. To recreate: - create a glance image using glance image-create --name cirros-sparse --is-public=True --container-format=bare --disk-format=vmdk --property vmware_disktype="sparse" < disk-vmdk.vmdk https://www.dropbox.com/s/793n37blb4ra3t6/disk-vmdk.vmdk - login to horizon and boot from the newly created image. - wait for the instance to turn to active and examine the logs To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1287209/+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 1424061] Re: keystone server should default to localhost-only
** Also affects: ceilometer Importance: Undecided Status: New ** Changed in: ceilometer Status: New => In Progress ** Changed in: ceilometer Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1424061 Title: keystone server should default to localhost-only Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Identity (Keystone): In Progress Bug description: By default keystone will listen on all interfaces. Keystone should use secure defaults. In this case, listen on localhost-only by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1424061/+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 1423973] Re: Use choices from oslo_config
** Also affects: python-keystoneclient Importance: Undecided Status: New ** Changed in: python-keystoneclient Importance: Undecided => Wishlist ** Changed in: python-keystoneclient Assignee: (unassigned) => Eric Brown (ericwb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1423973 Title: Use choices from oslo_config Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: Support went into oslo_config recently that will allow us to use the choices keyword argument from argparse [1]. We should look at leveraging this in Keystone. [1] https://github.com/openstack/oslo.config/blame/578f9f4e60f58c210a9e1cb455925b9f310fe10e/oslo_config/cfg.py#L932 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1423973/+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 1423973] Re: Use choices from oslo_config
** No longer affects: python-keystoneclient ** Also affects: keystonemiddleware Importance: Undecided Status: New ** Changed in: keystonemiddleware Assignee: (unassigned) => Eric Brown (ericwb) ** Changed in: keystonemiddleware Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1423973 Title: Use choices from oslo_config Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Identity (Keystone) Middleware: New Bug description: Support went into oslo_config recently that will allow us to use the choices keyword argument from argparse [1]. We should look at leveraging this in Keystone. [1] https://github.com/openstack/oslo.config/blame/578f9f4e60f58c210a9e1cb455925b9f310fe10e/oslo_config/cfg.py#L932 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1423973/+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 1423973] Re: Use choices from oslo_config
** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Importance: Undecided => Wishlist ** Changed in: nova Assignee: (unassigned) => Eric Brown (ericwb) ** Changed in: nova Status: New => In Progress ** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => Eric Brown (ericwb) -- 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/1423973 Title: Use choices from oslo_config Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Identity (Keystone) Middleware: In Progress Status in OpenStack Compute (Nova): In Progress Bug description: Support went into oslo_config recently that will allow us to use the choices keyword argument from argparse [1]. We should look at leveraging this in Keystone. [1] https://github.com/openstack/oslo.config/blame/578f9f4e60f58c210a9e1cb455925b9f310fe10e/oslo_config/cfg.py#L932 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1423973/+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 1588472] [NEW] tox -e genconfig - maximum recursion depth exceeded
Public bug reported: When running 'tox -e genconfig' on stable/mitaka of neutron, I get the following (running on Ubuntu 14.04): File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 913, in _replace_env env_list = self.getdict('setenv') File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 839, in getdict s = self.getstring(name, None) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 893, in getstring x = self._replace(x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 993, in _replace return RE_ITEM_REF.sub(self._replace_match, x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 913, in _replace_env env_list = self.getdict('setenv') File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 839, in getdict s = self.getstring(name, None) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 893, in getstring x = self._replace(x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 993, in _replace return RE_ITEM_REF.sub(self._replace_match, x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 913, in _replace_env env_list = self.getdict('setenv') File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 839, in getdict s = self.getstring(name, None) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 893, in getstring x = self._replace(x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 993, in _replace return RE_ITEM_REF.sub(self._replace_match, x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 959, in _replace_substitution val = self._substitute_from_other_section(sub_key) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 941, in _substitute_from_other_section if section in self._cfg and item in self._cfg[section]: File "/usr/lib/python2.7/dist-packages/py/_iniconfig.py", line 151, in __getitem__ return SectionWrapper(self, name) RuntimeError: maximum recursion depth exceeded while calling a Python object ** 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/1588472 Title: tox -e genconfig - maximum recursion depth exceeded Status in neutron: New Bug description: When running 'tox -e genconfig' on stable/mitaka of neutron, I get the following (running on Ubuntu 14.04): File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 913, in _replace_env env_list = self.getdict('setenv') File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 839, in getdict s = self.getstring(name, None) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 893, in getstring x = self._replace(x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 993, in _replace return RE_ITEM_REF.sub(self._replace_match, x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 913, in _replace_env env_list = self.getdict('setenv') File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 839, in getdict s = self.getstring(name, None) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 893, in getstring x = self._replace(x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 993, in _replace return RE_ITEM_REF.sub(self._replace_match, x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 989, in _replace_match return handler(match) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 913, in _replace_env env_list = self.getdict('setenv') File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 839, in getdict s = self.getstring(name, None) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 893, in getstring x = self._replace(x) File "/usr/local/lib/python2.7/dist-packages/tox/config.py", line 993, in _replace return RE_ITEM_REF.sub(self._replace_match, x) File "/usr/local/lib
[Yahoo-eng-team] [Bug 1289062] Re: LDAP read only config options are ignored
These are used. I recently fixed a bug that is related. See https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L298 ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1289062 Title: LDAP read only config options are ignored Status in OpenStack Identity (Keystone): Invalid Bug description: The LDAP configuration includes a number of options such as: [ldap] user_allow_create = False user_allow_update = False user_allow_delete = False tenant_allow_create = True tenant_allow_update = True tenant_allow_delete = True role_allow_create = True role_allow_update = True role_allow_delete = True From what i can gather these were added in the Essex release but are currently being completely ignored. We either need to enforce these values or remove them from the configuration files as they are misleading to our users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1289062/+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 1295381] [NEW] VMware: resize operates on orig VM and not clone
Public bug reported: The resize operation when using the VCenter driver ends up resizing the original VM and not the newly cloned VM. To recreate: 1) create a new VM from horizon using default debian image. I use a flavor of nano. 2) wait for it to complete and go active 3) click on resize and choose a flavor larger than what you used originally. i then usually choose a flavor of small. 4) wait for horizon to prompt you to confirm or revert the migration. 5) Switch over to vSphere Web Client. Notice two VMs for your newly created instance. One with a UUID name and the other with a UUID-orig name. "-orig" indicating the original. 6) Notice the original has be resized (cpu and mem are increased, disk is not, but that's a separate bug) and not the new clone. This is problem #1. 7) Now hit confirm in horizon. It works, but the logs contain a warning: "The attempted operation cannot be performed in the current state (Powered on).". I suspect its attempting to destroy the orig VM, but the orig was the VM resized and powered on, so it fails. This is problem #2. Results in a leaked VM. ** Affects: nova Importance: High Assignee: Sidharth Surana (ssurana) Status: New ** Tags: icehouse-rc-potential vmware ** Changed in: nova Assignee: (unassigned) => Sidharth Surana (ssurana) ** Description changed: The resize operation when using the VCenter driver ends up resizing the original VM and not the newly cloned VM. To recreate: 1) create a new VM from horizon using default debian image. I use a flavor of nano. 2) wait for it to complete and go active 3) click on resize and choose a flavor larger than what you used originally. i then usually choose a flavor of small. 4) wait for horizon to prompt you to confirm or revert the migration. - 5) Switch over to vSphere Web Client. Notice two VMs for your newly created instance. One with a UUID name and the other with a UUID-orig name. "-orig" indicating the original. + 5) Switch over to vSphere Web Client. Notice two VMs for your newly created instance. One with a UUID name and the other with a UUID-orig name. "-orig" indicating the original. 6) Notice the original has be resized (cpu and mem are increased, disk is not, but that's a separate bug) and not the new clone. This is problem #1. 7) Now hit confirm in horizon. It works, but the logs contain a warning: "The attempted operation cannot be performed in the current state (Powered on).". I suspect its attempting to destroy the orig VM, but the orig was the VM resized and powered on, so it fails. This is problem #2. + Results in a leaked VM. -- 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/1295381 Title: VMware: resize operates on orig VM and not clone Status in OpenStack Compute (Nova): New Bug description: The resize operation when using the VCenter driver ends up resizing the original VM and not the newly cloned VM. To recreate: 1) create a new VM from horizon using default debian image. I use a flavor of nano. 2) wait for it to complete and go active 3) click on resize and choose a flavor larger than what you used originally. i then usually choose a flavor of small. 4) wait for horizon to prompt you to confirm or revert the migration. 5) Switch over to vSphere Web Client. Notice two VMs for your newly created instance. One with a UUID name and the other with a UUID-orig name. "-orig" indicating the original. 6) Notice the original has be resized (cpu and mem are increased, disk is not, but that's a separate bug) and not the new clone. This is problem #1. 7) Now hit confirm in horizon. It works, but the logs contain a warning: "The attempted operation cannot be performed in the current state (Powered on).". I suspect its attempting to destroy the orig VM, but the orig was the VM resized and powered on, so it fails. This is problem #2. Results in a leaked VM. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1295381/+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 1301626] Re: Same Keypairs accessible in multiple projects assigned to same user
SSH keys are tied to the user, not project. Users span across projects, but not keystone domains. I see nothing wrong in the current behavior. ** Changed in: nova Status: New => Opinion -- 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/1301626 Title: Same Keypairs accessible in multiple projects assigned to same user Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Compute (Nova): Opinion Bug description: If I have two projects assigned to the same user in Horizon Dashboard. Each project has a separate ID, separate set of VMs and different floating IPs and different security rules assigned. But, The Keypairs are being shared for both the projects are the same. This is causing an issue since this implies that I can access VMs belonging to different projects using the same key pair. Also, i cannot add new keypairs for a particular project as its becoming visible in both the projects. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1301626/+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 1289627] Re: VMware NoPermission faults do not log what permission was missing
** Also affects: oslo.vmware Importance: Undecided Status: New ** Changed in: oslo.vmware Status: New => In Progress ** Changed in: oslo.vmware Assignee: (unassigned) => Eric Brown (ericwb) -- 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/1289627 Title: VMware NoPermission faults do not log what permission was missing Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: In Progress Bug description: NoPermission object has a privilegeId that tells us which permission the user did not have. Presently the VMware nova driver does not log this data. This is very useful for debugging user permissions problems on vCenter or ESX. http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.fault.NoPermission.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1289627/+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 1452066] Re: neutron-db-manage fails using mariadb fresh deployment
** 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/1452066 Title: neutron-db-manage fails using mariadb fresh deployment Status in neutron: Invalid Bug description: In our deployment configuration we use ansible to deploy kilo neutron with a mariadb cluster. The neutron-db-manage command fails on 57086602ca0a, scrap_nsx_adv_svcs_models TASK: [config-controller | initialize neutron database] *** failed: [controller1] => {"changed": true, "cmd": ["neutron-db-manage", "--config-file", "/etc/neutron/neutron.conf", "--config-file", "/etc/neutron/plugins/vmware/dvs.ini", "upgrade", "head"], "delta": "0:00:04.490216", "end": "2015-05-05 22:36:24.185528", "rc": 1, "start": "2015-05-05 22:36:19.695312", "warnings": []} stderr: 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 28c0ffb8ebbd -> 57086602ca0a, scrap_nsx_adv_svcs_models 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 238, in main CONF.command.func(config, CONF.command.name) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 106, in do_upgrade do_alembic_command(config, cmd, revision, sql=CONF.command.sql) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 72, in do_alembic_command getattr(alembic_command, cmd)(config, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/alembic/command.py", line 165, in upgrade script.run_env() File "/usr/lib/python2.7/dist-packages/alembic/script.py", line 382, in run_env util.load_python_file(self.dir, 'env.py') File "/usr/lib/python2.7/dist-packages/alembic/util.py", line 241, in load_python_file module = load_module_py(module_id, path) File "/usr/lib/python2.7/dist-packages/alembic/compat.py", line 79, in load_module_py mod = imp.load_source(module_id, path, fp) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 109, in run_migrations_online() File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 100, in run_migrations_online context.run_migrations() File "", line 7, in run_migrations File "/usr/lib/python2.7/dist-packages/alembic/environment.py", line 742, in run_migrations self.get_context().run_migrations(**kw) File "/usr/lib/python2.7/dist-packages/alembic/migration.py", line 305, in run_migrations step.migration_fn(**kw) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/versions/57086602ca0a_scrap_nsx_adv_svcs_models.py", line 32, in upgrade op.drop_table('vcns_edge_pool_bindings') File "", line 7, in drop_table File "/usr/lib/python2.7/dist-packages/alembic/operations.py", line 962, in drop_table self._table(name, **kw) File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 191, in drop_table self._exec(schema.DropTable(table)) File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 106, in _exec return conn.execute(construct, *multiparams, **params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 729, in execute return meth(self, multiparams, params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/sql/ddl.py", line 69, in _execute_on_connection return connection._execute_ddl(self, multiparams, params) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 783, in _execute_ddl compiled File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 958, in _execute_context context) File "/usr/lib/python2.7/dist-packages/oslo_db/sqlalchemy/compat/handle_error.py", line 261, in _handle_dbapi_exception e, statement, parameters, cursor, context) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1155, in _handle_dbapi_exception util.raise_from_cause(newraise, exc_info) File "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 199, in raise_from_cause reraise(type(exception), exception, tb=exc_tb) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 951, in _execute_context context) File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 436, in do_execute cursor.execute(statement, parameters) File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute