[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
