[Yahoo-eng-team] [Bug 1373961] Re: Missing version attribute while generating K2K SAML assertion
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1373961 Title: Missing version attribute while generating K2K SAML assertion Status in OpenStack Identity (Keystone): Fix Released Bug description: In Keystone2Keystone federation Assertion XML object is missing attribute 'version' which makes Shibboleth Service Providers complain badly. This parameter should be statically set to string value '2.0' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1373961/+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 1375597] [NEW] exception will kill router rescheduling call
Public bug reported: An encountered exception in the router rescheduling loop will cause the loop to terminate and not be tried again. Retries should continue at the normal interval. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Assignee: (unassigned) = Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1375597 Title: exception will kill router rescheduling call Status in OpenStack Neutron (virtual network service): New Bug description: An encountered exception in the router rescheduling loop will cause the loop to terminate and not be tried again. Retries should continue at the normal interval. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1375597/+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 1365678] Re: Sync with openstack/requirements
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1365678
Title:
Sync with openstack/requirements
Status in OpenStack Identity (Keystone):
Fix Released
Status in Oslo test framework and fixture library:
Fix Released
Bug description:
Our last sync with openstack/requirements was around the beginning of
August. We haven't been able to sync because we have unit test
failures on the sync job since around August 20th:
https://review.openstack.org/#/c/111620/
Likely, our tests need to be fixed to support whatever dependency is
breaking us.
Traceback (most recent call last):
File
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 1404, in stop
return self.__exit__()
File
/home/jenkins/workspace/gate-keystone-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py,
line 1376, in __exit__
raise RuntimeError('stop called on unstarted patcher')
RuntimeError: stop called on unstarted patcher
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1365678/+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 1373113] Re: Deleting a domain group assignment using a non-domain-aware identity backend (e.g. LDAP) fails
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1373113 Title: Deleting a domain group assignment using a non-domain-aware identity backend (e.g. LDAP) fails Status in OpenStack Identity (Keystone): Fix Released Bug description: When deleting a domain group assignment using a not domain-aware backend, such as LDAP, we should get an exception like: 'NotImplemented: Domain metadata not supported by LDAP', as we have for user assignments. However, trying to delete an assignment of such type, we get: Traceback (most recent call last): File keystone/assignment/core.py, line 570, in delete_grant domain_id): File keystone/common/manager.py, line 47, in wrapper return f(self, *args, **kwargs) File keystone/identity/core.py, line 202, in wrapper return f(self, *args, **kwargs) File keystone/identity/core.py, line 213, in wrapper return f(self, *args, **kwargs) File keystone/identity/core.py, line 816, in list_users_in_group self._mark_domain_id_filter_satisfied(hints) File keystone/identity/core.py, line 526, in _mark_domain_id_filter_satisfied for filter in hints.filters: AttributeError: 'str' object has no attribute 'filters' Pointers to the code are [1][2][3]. This occurs because we pass the domain_id (of type str) as it was a hint (of type driver_hints.Hints) on [1]. A patch to this bug should create a driver_hints.Hints() object with domain_id as a filter of it and pass it as argument, instead of passing domain_id directly. [1] https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L569-L570 [2] https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L813-L816 [3] https://github.com/openstack/keystone/blob/master/keystone/identity/core.py#L526 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1373113/+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 1365169] Re: Endpoint grouping extension does handle deletion callbacks
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1365169 Title: Endpoint grouping extension does handle deletion callbacks Status in OpenStack Identity (Keystone): Fix Released Bug description: If a project or endpoint group is deleted, the endpoint grouping extension should respond by deleting associated data. Instead, stale data remains in the backend. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1365169/+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 1365787] Re: LDAP group role assignment becomes user assignment
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1365787
Title:
LDAP group role assignment becomes user assignment
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
When I configure Keystone with the LDAP backend, creating a group role
assignment winds up being a user role assignment.
Here's steps to recreate:
Start with devstack configured to use LDAP
$ openstack group create blktest1
+---+--+
| Field | Value
|
+---+--+
| domain_id | default
|
| id| 33888a7d75274497bb1e7a05fc17a748
|
| links | {u'self':
u'http://192.168.122.176:5000/v3/groups/33888a7d75274497bb1e7a05fc17a748'} |
| name | blktest1
|
+---+--+
$ GROUP_ID=33888a7d75274497bb1e7a05fc17a748
$ openstack role list
| 1fbe54e498ad483cb900735715926032 | anotherrole |
$ ROLE_ID=1fbe54e498ad483cb900735715926032
$ openstack project list
| 111681b688eb4460b464745f461ad0ce | demo |
PROJECT_ID=111681b688eb4460b464745f461ad0ce
# Get a token since I can't find an openstack command to add role
assignment...
$ curl ...
$ TOKEN=PKIZ...
# Create the GROUP role assignment
$ curl -i -X PUT -H X-Auth-Token: $TOKEN \
http://localhost:35357/v3/projects/$PROJECT_ID/groups/$GROUP_ID/roles/$ROLE_ID
HTTP/1.1 204 No Content
# Check the results. Now it's a user role assignment.
$ openstack role assignment list
+--+--+---+--++
| Role | User | Group
| Project | Domain |
+--+--+---+--++
| 9fe2ff9ee4384b1894a90878d3e92bab | 6e045e61b335473f9806460fcbf06b08 |
| 4b78eb4768924d8ba492e53eecddf493 ||
| 29b0254e79d141d1a342086fd772e5f4 | 6e045e61b335473f9806460fcbf06b08 |
| 4b78eb4768924d8ba492e53eecddf493 ||
| 9fe2ff9ee4384b1894a90878d3e92bab | 8fa4aa9d5584421eb8fa22ad01ff806a |
| 111681b688eb4460b464745f461ad0ce ||
| 04b98b07af274304b19ce3e7d18de881 | 8fa4aa9d5584421eb8fa22ad01ff806a |
| 111681b688eb4460b464745f461ad0ce ||
| 29b0254e79d141d1a342086fd772e5f4 | 6e045e61b335473f9806460fcbf06b08 |
| 111681b688eb4460b464745f461ad0ce ||
| 1fbe54e498ad483cb900735715926032 | 8fa4aa9d5584421eb8fa22ad01ff806a |
| 111681b688eb4460b464745f461ad0ce ||
| 1fbe54e498ad483cb900735715926032 | 33888a7d75274497bb1e7a05fc17a748 |
| 111681b688eb4460b464745f461ad0ce ||
| 04b98b07af274304b19ce3e7d18de881 | 8fa4aa9d5584421eb8fa22ad01ff806a |
| 7dee56223a5d43169ba1c5a2ac8ec412 ||
+--+--+---+--++
# Also check the REST response since maybe it's in openstack command:
$ curl -H X-Auth-Token: $TOKEN
http://localhost:5000/v3/role_assignments | python -mjson.tool
...
{
links: {
assignment:
http://192.168.122.176:5000/v3/projects/111681b688eb4460b464745f461ad0ce/users/33888a7d75274497bb1e7a05fc17a748/roles/1fbe54e498ad483cb900735715926032;
},
role: {
id: 1fbe54e498ad483cb900735715926032
},
scope: {
project: {
id: 111681b688eb4460b464745f461ad0ce
}
},
user: {
id: 33888a7d75274497bb1e7a05fc17a748
}
},
...
It's got user where it should be group.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1365787/+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 1360446] Re: client connection leak to memcached under eventlet due to threadlocal
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1360446 Title: client connection leak to memcached under eventlet due to threadlocal Status in OpenStack Identity (Keystone): Fix Released Status in Keystone icehouse series: Triaged Status in OpenStack Identity (Keystone) Middleware: Fix Released Bug description: When Keystone configured with memcached as backend and token storage keystone didn't reuse connections to it and starting to fail after having more than 500 connections to the memcached. Steps to reproduce: 1. Configure keystone with memcached as backend. 2. Create moreless good load (creating of VM's creates a lot of connections) on keystone and watch for connections to memcached using netstat, ex. netstat -an |grep -c :11211 Expected behavior: connections number should be reasonable and be not more that the number of connections to the keystone (ideally :) Observed bahavior: Number of connections growing and seems than 1. They didn't reused at all. 2. Lifetime of some connection is 600 seconds. 3. It looks like not all the connections stay for 600 seconds. UPDATE from MorganFainberg This is specific to deploying under eventlet and the python-memcached library and it's explicit/unavoidable use of threadlocal. Use of threadlocal under eventlet causes the client connections to leak until the GC / kernel cleans up the connections. This was confirmed to only affect eventlet with patch threading. Keystone deployed under apache is not affected. All services deployed with keystonemiddleware that utilize eventlet and memcache for token cache are also affected. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1360446/+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 1363019] Re: test_versions.py is currently breaking pep8 in master
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1363019 Title: test_versions.py is currently breaking pep8 in master Status in OpenStack Identity (Keystone): Fix Released Bug description: Somehow a set of bad aligned '}' has got into master in test_versions.py, which is causing every patch to fail. This fixes it. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363019/+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 1361230] Re: ad248f6 jsonutils sync breaks if simplejson 2.2.0 (under python 2.6)
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1361230 Title: ad248f6 jsonutils sync breaks if simplejson 2.2.0 (under python 2.6) Status in OpenStack Telemetry (Ceilometer): Fix Committed Status in OpenStack Identity (Keystone): Fix Released Status in The Oslo library incubator: Fix Released Status in Oslo library for sending and saving object: Fix Released Status in Taskflow for task-oriented systems.: Fix Committed Bug description: This keystone sync: https://github.com/openstack/keystone/commit/94efafd6d6066f63a9226a6b943d0e86699e7edd Pulled in this change to jsonutils: https://review.openstack.org/#/c/113760/ That uses a flag in json.dumps which is only in simplejson = 2.2.0. If you don't have a new enough simplejson the keystone database migrations fail. Keystone doesn't even list simplejson as a requirement and oslo- incubator lists simplejson = 2.0.9 as a test-requirement since it's optional in the code. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1361230/+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 1361306] Re: Keystone doesn't handle user_attribute_id mapping
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1361306 Title: Keystone doesn't handle user_attribute_id mapping Status in OpenStack Identity (Keystone): Fix Released Bug description: By default keystone gets the id from first field of DN. It doesn't use user_id_attibute mapping from keystone.conf In the following code, id attribute is always 1 element in DN ---Relevent code--- https://github.com/openstack/keystone/blob/de2c6e15b9f45969c307ac6d1f634d933537aeaa/keystone/common/ldap/core.py#L1277-L1304 @staticmethod def _dn_to_id(dn): return utf8_decode(ldap.dn.str2dn(utf8_encode(dn))[0][0][1]) def _ldap_res_to_model(self, res): obj = self.model(id=self._dn_to_id(res[0])) # LDAP attribute names may be returned in a different case than # they are defined in the mapping, so we need to check for keys # in a case-insensitive way. We use the case specified in the # mapping for the model to ensure we have a predictable way of # retrieving values later. lower_res = dict((k.lower(), v) for k, v in six.iteritems(res[1])) for k in obj.known_keys: if k in self.attribute_ignore: continue try: v = lower_res[self.attribute_mapping.get(k, k).lower()] except KeyError: pass else: try: obj[k] = v[0] except IndexError: obj[k] = None return obj To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1361306/+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 1363917] Re: Links in `Configuring Federation` documentation return 404
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1363917 Title: Links in `Configuring Federation` documentation return 404 Status in OpenStack Identity (Keystone): Fix Released Bug description: In Configuring Federation documentation section all the external links are break https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst#configuring-federation I think there is only one link (python-openstackclient) right, all other are break, I mean, linked to 404 Page Not Found. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363917/+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 1343579] Re: Versionless GET on keystone gives different answer with port 5000 and 35357
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1343579 Title: Versionless GET on keystone gives different answer with port 5000 and 35357 Status in OpenStack Identity (Keystone): Fix Released Bug description: On a system with both v2/v3 (devstack), using 35357 shows only v3. 5000: versions xmlns=http://docs.openstack.org/identity/api/v2.0; version status=stable updated=2013-03-06T00:00:00Z id=v3.0 media-types media-type base=application/json type=application/vnd.openstack.identity-v3+json/ media-type base=application/xml type=application/vnd.openstack.identity-v3+xml/ /media-types links link href=http://devstack-neutron:5000/v3/; rel=self/ /links /version version status=stable updated=2014-04-17T00:00:00Z id=v2.0 media-types media-type base=application/json type=application/vnd.openstack.identity-v2.0+json/ media-type base=application/xml type=application/vnd.openstack.identity-v2.0+xml/ /media-types links link href=http://devstack-neutron:5000/v2.0/; rel=self/ link href=http://docs.openstack.org/; type=text/html rel=describedby/ /links link href=http://devstack-neutron:5000/v2.0/; rel=self/ link href=http://docs.openstack.org/; type=text/html rel=describedby/ /version /versions 35357: versions xmlns=http://docs.openstack.org/identity/api/v2.0; version status=stable updated=2013-03-06T00:00:00Z id=v3.0 media-types media-type base=application/json type=application/vnd.openstack.identity-v3+json/ media-type base=application/xml type=application/vnd.openstack.identity-v3+xml/ /media-types links link href=http://devstack-neutron:35357/v3/; rel=self/ /links /version /versions To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1343579/+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 1340041] Re: OpenLDAP 2.3: naming attribute [...] is not present in entry; Naming violation
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1340041
Title:
OpenLDAP 2.3: naming attribute [...] is not present in entry; Naming
violation
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
My keystone server is hosted on RHEL 6.4
The keystone version from rpm -qa is openstack-
keystone-2014.1-0.3.b2.el6.noarch
I am working with LDAP backend and have defined following:
- a user: authadmin (objectclass: Inetorgperson)
- a tenant: authentication (objectclass: groupOfNames)
- a role: admin (objectclass: organizationalRole)
My keystone.conf snippet is:
user_tree_dn = ou=Users,ou=OpenStack,dc=ldap,dc=com
user_objectclass = inetOrgPerson
user_id_attribute = uid
user_name_attribute = uid
tenant_tree_dn = ou=Customers,ou=OpenStack,dc=ldap,dc=com
tenant_objectclass = groupOfNames
tenant_id_attribute = cn
tenant_name_attribute = cn
role_tree_dn = ou=Roles,ou=OpenStack,dc=ldap,dc=com
role_objectclass = organizationalRole
role_id_attribute = cn
role_name_attribute = cn
While assigning 'admin' role to 'authadmin' user under tenant
'authentication' I get the following error
keystone user-role-add --user authadmin --role admin --tenant authentication
An unexpected error prevented the server from fulfilling your request.
{'info': naming attribute 'cn' is not present in entry, 'desc': 'Naming
violation'} (HTTP 500)
Looking at the network traffic I could see that ldapadd request is for
the dn: cn=admin,ou=authentication,ou=openstack,dc=ldap,dc=com
with 2 attributes:
objectclass: organizationalRole
roleOccupant: uid=authadmin,ou=users,ou=openstack,dc=ldap,dc=com
And since the 'cn' is missing which is the mandatory attribute for
organizationalRole objectclass, I am observing this failure.
If I use a new OpenLDAP server, say slapd 2.4.23, this works fine. The
LDAP server automatically adds the 'cn' attribute which is mentioned
in the 'dn'. Active Directory is also behaving in the similar way
Now I am unable to conclude if this is an OpenLDAP bug or a keystone
bug. Why is keystone not adding the 'cn' attribute in the ldapadd
request ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1340041/+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 1332666] Re: Poor performance on delete_tokens due to missing indexes
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1332666 Title: Poor performance on delete_tokens due to missing indexes Status in OpenStack Identity (Keystone): Fix Released Bug description: Due to user deletion (e.g. when heat deletes a temporary user) all tokens in the active token list need to be scanned to match the user_id. Similarly, tokens that need to match the trust_id require a scan of all active tokens. This causes an issue as we select all the columns (especially the extra column that contains a significant amount of data). At 15000 active tokens it is not impossible to load 15000x10k of token data for the scan. Under some circumstances this will cause a lot of work to be done, fill up buffers, and return 0 active tokens. Indexes on the user_id and trust_id columns in the token table solve this issue. The issue primarily is seen when it locks up either an eventlet worker or a mod_wsgi process (as the DB queries do not yield to other coroutines in eventlet when using MySQLDB or consume the resources for the mod_wsgi worker until the results are returned). The query looks like: SELECT token.id AS token_id, token.expires AS token_expires, token.extra AS token_extra, token.valid AS token_valid, token.user_id AS token_user_id, token.trust_id AS token_trust_id FROM token WHERE token.valid = 1 AND token.expires '2014-06-19 23:18:48.196884' AND token.user_id = 'f6d9db238d084998aaef92ce425edff0'; This query most of the time uses the index idx_token_expires which results in too many rows.Some times depending on the load using this index matches more than 5 rows in our performance run which is as good as full table scan. As the queries in question use user_id in the where clause, the above query can be optimized by adding index on user_id. The same performance run after adding the index on user_id doesn't show any degradation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1332666/+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 1321378] Re: keystone user-role-delete operation fails when user no longer exists in backend
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1321378 Title: keystone user-role-delete operation fails when user no longer exists in backend Status in OpenStack Identity (Keystone): Fix Released Bug description: When using an external user catalog (in our case, AD), if the user is removed on the backend catalog, the user-role-* keystone CLI commands no longer work, because keystone cannot look up the user. The specific situation is a user had been granted roles on some projects, but then that user left the company and was removed from the backend directory. When going back to remove the roles assigned to that user, the keystone commands fail. It may still be possible to do these operations directly through the API, I didn't check that. But ultimately was able to work around it by directly removing the entries in the keystone user_project_metadata table. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1321378/+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 1217017] Re: Can't use sql as domain-specific driver
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1217017
Title:
Can't use sql as domain-specific driver
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
File “/keystone/common/dependency.py” has a method named “requires”
which is a decorator for the “Assignment” class of both files
“/keystone/assignment/backends/ldap.py” and
“/keystone/assignment/backends/sql.py”.
File “/keystone/assignment/backends/ldap.py”:
@dependency.requires('identity_api')
class Assignment(assignment.Driver):
File “/keystone/assignment/backends/sql.py”:
@dependency.requires('identity_api')
class Assignment(sql.Base, assignment.Driver):
When I specify the following contents for file
“/etc/keystone/domains/keystone.Default.conf” I am telling Keystone to
use an SQL backend for the default domain:
[assignment]
driver = keystone.assignment.backends.sql.Assignment
[identity]
driver = keystone.identity.backends.sql.Identity
[ldap]
However, there is a problem with the following line in method requires
of file “dependency.py”:
def wrapper(self, *args, **kwargs):
Inject each dependency from the registry.
self.__wrapped_init__(*args, **kwargs)
for dependency in self._dependencies:
if dependency not in REGISTRY:
if dependency in _future_dependencies:
_future_dependencies[dependency] += [self]
else:
_future_dependencies[dependency] = [self]
continue
setattr(self, dependency, REGISTRY[dependency])
because it is passing arguments to the constructor of the Assignment
class in file “/keystone/assignment/backends/sql.py” which extends the
sql.Base class (i.e. class Base(object) of file
“/keystone/common/sql/core.py“) that extends class “object” which does
not accept any parameters for its constructor. It took me a full day
to pin this one down.
To get around this problem I added the following lines to class
Base(object) of file “/keystone/common/sql/core.py“ in order to accept
any number of parameters:
def __init__(self, *args, **kwargs):
super(Base, self).__init__()
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1217017/+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 1262360] Re: Unable to delete domain if user from other domain was added
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1262360
Title:
Unable to delete domain if user from other domain was added
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
I tried a use case where I
1. Have list of users (in the LDAP) in the default domain
2. Create domain
3. Add member role to user for the new domain
4. Remove role
5. Try do delete domain
And there I got the problem
{domain: {enabled: false, id: 5bc213efd70e4ec197c8a85350b127e3,
links: {self:
http://127.0.0.1:5000/v3/domains/5bc213efd70e4ec197c8a85350b127e3}, name:
test-domain}}Delete domain
HTTP/1.1 500 Internal Server Error
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 450
Date: Wed, 18 Dec 2013 19:47:47 GMT
{error: {message: An unexpected error prevented the server from
fulfilling your request. (IntegrityError) (1451, 'Cannot delete or
update a parent row: a foreign key constraint fails
(`keystone`.`user_domain_metadata`, CONSTRAINT
`user_domain_metadata_ibfk_2` FOREIGN KEY (`domain_id`) REFERENCES
`domain` (`id`))') 'DELETE FROM domain WHERE domain.id = %s'
('5bc213efd70e4ec197c8a85350b127e3',), code: 500, title:
Internal Server Error}}List domains
mysql select * from domain where id=5bc213efd70e4ec197c8a85350b127e3;
+--+-+-+---+
| id | name| enabled | extra |
+--+-+-+---+
| 5bc213efd70e4ec197c8a85350b127e3 | test-domain | 0 | {}|
+--+-+-+---+
1 row in set (0.00 sec)
mysql select * from user_domain_metadata;
+--+--+---+
| user_id | domain_id| data
|
+--+--+---+
| d0c8e779e094463cabc425f1d222e7e0 | 5bc213efd70e4ec197c8a85350b127e3 |
{roles: []} |
+--+--+---+
1 row in set (0.00 sec)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1262360/+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 1292283] Re: revocation events: deleting a token revokes all tokens with same expiration
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1292283 Title: revocation events: deleting a token revokes all tokens with same expiration Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Identity (Keystone): Fix Released Bug description: As part of the design process for revocation events it was determined that a mechanism to revoke all dependent tokens was needed. This covers the case of revoking a token and ensuring all tokens that were created from that token are also revoked. To accomplish this, the revocation of a specific token is done by expiration_time. The expiration_time attribute is never changed on subsequent tokens. This means it is easy to ensure revocation of an entire chain of tokens. This poses an issue if any specific token (or all tokens that are a child of a specific token) should be revoked, but the parent tokens should not be revoked. Use case: Get Unscoped token Get Scoped Token from Unscoped token Get New Scoped Token Revoke first unscoped token Now all tokens (including the Unscoped token) are revoked because they share an expiration_time. Likely there needs to be a solution that allows for revoking based upon expiration_time and issued_at and one that revokes on expiration_time alone. Revoking by expiration_time alone is API incompatible with previous API mechanisms (both V2 and V3). This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099 was identified. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1292283/+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 1282355] Re: ldap/core deleteTree not always supported
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1282355 Title: ldap/core deleteTree not always supported Status in OpenStack Identity (Keystone): Fix Released Bug description: Not every LDAP server supports CONTROL_TREEDELETE (OID 1.2.840.113556.1.4.805) e.g. openldap, 389 The LDAP server will respond with ldap.NOT_ALLOWED_ON_NONLEAF in that case, and the client will have to fallback on a recursive delete (note this is what openldap ldapdelete -r does). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1282355/+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 1222675] Re: LDAP Identity Driver does not call delete_user or delete_group on the LDAP assignment api
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1222675 Title: LDAP Identity Driver does not call delete_user or delete_group on the LDAP assignment api Status in OpenStack Identity (Keystone): Fix Released Bug description: Likely the call to assignment_api.delete_user and assignment_api.delete_group should be moved to the identity manager to ensure it is called every time, the user_ref should also be passed to the assignment_api instead of just the user_id so that the assignment_api has no need to do a lookup via identity_api (if required). The kvs identity driver does not call delete_user on assignment_api. The kvs identity driver does not call delete_group on assignment_api. The ldap identity driver does not call delete_group on assignment_api. Tests should be added as well to confirm the assignment_api methods are called. Related: Should delete_user called with the PAM identity driver still call assignment_api.delete_user? It would seem logical that it could be used to cleanup all assignments, and just handle the NotImplemented deletion from the identity store. If this is a valid use-case, the PAM identity driver does not call assignment_api.delete_user or delete_group when expected. This might also just warrant a deprecation of the PAM backend for a more feature-rich backend (such as SSSD/IPA) and ignore this shortcoming. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1222675/+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 1372956] Re: Wrong idp_metadata_path parameter group
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1372956 Title: Wrong idp_metadata_path parameter group Status in OpenStack Identity (Keystone): Fix Released Bug description: federation.controllers.SAMLMetadataV3.get_metadata() method expects parameter CONF.federation.idp_metadata_path whereas the right parameter is CONF.saml.idp_metadata_path. Controllers should be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1372956/+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 1371620] Re: Setting up database schema with db_sync fails in migration 039 (SQLITE)
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1371620 Title: Setting up database schema with db_sync fails in migration 039 (SQLITE) Status in OpenStack Identity (Keystone): Fix Released Status in “keystone” package in Ubuntu: Fix Released Bug description: A fresh clone of master (commit ee4ee3b7f570d448f9053547febd86591e600697) won't set up the database. On a fresh install of ubuntu 12.04.3 (yes, I know, but it's what I had kicking about) in a VM (Vmware), with no special config except for web proxies (excluding localhost) I followed http://docs.openstack.org/developer/keystone/setup.html and, once able to import keystone http://docs.openstack.org/developer/keystone/developing.html up to the point of running bin/keystone-manage db_sync this last command results in a stack trace as follows: (.venv)david@ubuntu:~/keystone$ bin/keystone-manage db_sync 2014-09-19 06:54:16.321 12991 CRITICAL keystone [-] OperationalError: (OperationalError) database is locked u'DELETE FROM user_project_metadata' () 2014-09-19 06:54:16.321 12991 TRACE keystone Traceback (most recent call last): 2014-09-19 06:54:16.321 12991 TRACE keystone File bin/keystone-manage, line 44, in module 2014-09-19 06:54:16.321 12991 TRACE keystone cli.main(argv=sys.argv, config_files=config_files) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/keystone/cli.py, line 307, in main 2014-09-19 06:54:16.321 12991 TRACE keystone CONF.command.cmd_class.main() 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/keystone/cli.py, line 74, in main 2014-09-19 06:54:16.321 12991 TRACE keystone migration_helpers.sync_database_to_version(extension, version) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/keystone/common/sql/migration_helpers.py, line 204, in sync_database_to_version 2014-09-19 06:54:16.321 12991 TRACE keystone _sync_common_repo(version) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/keystone/common/sql/migration_helpers.py, line 160, in _sync_common_repo 2014-09-19 06:54:16.321 12991 TRACE keystone init_version=init_version) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/oslo/db/sqlalchemy/migration.py, line 79, in db_sync 2014-09-19 06:54:16.321 12991 TRACE keystone return versioning_api.upgrade(engine, repository, version) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/migrate/versioning/api.py, line 186, in upgrade 2014-09-19 06:54:16.321 12991 TRACE keystone return _migrate(url, repository, version, upgrade=True, err=err, **opts) 2014-09-19 06:54:16.321 12991 TRACE keystone File string, line 2, in _migrate 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py, line 160, in with_engine 2014-09-19 06:54:16.321 12991 TRACE keystone return f(*a, **kw) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/migrate/versioning/api.py, line 366, in _migrate 2014-09-19 06:54:16.321 12991 TRACE keystone schema.runchange(ver, change, changeset.step) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/migrate/versioning/schema.py, line 93, in runchange 2014-09-19 06:54:16.321 12991 TRACE keystone change.run(self.engine, step) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/migrate/versioning/script/py.py, line 148, in run 2014-09-19 06:54:16.321 12991 TRACE keystone script_func(engine) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/keystone/common/sql/migrate_repo/versions/039_grant_to_assignment.py, line 223, in upgrade 2014-09-19 06:54:16.321 12991 TRACE keystone migrate_grant_table(meta, migrate_engine, session, table_name) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/keystone/common/sql/migrate_repo/versions/039_grant_to_assignment.py, line 85, in migrate_grant_table 2014-09-19 06:54:16.321 12991 TRACE keystone migrate_engine.execute(upgrade_table.delete()) 2014-09-19 06:54:16.321 12991 TRACE keystone File /home/david/keystone/.venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py, line 1752, in execute 2014-09-19 06:54:16.321 12991 TRACE keystone return connection.execute(statement, *multiparams, **params) 2014-09-19 06:54:16.321 12991 TRACE keystone File
[Yahoo-eng-team] [Bug 1373167] Re: Infinite Recursion for __getattr__ in keystone.token.persistence.core.Manager due to dep injection
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1373167 Title: Infinite Recursion for __getattr__ in keystone.token.persistence.core.Manager due to dep injection Status in OpenStack Identity (Keystone): Fix Released Bug description: On initializing the token_api due to the way the dependency injector works, an infinite recursion occurs at: https://github.com/openstack/keystone/blob/1af24284bdc093dae4f027ade2ddb29656b676f0/keystone/token/persistence/core.py#L228-L236 This occurs when doing the lookup for token_provider_api causes an issue. The solution simply requires verifying that the 'item' is not in self._dependencies or self._optionals. This stabilizes eventually after startup. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1373167/+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 1374033] Re: wsgi generating wrong entity_id values when issuing saml assertions.
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1374033 Title: wsgi generating wrong entity_id values when issuing saml assertions. Status in OpenStack Identity (Keystone): Fix Released Bug description: Attribute issuer should always be set to CONF.saml.idp_entity_id, otherwise entityID from the IdP metadata and the generated assertion can differ and hence make Service Provider reject the assertion. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1374033/+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 1372287] Re: Spelling error in keystone/common/utils.py
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1372287 Title: Spelling error in keystone/common/utils.py Status in OpenStack Identity (Keystone): Fix Released Bug description: The make_dirs() method in the utils.py file has a spelling error in the doc string comments, namely: Assure the directory exists and optionally set it's ownership and permissions. It's should be its To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1372287/+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 1371428] Re: Keystone unit tests trying to use git clone
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1371428 Title: Keystone unit tests trying to use git clone Status in OpenStack Identity (Keystone): Fix Released Bug description: This bug is the 2nd instance of https://bugs.launchpad.net/keystone/+bug/948495, 2 years later. Its looking like keystone is fetching python-keystoneclient from git, in order to run its unit tests. This is not possible when running during the build of the Debian package. The result is that all keystone.tests.test_keystoneclient.KcMasterTestCase.* unit tests are failing, as per this build log: https://117.121.243.214/job/keystone/36/console One way to test it would be to completely disable these if git isn't available (which is the case when running in a minimal chroot build environment). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1371428/+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 1371499] Re: Spelling errors in comments in test_backend_ldap.py
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1371499 Title: Spelling errors in comments in test_backend_ldap.py Status in OpenStack Identity (Keystone): Fix Released Bug description: Some minor spelling mistakes could use correcting, namely: # Domain3 has a user created before we switched on # multiple backends, plus one created afterwards - and it's # backend has not changed - so we should fined two. Two mistakes in the same block! To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1371499/+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 1369664] Re: Token are not revoked when a role from group is revoked
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1369664 Title: Token are not revoked when a role from group is revoked Status in OpenStack Identity (Keystone): Fix Released Bug description: Since the commit https://review.openstack.org/#/c/115338, when a groupe role is revoked, the tokens of the members of this group are not revoked. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1369664/+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 1368046] Re: empty username/userid results in unhelpful error
** Changed in: keystone Status: Fix Committed = Fix Released ** Changed in: keystone Milestone: None = juno-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1368046 Title: empty username/userid results in unhelpful error Status in OpenStack Identity (Keystone): Fix Released Bug description: If the username/userid is provided in the body but it is blank, an sqlalchemy error is triggered from querying on an empty ID. 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/common/wsgi.py, line 212, in __call__ 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi result = method(context, **params) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/token/controllers.py, line 98, in authenticate 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi context, auth) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/token/controllers.py, line 276, in _authenticate_local 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi password=password) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/notifications.py, line 253, in wrapper 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi result = f(wrapped_self, context, user_id, *args, **kwargs) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/identity/core.py, line 189, in wrapper 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi return f(self, *args, **kwargs) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/identity/core.py, line 281, in authenticate 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi ref = driver.authenticate(user_id, password) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/identity/backends/sql.py, line 110, in authenticate 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi user_ref = self._get_user(session, user_id) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib/python2.7/site-packages/keystone/identity/backends/sql.py, line 136, in _get_user 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi user_ref = session.query(User).get(user_id) 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi File /usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py, line 799, in get 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi if len(ident) != len(mapper.primary_key): 2014-09-10 20:00:24.996 1497 TRACE keystone.common.wsgi TypeError: object of type 'NoneType' has no len() To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1368046/+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 1369180] Re: keystone logs for unit tests are too verbose
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1369180 Title: keystone logs for unit tests are too verbose Status in OpenStack Identity (Keystone): Fix Released Bug description: The current full jenkins run comes close to blowing the 50Mb limit we set for success, meaning that minor changes can tip the logging over this limit and tests fail. Once of the major culprits is that we log every time (for every test) when someone subscribes to a callback notification. This seems overzealous and wasteful of electrons. We should set the default notification log level to INFO in the tests/core.py to suppress this. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1369180/+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 1367952] Re: Trust execution fails when trustor is in LDAP
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1367952 Title: Trust execution fails when trustor is in LDAP Status in OpenStack Identity (Keystone): Fix Released Bug description: the token provider code is checking the enabled attribute on the when excuting a trust. However, in many LDAP deployments, this value is unset, and For the auth plugins, the enabled logic is calculated in identity/core.py. THe token provider should use this code as well. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1367952/+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 1371154] Re: increase default setting of workers to n-cpu
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1371154 Title: increase default setting of workers to n-cpu Status in OpenStack Identity (Keystone): Fix Released Bug description: Eventlet workers should default to n-cpu not 1 for both main and admin APIs. The default of 1 with UUID tokens causes eventlet to perform extremely poorly under a default installation. It is possible the minimum default should always be 2 workers. (Open for discussion) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1371154/+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 1366988] Re: Formatting error in debug logging
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366988 Title: Formatting error in debug logging Status in OpenStack Identity (Keystone): Fix Released Bug description: When logging is set to the debug level revoke_token can fail when there is not audit_chain_id, but the token is supposed to be revoked by the chain. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366988/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1367354] Re: oslo.db's master breaks unittest in OS projects
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1367354 Title: oslo.db's master breaks unittest in OS projects Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Compute (Nova): Confirmed Status in Oslo Database library: Fix Released Status in “keystone” package in Ubuntu: Fix Released Bug description: When I run the unittests in different OpennStack projects using the latest oslo.db there were a lot of failures on Nova, Neutron and Keystone. The lot of tests raises OperationalError: (OperationalError) cannot start a transaction within a transaction 'BEGIN' () The right approach is to fix these projects, but we are in the end of J release, so I'm not sure, that we can merge these fixes fast. This issue was caused by commit [1], so the faster and simplest approach is - to revert this commit an continue our fork on this in K [1] https://github.com/openstack/oslo.db/commit/78fd290a89545de31e5c13f3085df23368a8afaa To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1367354/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1366606] Re: oauth1 downgrade fail with sqlite
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366606 Title: oauth1 downgrade fail with sqlite Status in OpenStack Identity (Keystone): Fix Released Bug description: The oauth1 extension migrations fail with sqlite when doing the version 2 downgrade. This is because the migration is attempting to compare a string to an sqlalchemy Engine object. NotSupportedError: SQLite does not support ALTER TABLE DROP CONSTRAINT; see http://www.sqlite.org/lang_altertable.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366606/+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 1366649] Re: Typo in keystone/common/base64utils.py
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366649 Title: Typo in keystone/common/base64utils.py Status in OpenStack Identity (Keystone): Fix Released Bug description: Typo in keystone/common/base64utils.py To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366649/+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 1366211] Re: Using LDAP assignments, delete group doesn't remove assignments
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366211 Title: Using LDAP assignments, delete group doesn't remove assignments Status in OpenStack Identity (Keystone): Fix Released Bug description: When Keystone is configured to use the LDAP backend for assignments, if a group with a role assignment is deleted then the role assignments are not deleted as they should be. See bug 1365787 for instructions on creating the group role assignment. Here's an example where I set up a group role assignment: $ openstack role assignment list +--+--+--+--++ | Role | User | Group | Project | Domain | +--+--+--+--++ ... | fc4bf67b5d004581b375b98bbc31af38 | | ae467ef324584807894ab52566db41f4 | 31e82447e7b2415f934a328e121595ce || +--+--+--+--++ bknudson@f1-ds:~$ openstack group delete blktest1 bknudson@f1-ds:~$ openstack role assignment list +--+--+--+--++ | Role | User | Group | Project | Domain | +--+--+--+--++ | fc4bf67b5d004581b375b98bbc31af38 | | ae467ef324584807894ab52566db41f4 | 31e82447e7b2415f934a328e121595ce || +--+--+--+--++ That role assignment shouldn't be there anymore. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366211/+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 1365061] Re: Warn against sorting requirements
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1365061 Title: Warn against sorting requirements Status in Cinder: Fix Committed Status in Designate: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Identity (Keystone) Middleware: Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Fix Committed Status in Python client library for Keystone: Invalid Status in OpenStack Object Storage (Swift): Fix Committed Bug description: Contrary to bug 1285478, requirements files should not be sorted alphabetically. Given that requirements files can contain comments, I'd suggest a header in all requirements files along the lines of: # The order of packages is significant, because pip processes them in the order # of appearance. Changing the order has an impact on the overall integration # process, which may cause wedges in the gate later. This is the result of a mailing list discussion (thanks, Sean!): http://www.mail-archive.com/openstack- d...@lists.openstack.org/msg33927.html To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1365061/+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 1366944] Re: Man pages out of date
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366944 Title: Man pages out of date Status in OpenStack Identity (Keystone): Fix Released Bug description: The man pages for keystone-all and keystone-manage are out of date. especially keystone-manage is missing new subcommands. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366944/+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 1366589] Re: JSON Home support for GET /
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366589 Title: JSON Home support for GET / Status in OpenStack Identity (Keystone): Fix Released Bug description: Keystone supports getting a JSON Home document for GET /v3. It should also support returning the JSON Home for GET /, that way a client that supports JSON Home and is pointed to the / endpoint doesn't have to then fetch /v3. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366589/+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 1366991] Re: Keystone local authenticate has unnecessary CADF pending audit record
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1366991 Title: Keystone local authenticate has unnecessary CADF pending audit record Status in OpenStack Identity (Keystone): Fix Released Bug description: Keystone local authenticate has an unnecessary CADF pending audit record. Pending should be used for long running operations but local authenticate is not such an operation. Keystone federated identity authenticate audit record does not generate pending audit records so fixing local authenticate will improve consistency To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1366991/+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 1346211] Re: keystone under apache can't handle request chunking
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1346211
Title:
keystone under apache can't handle request chunking
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
Method to reproduce stack trace for apache config with chunking enabled
1. If using devstack, configure it to enable chunking in apache, by
adding WSGIChunkedRequest On in the file devstack/files/apache-
keystone.template (in both sections) and start devstack
2. Run from the command line:
openstack -v --debug server list (or any simple command)
3. Look in the output for the very first curl command that looks
something like this:
curl -i --insecure -X POST http://192.168.51.21:5000/v2.0/tokens -H
Content-Type: application/json -H Accept: application/json -H
User-Agent: python-keystoneclient -d '{auth: {tenantName:
demo, passwordCredentials: {username: demo, password:
admin}}}'
4. The above curl command succeeds. Modify it to use chunking by
adding -H Transfer-Encoding: chunked and run it:
curl -i --insecure -X POST http://192.168.51.21:5000/v2.0/tokens -H
Content-Type: application/json -H Accept: application/json -H
User-Agent: python-keystoneclient -H Transfer-Encoding: chunked -d
'{auth: {tenantName: demo, passwordCredentials: {username:
demo, password: admin}}}'
5. You will get a cli error:
HTTP/1.1 500 Internal Server Error
Date: Wed, 16 Jul 2014 19:01:58 GMT
Server: Apache/2.2.22 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 215
Connection: close
Content-Type: application/json
{error: {message: An unexpected error prevented the server from
fulfilling your request: request data read error (Disable debug mode
to suppress these details.), code: 500, title: Internal Server
Error}}
6. The keystone log will show a stack trace:
[Wed Jul 16 19:02:43 2014] [error] 13693 ERROR keystone.common.wsgi [-]
request data read error
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi Traceback
(most recent call last):
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi File
/opt/stack/keystone/keystone/common/wsgi.py, line 414, in __call__
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
response = self.process_request(request)
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi File
/opt/stack/keystone/keystone/middleware/core.py, line 112, in process_request
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
params_json = request.body
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi File
/usr/local/lib/python2.7/dist-packages/webob/request.py, line 677, in
_body__get
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
self.make_body_seekable() # we need this to have content_length
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi File
/usr/local/lib/python2.7/dist-packages/webob/request.py, line 922, in
make_body_seekable
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
self.copy_body()
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi File
/usr/local/lib/python2.7/dist-packages/webob/request.py, line 938, in
copy_body
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
self.body = self.body_file_raw.read()
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi File
/opt/stack/keystone/keystone/common/utils.py, line 306, in read
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
result = self.data.read()
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi IOError:
request data read error
[Wed Jul 16 19:02:43 2014] [error] 13693 TRACE keystone.common.wsgi
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1346211/+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 1363709] Re: keystone-all logging config twice
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1363709 Title: keystone-all logging config twice Status in OpenStack Identity (Keystone): Fix Released Bug description: keystone-all is logging the config twice. Once from keystone-all and once from keystone.openstack.common.service. The config should only has to be logged once. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1363709/+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 1350000] Re: UUID is a more friendly default token provider than PKI
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/135 Title: UUID is a more friendly default token provider than PKI Status in OpenStack Identity (Keystone): Fix Released Bug description: PKI has been the default token provider since Grizzly. Early in the Grizzly development cycle, PKI was established as the default, primarily to expose the implementation to a broad developer audience to work out any issues. Issues were immediately discovered that prevented PKI from becoming the default in production deployments, and that has been an ongoing theme ever since. As of the Juno development cycle, there are still unresolved issues that prevent PKI from being a reasonable production choice. The following etherpad summarizes the Keystone community's perspective on each technology: https://etherpad.openstack.org/p/pki-vs-uuid This was also discussed in the July 29th keystone meeting: http://eavesdrop.openstack.org/meetings/keystone/2014/keystone.2014-07-29-18.01.log.html It therefore follows that UUID, or a variant thereof, should become the default token provider for Juno. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/135/+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 1328469] Re: Update test requirement hacking to series 0.9.x
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1328469 Title: Update test requirement hacking to series 0.9.x Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: Fix Committed Bug description: After the release of Hacking 0.9.x and the acceptance to the global requirements (https://review.openstack.org/#/c/98824/) the test requirement should be bumped and all new issues should be fixed accordingly. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1328469/+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 1350273] Re: Filtering services by name doesn't work
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1350273 Title: Filtering services by name doesn't work Status in OpenStack Identity (Keystone): Fix Released Bug description: doing a query for listing services filtering by name doesn't work in the SQL backend. This is due to a couple of things: * 'name' doesn't appear in the filterprotected decorator in keystone.catalog.controllers line 250 (https://github.com/openstack/keystone/blob/d9bfb7a695b3f886dbb961e721bce91194e14cce/keystone/catalog/controllers.py#L250) * the sql model for the service doesn't have an explicit name attribute in keystone.catalog.backends.sql This is an issue since some clients (namely python-openstackclient) give the option to create endpoints with the service name as a parameter (you can give the service id, name or type), even though it is not possible to retrieve a service from keystone using the name. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1350273/+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 1331882] Re: trustor_user_id not available in v2 trust token
** Changed in: keystone
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1331882
Title:
trustor_user_id not available in v2 trust token
Status in OpenStack Identity (Keystone):
Fix Released
Status in OpenStack Security Notes:
New
Bug description:
The trust information in the v2 token is missing the trustor_user_id
and impersonation values. This means you are unable to tell who gave
you the trust.
The following two examples were generated with the same information.
(They are printed from client.auth_ref which is why they are missing
some structure information)
v2 Trust token:
{u'metadata': {u'is_admin': 0,
u'roles': [u'136bc06cef2f496f842a76644feaed03',
u'7d42773abeff45ea90fdb4067f6b3a9f']},
u'serviceCatalog': [...],
u'token': {u'expires': u'2014-06-19T02:41:19Z',
u'id': u'4b8d23d9707a4c9f8a270759725dfcf8',
u'issued_at': u'2014-06-19T01:41:19.811417',
u'tenant': {u'description': u'Default Tenant',
u'enabled': True,
u'id': u'9029b226bc894fa3a23ec24fd9f4796c',
u'name': u'demo'}},
u'trust': {u'id': u'0b16de31a8c64fd5b0054054db468a00',
u'trustee_user_id': u'f6cce259563e40acb3f841f5d89c6191'},
u'user': {u'id': u'f6cce259563e40acb3f841f5d89c6191',
u'name': u'bob',
u'roles': [{u'name': u'can_create'}, {u'name': u'can_delete'}],
u'roles_links': [],
u'username': u'bob'}}
v3 Trust token:
{u'OS-TRUST:trust': {u'id': u'0b16de31a8c64fd5b0054054db468a00',
u'impersonation': False,
u'trustee_user': {u'id':
u'f6cce259563e40acb3f841f5d89c6191'},
u'trustor_user': {u'id':
u'5fcb10539aa646ea8b0fe3c80e15d33d'}},
'auth_token': '0b8a2d2e081e4e6e8ae3ad5dfedcf9db',
u'catalog': [...],
u'expires_at': u'2014-06-19T02:41:19.935302Z',
u'extras': {},
u'issued_at': u'2014-06-19T01:41:19.935330Z',
u'methods': [u'password'],
u'project': {u'domain': {u'id': u'default', u'name': u'Default'},
u'id': u'9029b226bc894fa3a23ec24fd9f4796c',
u'name': u'demo'},
u'roles': [{u'id': u'136bc06cef2f496f842a76644feaed03',
u'name': u'can_create'},
{u'id': u'7d42773abeff45ea90fdb4067f6b3a9f',
u'name': u'can_delete'}],
u'user': {u'domain': {u'id': u'default', u'name': u'Default'},
u'id': u'f6cce259563e40acb3f841f5d89c6191',
u'name': u'bob'}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1331882/+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 1209343] Re: LDAP connection code does not provide ldap.set_option(ldap.OPT_X_TLS_CACERTFILE) for ldaps protocol
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1209343 Title: LDAP connection code does not provide ldap.set_option(ldap.OPT_X_TLS_CACERTFILE) for ldaps protocol Status in OpenStack Identity (Keystone): Fix Released Status in Keystone icehouse series: Fix Committed Bug description: The HP Enterprise Directory LDAP servers require a ca certificate file for ldaps connections. Sample working Python code: ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, d:/etc/ssl/certs/hpca2ssG2_ns.cer) ldap_client = ldap.initialize(host) ldap_client.protocol_version = ldap.VERSION3 ldap_client.simple_bind_s(binduser,bindpw) filter = '(uid=mark.m*)' attrs = ['cn', 'mail', 'uid', 'hpStatus'] r = ldap_client.search_s(base, scope, filter, attrs) for dn, entry in r: print 'dn=', repr(dn) for k in entry.keys(): print '\t', k, '=', entry[k] The current H-2 keystone/common/ldap/core.py file only provides this ldap.set_option for TLS connections. I have attached a picture of a screen shot showing the change I had to make to file core.py to enable the ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, tls_cacertfile) statement to also get executed for ldaps connections. Basically I pulled the set_option code out of the if tls_cacertfile: block. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1209343/+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 1364618] Re: KvsInheritanceTests does not use backend KVS
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1364618 Title: KvsInheritanceTests does not use backend KVS Status in OpenStack Identity (Keystone): Fix Released Bug description: The tests in KvsInheritanceTests [1] does not use the backend KVS as identity driver, as they were supposed to. To fix this, we need to add a config_overrides method, as at [2]. [1] https://github.com/openstack/keystone/blame/master/keystone/tests/test_backend_kvs.py#L257 [2] https://github.com/openstack/keystone/blame/master/keystone/tests/test_backend_kvs.py#L247-L251 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1364618/+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 1362007] Re: Empty supported backend list in Keystone architecture documentation
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1362007 Title: Empty supported backend list in Keystone architecture documentation Status in OpenStack Identity (Keystone): Fix Released Bug description: Found just before: http://docs.openstack.org/developer/keystone/architecture.html#rules in block: http://docs.openstack.org/developer/keystone/architecture.html#approach-to-authorization-policy ...Backends included in Keystone are: empty To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362007/+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 1363932] Re: Internal error Enabling Federation Extension
** Changed in: keystone Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1363932 Title: Internal error Enabling Federation Extension Status in OpenStack Identity (Keystone): Fix Released Bug description: Following steps here http://docs.openstack.org/developer/keystone/extensions/federation.html I've realized of a possible bug, but I'm not sure, let me explain myself. Step 3 of http://docs.openstack.org/developer/keystone/extensions/federation.html [pipeline:api_v3] pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension s3_extension federation_extension service_v3 Ok, no problems. Restart keystone (under apache) and type keystone tenant-list command and every is fine, no problems. Now, modify again keystone-paste.ini file (by the way, on a fresh keystone installation this file is called keystone-dist-paste.ini by default) and put federation_extenstion at the end of the line, like: [pipeline:api_v3] pipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body ec2_extension s3_extension service_v3 federation_extension Restart keystone and when you type keystone tenant-list command, keystone raises: Internal Server Error 500 This is the log information about this error: [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] mod_wsgi (pid=24803): Target WSGI script '/var/www/cgi-bin/keystone/main' cannot be loaded as Python module. [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] mod_wsgi (pid=24803): Exception occurred processing WSGI script '/var/www/cgi-bin/keystone/main'. [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] Traceback (most recent call last): [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /var/www/cgi-bin/keystone/main, line 58, in module [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] name=name) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 247, in loadapp [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] return loadobj(APP, uri, name=name, **kw) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 272, in loadobj [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] return context.create() [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 710, in create [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] return self.object_type.invoke(self) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 144, in invoke [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] **context.local_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/util.py, line 56, in fix_call [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] val = callable(*args, **kw) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/urlmap.py, line 25, in urlmap_factory [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] app = loader.get_app(app_name, global_conf=global_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 350, in get_app [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] name=name, global_conf=global_conf).create() [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 362, in app_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] APP, name=name, global_conf=global_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 450, in get_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] global_additions=global_additions) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 559, in _pipeline_app_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] APP, pipeline[-1], global_conf) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File /usr/lib/python2.6/site-packages/paste/deploy/loadwsgi.py, line 408, in get_context [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] object_type, name=name) [Mon Sep 01 11:28:56 2014] [error] [client 128.142.145.164] File
[Yahoo-eng-team] [Bug 1375607] [NEW] .po files don't contain comments for translators
Public bug reported: It looks like Horizon developers write many comments in their codes to tanslators. According to https://docs.djangoproject.com/en/1.7/topics/i18n/translation/#comments-for-translators, these comments should show up in the po files. Yet I checked English version po files and found no comments there. I think the problem may be caused by the po file generation method. I have sent the issue to I18n mailing list. It might related with the po file generation scripts in infrastructure env. Regards Daisy ** Affects: horizon Importance: Undecided Status: New ** Description changed: - It looks like Horizon developers write many comments in their codes to translators. + It looks like Horizon developers write many comments in their codes to tanslators. According to https://docs.djangoproject.com/en/1.7/topics/i18n/translation/#comments-for-translators, these comments should show up in the po files. Yet I checked English version po files and found no comments there. I think the problem may be caused by the po file generation method. I have sent the issue to I18n mailing list. It might related with the po file generation scripts in infrastructure env. Regards Daisy -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1375607 Title: .po files don't contain comments for translators Status in OpenStack Dashboard (Horizon): New Bug description: It looks like Horizon developers write many comments in their codes to tanslators. According to https://docs.djangoproject.com/en/1.7/topics/i18n/translation/#comments-for-translators, these comments should show up in the po files. Yet I checked English version po files and found no comments there. I think the problem may be caused by the po file generation method. I have sent the issue to I18n mailing list. It might related with the po file generation scripts in infrastructure env. Regards Daisy To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1375607/+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 1375606] [NEW] Floating ip doesn't get migrated when perform a nova evacuate using nova-network multi host mode
Public bug reported: Using nova-network multi_host mode Icehouse version when evacuate an instance with floating ip , instance get rebuilded to another node, but floating ip doesn't updated to the new compute node. ** Affects: nova 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/1375606 Title: Floating ip doesn't get migrated when perform a nova evacuate using nova-network multi host mode Status in OpenStack Compute (Nova): New Bug description: Using nova-network multi_host mode Icehouse version when evacuate an instance with floating ip , instance get rebuilded to another node, but floating ip doesn't updated to the new compute node. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1375606/+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 1371040] Re: glance store rbd driver get method returns tupe more than basic driver defines
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1371040 Title: glance store rbd driver get method returns tupe more than basic driver defines Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: glance_store/_drivers/rbd.py def get(self, location, offset=0, chunk_size=None, context=None): 208 209 Takes a `glance_store.location.Location` object that indicates 210 where to find the image file, and returns a tuple of generator 211 (for reading the image file) and image_size 212 213 :param location `glance_store.location.Location` object, supplied 214 from glance_store.location.get_location_from_uri() 215 :raises `glance_store.exceptions.NotFound` if image does not exist 216 217 loc = location.store_location 218 return (ImageIterator(loc.image, self), 219 self.get_size(location), chunk_size) the return tupe should be two values, not three, this is what all else expected. @@ -453,7 +453,7 @@ class Controller(controller.BaseController): if dest is not None: src_store.READ_CHUNKSIZE = dest.WRITE_CHUNKSIZE image_data, image_size = src_store.get(loc, context=context) when using rbd backend, an exception raised too many values to unpack tested with lastest trunk code base To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1371040/+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 1370989] Re: s3_store_host including port num not working
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1370989 Title: s3_store_host including port num not working Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Due to the following change in boto, s3_store_host with :port num does not work for now. If s3_store_host is configured with port num like below, it will try to connect to 80 as the standard http port. https://github.com/boto/boto/commit/0205cadde7b68c6648c410a9b1ef653655eae3b8 [/etc/glance/glace-api.conf] s3_store_host=s3.cloudian.com:18080 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1370989/+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 1370247] Re: glance_store rbd driver accidentally changed chunk size units
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1370247 Title: glance_store rbd driver accidentally changed chunk size units Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: In migrating to glance_store, there was a typo of operators, so 1024**2 became 1024^6, which is 1026 in python, which makes the default chunk size off by a couple orders of magnitude (~8k rather than 8mb). To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1370247/+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 1368391] Re: sqlalchemy-migrate 0.9.2 is breaking nova unit tests
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1368391 Title: sqlalchemy-migrate 0.9.2 is breaking nova unit tests Status in Cinder: Fix Committed Status in Cinder havana series: Fix Released Status in Cinder icehouse series: Fix Committed Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance havana series: Fix Released Status in Glance icehouse series: Fix Committed Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) havana series: Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Committed Status in Database schema migration for SQLAlchemy: New Bug description: sqlalchemy-migrate 0.9.2 is breaking nova unit tests OperationalError: (OperationalError) cannot commit - no transaction is active u'COMMIT;' () http://logs.openstack.org/39/117839/18/gate/gate-nova- python27/8a7aa8c/ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1368391/+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 1366503] Re: [v2] Duplicate image id return 500 instead of 409
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1366503 Title: [v2] Duplicate image id return 500 instead of 409 Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Duplicate image id will return HTTP 500 error instead of 409 in Glance V2 API, see https://review.openstack.org/#/c/119285/1,publish To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1366503/+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 1364570] Re: missing registry api tests for glance tasks
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1364570 Title: missing registry api tests for glance tasks Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Although, https://github.com/openstack/glance/blob/master/glance/db/registry/api.py#L262 has code for db/registry there are missing tests in https://github.com/openstack/glance/blob/master/glance/tests/functional/db/test_registry.py To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1364570/+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 1366515] Re: [v2] Can't recognize paramter **id** for image create
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1366515 Title: [v2] Can't recognize paramter **id** for image create Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: We're using **id** in image schema[1,2], but using **image_id** for most of the internal functions[3,4]. So user will got a key error if he is passing in **id**. [1] https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L672 [2] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/shell.py#L37 [3] https://github.com/openstack/glance/blob/master/glance/domain/__init__.py#L73 [4] https://github.com/openstack/glance/blob/master/glance/domain/__init__.py#L78 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1366515/+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 1324395] Re: Rename Openstack to OpenStack
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1324395 Title: Rename Openstack to OpenStack Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Rename Openstack to OpenStack To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1324395/+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 1361963] Re: No default control_exchange configuration prompt in glance-api.conf
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1361963 Title: No default control_exchange configuration prompt in glance-api.conf Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: In current default glance-api.conf, messaging configurations as below, but actually 'rabbit_notification_exchange = glance' and 'qpid_notification_exchange = glance' do not impact topic consumer_queue creation. because Oslo .messaging uses 'control_exchange' as queue name, default value is 'openstack'. other component such as cinder has written ''control_exchange=cinder'' into cinder conf. glance should do same change as well. # Messaging driver used for 'messaging' notifications driver # rpc_backend = 'rabbit' # Configuration options if sending notifications via rabbitmq (these are # the defaults) rabbit_host = localhost rabbit_port = 5672 rabbit_use_ssl = false rabbit_userid = guest rabbit_password = guest rabbit_virtual_host = / rabbit_notification_exchange = glance rabbit_notification_topic = notifications rabbit_durable_queues = False # Configuration options if sending notifications via Qpid (these are # the defaults) qpid_notification_exchange = glance qpid_notification_topic = notifications qpid_hostname = localhost qpid_port = 5672 qpid_username = qpid_password = qpid_sasl_mechanisms = qpid_reconnect_timeout = 0 qpid_reconnect_limit = 0 qpid_reconnect_interval_min = 0 qpid_reconnect_interval_max = 0 qpid_reconnect_interval = 0 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1361963/+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 1300546] Re: config.generator could not handle split configs
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1300546 Title: config.generator could not handle split configs Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in The Oslo library incubator: Fix Released Bug description: Current config.generator could not handle split configs for the different services within a project, all configurations be collected and save to a single large template file. But for most project, the code repo contains more then one service, like nova repo/project contains nova-api, nova-compute. So the single template file is hard to be used/maintained for separated service. IMO, it will be cool if config.generator could generate separated configs based on service instead of project. Example of split configs is glance-api.conf versus glance- registry.conf To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1300546/+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 1306559] Re: Fix python26 compatibility for RFCSysLogHandler
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1306559 Title: Fix python26 compatibility for RFCSysLogHandler Status in Cinder: Confirmed Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Identity (Keystone): Confirmed Status in Murano: Fix Released Status in OpenStack Neutron (virtual network service): Confirmed Bug description: Currently used pattern https://review.openstack.org/#/c/63094/15/openstack/common/log.py (lines 471-479) will fail for Python 2.6.x. In order to fix the broken Python 2.6.x compatibility, old style explicit superclass method calls should be used instead. Here is an example of how to check this for Python v2.7 and v2.6: import logging.handlers print type(logging.handlers.SysLogHandler) print type(logging.Handler) Results would be: Python 2.7: type 'type', so super() may be used for RFCSysLogHandler(logging.handlers.SysLogHandler) Python 2.6:type 'classobj', so super() may *NOT* be used for RFCSysLogHandler(logging.handlers.SysLogHandler) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1306559/+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 1230127] Re: Use self.assertTrue instead of self.assertEqual(..., True)
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1230127 Title: Use self.assertTrue instead of self.assertEqual(..., True) Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: $ find . -name '*.*' | xargs grep self.assertEqual | grep True ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(data['image']['is_public'], True) ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(data['image']['is_public'], True) ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(data['image']['is_public'], True) ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(response['x-image-meta-is_public'], 'True') ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(data['image']['is_public'], True) ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(data['image']['is_public'], True) ./tests/integration/legacy_functional/test_v1_api.py: self.assertEqual(data['image']['is_public'], True) ... ./tests/unit/test_swift_store.py: self.assertEqual(connection.insecure, True) ./tests/unit/test_swift_store.py:self.assertEquals(connection.snet, True) ./tests/unit/test_swift_store.py:self.assertEquals(connection.snet, True) $ find . -name '*.*' | xargs grep self.assertTrue ./tests/unit/test_context_middleware.py: self.assertTrue(req.context.is_admin) ./tests/unit/test_context_middleware.py: self.assertTrue(req.context.is_admin) ... ./tests/unit/test_context_middleware.py: self.assertTrue(req.context.is_admin) ./tests/unit/test_context_middleware.py: self.assertTrue(req.context.read_only) ./tests/unit/test_context_middleware.py: self.assertTrue(req.context.is_admin) The tests assertions need to be consistent: use assertTrue/assertFalse instead of assertEqual to test boolean values. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1230127/+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 1291848] Re: Remove deprecation warning when loading stores
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1291848 Title: Remove deprecation warning when loading stores Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Tracking the need of removing deprecation warning and the _EXTRA_STORES global from stores/__init__ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1291848/+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 1187395] Re: GET to non-existent member can return 500
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1187395 Title: GET to non-existent member can return 500 Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: $ curl -v -k -H 'x-auth-token: XXX' https://localhost:9191/images/ff01e505-97fc-4bd9-98ae-63f5b7181a86/members/123 * About to connect() to localhost port 9191 (#0) * Trying 127.0.0.1... connected * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using AES256-SHA * Server certificate: *subject: C=US; ST=Nevada; L=Las Vegas; O=Hewlett Packard; OU=Cloud Services; CN=glance.rnda.aw1.hpcloud.net; emailAddress=csbu.gal...@hp.com *start date: 2013-02-19 16:47:42 GMT *expire date: 2015-02-19 16:57:42 GMT *common name: glance.rnda.aw1.hpcloud.net (does not match 'localhost') *issuer: DC=ms; DC=hpcloud; CN=aw1cloudica01 *SSL certificate verify ok. GET /images/ff01e505-97fc-4bd9-98ae-63f5b7181a86/members/123 HTTP/1.1 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: localhost:9191 Accept: */* x-auth-token: HPAuth10_39a73cd66f63a22532e69eddf807444bbcc89c33a7303330e188415f33e321c4 HTTP/1.1 500 Internal Server Error Content-Type: text/plain Content-Length: 0 Date: Tue, 04 Jun 2013 13:49:55 GMT Connection: close * Closing connection #0 * SSLv3, TLS alert, Client hello (1): To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1187395/+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 1256364] Re: While deleting an image, Glance Swift store fails to delete remaining chunks upon erroring on one of the chunks
** Changed in: glance Status: Fix Committed = Fix Released ** Changed in: glance Milestone: None = juno-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1256364 Title: While deleting an image, Glance Swift store fails to delete remaining chunks upon erroring on one of the chunks Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: While attempting to delete an image, glance swift store: 1. checks if the image is stored as chunks. 2. if stored as chunks: 2.a. fetch the list of chunks 2.b. iterates over chunks and deletes each one 2.c. deletes the manifest 3. if not stored as chunks, deletes the object In step 2.b, when iterating over the list of chunks and deleting each one, if glance swift store receives an error on one of the chunks, an exception is raised and the delete process halts leaving the remaining chunks orphaned. This may cause orphaned chunks to be leftover in swift. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1256364/+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 1264302] Re: insufficient permissions on glance images for direct copy
** Changed in: glance
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1264302
Title:
insufficient permissions on glance images for direct copy
Status in OpenStack Image Registry and Delivery Service (Glance):
Fix Released
Bug description:
I'm running Havana multinode. Instances and images are located on SAN
attached shared disk (GPFS). Glance images need to be copied by cp
instead of curl to nova's _base directory. Here is my configs:
** /etc/glance/glance-api.conf
filesystem_store_datadir = /gpfs/images/
show_multiple_locations = True
filesystem_store_metadata_file = /etc/glance/gpfs.json
** /etc/glance/gpfs.json
{
id: b2b3229e-f22f-4af1-a809-fcf72afe8577,
mountpoint: /gpfs
}
** /etc/nova/nova.conf
allowed_direct_url_schemes=file
filesystems=gpfs
[image_file_url:gpfs]
id=b2b3229e-f22f-4af1-a809-fcf72afe8577
mountpoint=/gpfs
** Nova log on compute node
2013-12-25 17:29:15.512 10058 INFO nova.virt.libvirt.driver
[req-af8fc341-bc26-4217-ba47-51a63d39a934 3cb68bbdc8bf499d82dee70392fe1c62
d1944f8305224f00b7f1faf72937f448] [instance: 4c18cdd0-c852-406
7-bef7-de0b3e6db82b] Creating image
2013-12-25 17:29:16.109 10058 ERROR nova.image.glance
[req-af8fc341-bc26-4217-ba47-51a63d39a934 3cb68bbdc8bf499d82dee70392fe1c62
d1944f8305224f00b7f1faf72937f448] Unexpected error while running com
mand.
Command: cp /gpfs/images/e70e8713-b96b-4e6e-85a6-eda501889315
/var/lib/nova/instances/_base/bbc9f62419d817181cf3f8f72530133bc0a1172e.part
Exit code: 1
Stdout: ''
Stderr: cp: cannot open `/gpfs/images/e70e8713-b96b-4e6e-85a6-eda501889315'
for reading: Permission denied\n
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance Traceback (most recent
call last):
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance File
/usr/lib/python2.6/site-packages/nova/image/glance.py, line 338, in download
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance
xfer_mod.download(context, o, dst_path, loc_meta)
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance File
/usr/lib/python2.6/site-packages/nova/image/download/file.py, line 164, in
download
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance
lv_utils.copy_image(source_file, dst_file)
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance File
/usr/lib/python2.6/site-packages/nova/virt/libvirt/utils.py, line 462, in
copy_image
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance execute('cp', src,
dest)
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance File
/usr/lib/python2.6/site-packages/nova/virt/libvirt/utils.py, line 50, in
execute
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance return
utils.execute(*args, **kwargs)
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance File
/usr/lib/python2.6/site-packages/nova/utils.py, line 177, in execute
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance return
processutils.execute(*cmd, **kwargs)
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance File
/usr/lib/python2.6/site-packages/nova/openstack/common/processutils.py, line
178, in execute
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance cmd=' '.join(cmd))
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance ProcessExecutionError:
Unexpected error while running command.
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance Command: cp
/gpfs/images/e70e8713-b96b-4e6e-85a6-eda501889315
/var/lib/nova/instances/_base/bbc9f62419d817181cf3f8f72530133bc0a1172e.part
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance Exit code: 1
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance Stdout: ''
2013-12-25 17:29:16.109 10058 TRACE nova.image.glance Stderr: cp: cannot
open `/gpfs/images/e70e8713-b96b-4e6e-85a6-eda501889315' for reading:
Permission denied\n
** File permissions on image
-rw-r-. 1 glance glance 10718478336 Dec 23 19:21
/gpfs/images/e70e8713-b96b-4e6e-85a6-eda501889315
I assume that compute service was trying to copy image on behalf on
nova user, that's why this operation was failed with Permission
denied.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1264302/+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 1368128] Re: glance rbd store get_size uses wrong pool
** Changed in: glance Status: Fix Committed = Fix Released ** Changed in: glance Milestone: None = juno-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1368128 Title: glance rbd store get_size uses wrong pool Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: the rbd store's get_size() method ignores the pool of the actual parameter and instead uses the glance pool, which breaks cross-pool image access (one such example would be when we'd reference an rbd ephemeral disk snapshot which is in the ephemeral disk pool) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1368128/+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 1367860] Re: metadef namespace OS::Compute::HostCapabilities description improvement
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1367860 Title: metadef namespace OS::Compute::HostCapabilities description improvement Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: metadef namespace OS::Compute::HostCapabilities description improvement The OS::Compute::HostCapabilities namespace should include more information about how the properties are used by Nova. Let admin's know that the ComputeCapabilitiesFilter needs to be enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1367860/+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 1367548] Re: metadata definition VMware namespace has incorrect capitalization
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1367548 Title: metadata definition VMware namespace has incorrect capitalization Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: metadata definition VMware namespace has incorrect capitalization and the description should make it more clear that this only applies if the Nova VMware driver is enabled. OS::Compute::VMwAre should be OS::Compute::VMware ttripp@ubuntu:~/devstack$ glance --os-image-api-version 2 md-namespace-list ++ | namespace | ++ | OS::Compute::VMwAre| etc etc etc ttripp@ubuntu:~/devstack$ glance --os-image-api-version 2 md-namespace-show OS::Compute::VMwAre ++--+ | Property | Value | ++--+ | created_at | 2014-09-10T02:55:41Z | | description| The VMware compute driver options. | || | || These are properties specific to compute drivers. For a list of all | || hypervisors, see here: https://wiki.openstack.org/wiki/HypervisorSupportMatrix. | | display_name | VMware Driver Options | | namespace | OS::Compute::VMwAre | | owner | admin | | properties | [vmware_ostype, vmware_adaptertype] | | protected | True | | resource_type_associations | [OS::Glance::Image] | | schema | /v2/schemas/metadefs/namespace | | visibility | public | ++--+ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1367548/+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 1367908] Re: Update glance docs to reflect the changes in metadefs api's
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1367908 Title: Update glance docs to reflect the changes in metadefs api's Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Glance docs needs to be updated to synchronize with the changes in metadefs api - rename resource_type to resource_type_associations in namespace API input/output - Add created_at/updated_at in resource_type_associations block of namespace API input/output. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1367908/+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 1370769] Re: Ensure all metadata definition code uses six.itertypes
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1370769 Title: Ensure all metadata definition code uses six.itertypes Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Python client library for Glance: Invalid Bug description: Similar to https://review.openstack.org/#/c/95467/ According to https://wiki.openstack.org/wiki/Python3 dict.iteritems() should be replaced with six.iteritems(dict). All metadata definition code added should ensure that six.iteritems is used. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1370769/+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 1367545] Re: metadef OS::Glance::CommonImageProperties missing colon :
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1367545 Title: metadef OS::Glance::CommonImageProperties missing colon : Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: OS::Glance:CommonImageProperties should be OS::Glance::CommonImageProperties Second set of :: missing one : See below. glance --os-image-api-version 2 md-namespace-list ++ | namespace | ++ | OS::Compute::VMwAre| | OS::Compute::XenAPI| | OS::Compute::Quota | | OS::Compute::Libvirt | | OS::Compute::Hypervisor| | OS::Compute::Watchdog | | OS::Compute::HostCapabilities | | OS::Compute::Trust | | OS::Compute::VirtCPUTopology | | OS::Glance:CommonImageProperties | | OS::Compute::RandomNumberGenerator | ++ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1367545/+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 1282893] Re: Enforce using six.text_type() over unicode()
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1282893 Title: Enforce using six.text_type() over unicode() Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Given http://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data- instead-of-unicode-vs-8-bit, we should have a hacking rule that enforces the usage of six.text_type rather than unicode. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1282893/+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 1367172] Re: glance-manage db_load_metadefs should use 'with open as...'
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1367172 Title: glance-manage db_load_metadefs should use 'with open as...' Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Bug description: Currently script which loads metadeta definitions to database uses try except block with open(file) inside. There is better solution in Python for file streams - use 'with open(file) as...'. With this approach we will be sure that every resource is cleaned up when the code finishes running. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1367172/+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 1040772] Re: Tweak logging of process id
** Changed in: glance
Status: Fix Committed = Fix Released
** Changed in: glance
Milestone: None = juno-rc1
--
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/1040772
Title:
Tweak logging of process id
Status in OpenStack Image Registry and Delivery Service (Glance):
Fix Released
Status in OpenStack Compute (Nova):
Fix Released
Status in openstack-common:
Fix Released
Bug description:
I'd like to suggest tweaking how we log process id.
Currently the log looks like:
2012-08-21 12:16:36 DEBUG glance.store [-] Attempting to import store
glance.store.filesystem.Store from (pid=16913) _get_store_class
/usr/lib/python2.7/dist-packages/glance/store/__init__.py:146
2012-08-21 12:16:36 DEBUG glance.store [-] Registering store class
'glance.store.filesystem.Store' with schemes ('file', 'filesystem') from
(pid=16913) create_stores
/usr/lib/python2.7/dist-packages/glance/store/__init__.py:176
2012-08-21 12:16:36 DEBUG glance.store.base [-] Late loading location class
glance.store.filesystem.StoreLocation from (pid=16913) get_store_location_class
/usr/lib/python2.7/dist-packages/glance/store/base.py:68
I find it tricky to see if these are from the same process on the
server or not.
Tweaking to be in a fixed position like:
2012-08-23 16:40:48 DEBUG 11141 glance.api.middleware.version_negotiation [-]
Using url versioning process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:55
2012-08-23 16:40:48 DEBUG 11141 glance.api.middleware.version_negotiation [-]
Matched version: v1 process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:67
2012-08-23 16:40:48 DEBUG 11141 glance.api.middleware.version_negotiation [-]
new uri /v1/images/48fb03f5-2dfe-4a6e-8b60-8260158edb72 process_request
/usr/lib/python2.7/dist-packages/glance/api/middleware/version_negotiation.py:68
makes it easier to track which requests are being handled by which
processes.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1040772/+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 1365061] Re: Warn against sorting requirements
** Changed in: glance Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1365061 Title: Warn against sorting requirements Status in Cinder: Fix Committed Status in Designate: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Identity (Keystone) Middleware: Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Fix Committed Status in Python client library for Keystone: Invalid Status in OpenStack Object Storage (Swift): Fix Committed Bug description: Contrary to bug 1285478, requirements files should not be sorted alphabetically. Given that requirements files can contain comments, I'd suggest a header in all requirements files along the lines of: # The order of packages is significant, because pip processes them in the order # of appearance. Changing the order has an impact on the overall integration # process, which may cause wedges in the gate later. This is the result of a mailing list discussion (thanks, Sean!): http://www.mail-archive.com/openstack- d...@lists.openstack.org/msg33927.html To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1365061/+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 1375625] [NEW] Problem in l3-agent tunnel interface would cause split-brain in HA router
Public bug reported: Assuming l3-agents have 1 NIC (ie eth0) assigned to tenant-network (tunnel) traffic and another (ie eth1) assigned to external network,. Disconnecting eth0 would prevent keeplived reports and trigger one of the slaves to become master. However, since the error is outside the router namespace, the original master is unaware of that and would not trigger fault state. Instead it will continue to receive traffic on the, yet active, external network interface - eth1. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ha -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1375625 Title: Problem in l3-agent tunnel interface would cause split-brain in HA router Status in OpenStack Neutron (virtual network service): New Bug description: Assuming l3-agents have 1 NIC (ie eth0) assigned to tenant-network (tunnel) traffic and another (ie eth1) assigned to external network,. Disconnecting eth0 would prevent keeplived reports and trigger one of the slaves to become master. However, since the error is outside the router namespace, the original master is unaware of that and would not trigger fault state. Instead it will continue to receive traffic on the, yet active, external network interface - eth1. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1375625/+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 1263067] Re: Glance HTTP store doesn't work behind proxy
** Also affects: python-glanceclient Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1263067 Title: Glance HTTP store doesn't work behind proxy Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Python client library for Glance: New Bug description: If Glance is deployed in an environment which require proxy for most connections than images stored in the http store will fail to be downloaded because the HTTP store use httplib (low level http library) which doesn't care about any proxy settings. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1263067/+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 1375688] [NEW] test failure in ShelveComputeManagerTestCase.test_unshelve
Public bug reported:
Full logs here: http://logs.openstack.org/02/124402/3/check/gate-nova-
python26/1d3512b/
Seen:
2014-09-26 15:20:46.795 | ExpectedMethodCallsError: Verify: Expected
methods never called:
2014-09-26 15:20:46.796 | 0.
_notify_about_instance_usage.__call__(nova.context.RequestContext object at
0xcf5e990,
Instance(access_ip_v4=None,access_ip_v6=None,architecture='x86_64',auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,config_drive=None,created_at=2014-09-26T15:09:38Z,default_ephemeral_device=None,default_swap_device=None,deleted=False,deleted_at=None,disable_terminate=False,display_description=None,display_name=None,ephemeral_gb=0,ephemeral_key_uuid=None,fault=?,host='fake-mini',hostname=None,id=1,image_ref='fake-image-ref',info_cache=?,instance_type_id=2,kernel_id=None,key_data=None,key_name=None,launch_index=None,launched_at=2014-09-26T15:09:39Z,launched_on=None,locked=False,locked_by=None,memory_mb=0,metadata={},node='fakenode1',numa_topology=?,os_type='Linux',pci_devices=?,power_state=123,progress=None,project_id='fake',ramdisk_id=None,reservation_id='r-fakeres',root_device_name=None,root_gb=0,scheduled_at=None,security_gro
ups=?,shutdown_terminate=False,system_metadata={instance_type_ephemeral_gb='0',instance_type_flavorid='1',instance_type_id='2',instance_type_memory_mb='512',instance_type_name='m1.tiny',instance_type_root_gb='1',instance_type_rxtx_factor='1.0',instance_type_swap='0',instance_type_vcpu_weight=None,instance_type_vcpus='1'},task_state=None,terminated_at=None,updated_at=2014-09-26T15:09:38Z,user_data=None,user_id='fake',uuid=cb73da32-e73e-4f52-a332-f66e9752ac9d,vcpus=0,vm_mode=None,vm_state='active'),
'unshelve.end') - None
and:
2014-09-26 15:20:46.800 | UnexpectedMethodCallError: Unexpected
method call
instance_update_and_get_original.__call__(nova.context.RequestContext
object at 0xcf5e990, 'cb73da32-e73e-4f52-a332-f66e9752ac9d',
{'vm_state': u'active', 'expected_task_state': 'spawning', 'key_data':
None, 'host': u'fake-mini', 'image_ref': u'fake-image-ref',
'power_state': 123, 'auto_disk_config': False, 'task_state': None,
'launched_at': datetime.datetime(2014, 9, 26, 15, 9, 39, 224533,
tzinfo=iso8601.iso8601.Utc object at 0xa8b48d0)},
columns_to_join=['metadata', 'system_metadata'], update_cells=False) -
None
My initial reaction is that the mox error messages don't contain enough
information to diagnose the problem, or at least they certainly don't
make it obvious to the uninitiated, due to the missing expected values.
** Affects: nova
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/1375688
Title:
test failure in ShelveComputeManagerTestCase.test_unshelve
Status in OpenStack Compute (Nova):
New
Bug description:
Full logs here: http://logs.openstack.org/02/124402/3/check/gate-nova-
python26/1d3512b/
Seen:
2014-09-26 15:20:46.795 | ExpectedMethodCallsError: Verify: Expected
methods never called:
2014-09-26 15:20:46.796 | 0.
_notify_about_instance_usage.__call__(nova.context.RequestContext object at
0xcf5e990,
Instance(access_ip_v4=None,access_ip_v6=None,architecture='x86_64',auto_disk_config=False,availability_zone=None,cell_name=None,cleaned=False,config_drive=None,created_at=2014-09-26T15:09:38Z,default_ephemeral_device=None,default_swap_device=None,deleted=False,deleted_at=None,disable_terminate=False,display_description=None,display_name=None,ephemeral_gb=0,ephemeral_key_uuid=None,fault=?,host='fake-mini',hostname=None,id=1,image_ref='fake-image-ref',info_cache=?,instance_type_id=2,kernel_id=None,key_data=None,key_name=None,launch_index=None,launched_at=2014-09-26T15:09:39Z,launched_on=None,locked=False,locked_by=None,memory_mb=0,metadata={},node='fakenode1',numa_topology=?,os_type='Linux',pci_devices=?,power_state=123,progress=None,project_id='fake',ramdisk_id=None,reservation_id='r-fakeres',root_device_name=None,root_gb=0,scheduled_at=None,security_g
roups=?,shutdown_terminate=False,system_metadata={instance_type_ephemeral_gb='0',instance_type_flavorid='1',instance_type_id='2',instance_type_memory_mb='512',instance_type_name='m1.tiny',instance_type_root_gb='1',instance_type_rxtx_factor='1.0',instance_type_swap='0',instance_type_vcpu_weight=None,instance_type_vcpus='1'},task_state=None,terminated_at=None,updated_at=2014-09-26T15:09:38Z,user_data=None,user_id='fake',uuid=cb73da32-e73e-4f52-a332-f66e9752ac9d,vcpus=0,vm_mode=None,vm_state='active'),
'unshelve.end') - None
and:
2014-09-26 15:20:46.800 | UnexpectedMethodCallError: Unexpected
method call
instance_update_and_get_original.__call__(nova.context.RequestContext
object at 0xcf5e990, 'cb73da32-e73e-4f52-a332-f66e9752ac9d',
{'vm_state': u'active', 'expected_task_state': 'spawning', 'key_data':
None, 'host': u'fake-mini',
[Yahoo-eng-team] [Bug 1375698] [NEW] mlnx agent throws exception - unbound method sleep()
Public bug reported: Traceback: 2014-09-30 13:28:53.603 529 DEBUG neutron.plugins.mlnx.agent.utils [req-a040c7ec-9a06-4f85-9420-60d6c4ca376e None] get_attached_vnics get_attached_vnics /opt/stack/neutron/neutron/plugins/mlnx/agent/utils.py:81 2014-09-30 13:28:56.608 529 DEBUG neutron.plugins.mlnx.common.comm_utils [req-a040c7ec-9a06-4f85-9420-60d6c4ca376e None] Request timeout - call again after 3 seconds decorated /opt/stack/neutron/neutron/plugins/mlnx/common/comm_utils.py:58 2014-09-30 13:28:56.608 529 CRITICAL neutron [req-a040c7ec-9a06-4f85-9420-60d6c4ca376e None] TypeError: unbound method sleep() must be called with RetryDecorator instance as first argument (got int instance instead) 2014-09-30 13:28:56.608 529 TRACE neutron Traceback (most recent call last): 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 426, in module 2014-09-30 13:28:56.608 529 TRACE neutron main() 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 421, in main 2014-09-30 13:28:56.608 529 TRACE neutron agent.daemon_loop() 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 373, in daemon_loop 2014-09-30 13:28:56.608 529 TRACE neutron port_info = self.scan_ports(previous=port_info, sync=sync) 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 247, in scan_ports 2014-09-30 13:28:56.608 529 TRACE neutron cur_ports = self.eswitch.get_vnics_mac() 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 63, in get_vnics_mac 2014-09-30 13:28:56.608 529 TRACE neutron return set(self.utils.get_attached_vnics().keys()) 2014-09-30 13:28:56.608 529 TRACE neutron File /opt/stack/neutron/neutron/plugins/mlnx/agent/utils.py, line 83, in get_attached_vnics 2014-09-30 13:28:56.608 529 TRACE neutron vnics = self.send_msg(msg) 2014-09-30 13:28:56.608 529 TRACE neutron File /opt/stack/neutron/neutron/plugins/mlnx/common/comm_utils.py, line 59, in decorated 2014-09-30 13:28:56.608 529 TRACE neutron RetryDecorator.sleep_fn(sleep_interval) 2014-09-30 13:28:56.608 529 TRACE neutron TypeError: unbound method sleep() must be called with RetryDecorator instance as first argument (got int instance instead) ** Affects: neutron Importance: Undecided Assignee: Samer Deeb (samerd) Status: New ** Tags: mellanox ml2 ** Tags added: mellanox ** Tags added: ml2 ** Changed in: neutron Assignee: (unassigned) = Samer Deeb (samerd) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1375698 Title: mlnx agent throws exception - unbound method sleep() Status in OpenStack Neutron (virtual network service): New Bug description: Traceback: 2014-09-30 13:28:53.603 529 DEBUG neutron.plugins.mlnx.agent.utils [req-a040c7ec-9a06-4f85-9420-60d6c4ca376e None] get_attached_vnics get_attached_vnics /opt/stack/neutron/neutron/plugins/mlnx/agent/utils.py:81 2014-09-30 13:28:56.608 529 DEBUG neutron.plugins.mlnx.common.comm_utils [req-a040c7ec-9a06-4f85-9420-60d6c4ca376e None] Request timeout - call again after 3 seconds decorated /opt/stack/neutron/neutron/plugins/mlnx/common/comm_utils.py:58 2014-09-30 13:28:56.608 529 CRITICAL neutron [req-a040c7ec-9a06-4f85-9420-60d6c4ca376e None] TypeError: unbound method sleep() must be called with RetryDecorator instance as first argument (got int instance instead) 2014-09-30 13:28:56.608 529 TRACE neutron Traceback (most recent call last): 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 426, in module 2014-09-30 13:28:56.608 529 TRACE neutron main() 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 421, in main 2014-09-30 13:28:56.608 529 TRACE neutron agent.daemon_loop() 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 373, in daemon_loop 2014-09-30 13:28:56.608 529 TRACE neutron port_info = self.scan_ports(previous=port_info, sync=sync) 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 247, in scan_ports 2014-09-30 13:28:56.608 529 TRACE neutron cur_ports = self.eswitch.get_vnics_mac() 2014-09-30 13:28:56.608 529 TRACE neutron File agent/eswitch_neutron_agent.py, line 63, in get_vnics_mac 2014-09-30 13:28:56.608 529 TRACE neutron return set(self.utils.get_attached_vnics().keys()) 2014-09-30 13:28:56.608 529 TRACE neutron File /opt/stack/neutron/neutron/plugins/mlnx/agent/utils.py, line 83, in get_attached_vnics 2014-09-30 13:28:56.608 529 TRACE neutron vnics = self.send_msg(msg) 2014-09-30 13:28:56.608 529 TRACE neutron File /opt/stack/neutron/neutron/plugins/mlnx/common/comm_utils.py, line 59, in decorated 2014-09-30 13:28:56.608 529 TRACE neutron
[Yahoo-eng-team] [Bug 1374497] Re: change in oslo.db ping handling is causing issues in projects that are not using transactions
** Also affects: oslo.db/juno Importance: High Assignee: Mike Bayer (zzzeek) Status: In Progress ** No longer affects: oslo.db/juno ** Also affects: oslo.db/juno Importance: Undecided Status: New ** Changed in: oslo.db/juno Milestone: None = 1.0.2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1374497 Title: change in oslo.db ping handling is causing issues in projects that are not using transactions Status in OpenStack Identity (Keystone): Triaged Status in Oslo Database library: Fix Committed Status in oslo.db juno series: Triaged Bug description: in https://review.openstack.org/#/c/106491/, the ping listener which emits SELECT 1 at connection start was moved from being a connection pool checkout handler to a transaction on begin handler. Apparently Keystone and possibly others are using the Session in autocommit mode, despite that this is explicitly warned against in SQLAlchemy's docs (see http://docs.sqlalchemy.org/en/rel_0_9/orm/session.html#autocommit- mode), and for these projects they are seeing failed connections not transparently recovered (see https://bugs.launchpad.net/keystone/+bug/1361378). Alternatives include: 1. move the ping listener back to being a checkout handler 2. fix downstream projects to not use the session in autocommit mode In all likelihood, the fix here should involve both. I have a longer term plan to fix EngineFacade once and for all so that the correct use patterns are explicit, but that still has to be blueprinted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1374497/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1375772] [NEW] Authenicate fails with IndexError exception with LDAP and user_enabled_emulation
Public bug reported: I am running latest keystone from git (82ded4a) and am using keystone configured with the LDAP and using user_enabled_emulation. I get the exception IndexError: string index out of range when trying to authenticate. My research suggests that it's the commit that fixed bug 1340041 that introduced this bug. Everything works when I revert the commit that fixed that. The problem is the following: in line 1672 (keystone/common/ldap/core.py) for the patch for the above bug the ldap.dn.str2dn array gets converted to a string which causes naming_rdn to contain [ and then I get an exception on line 1675 because the string has length one. ** Affects: keystone Importance: Undecided Status: New ** Description changed: I am running latest keystone from git (82ded4a) and am using keystone configured with the LDAP and using user_enabled_emulation. I get the exception IndexError: string index out of range when trying to authenticate. - My research suggests that it's the commit that fixed bug 1340041 - (https://launchpad.net/bugs/1340041) that introduced this bug. - Everything works when I revert the commit that fixed that. + My research suggests that it's the commit that fixed bug 1340041 that + introduced this bug. Everything works when I revert the commit that + fixed that. The problem is the following: in line 1672 (keystone/common/ldap/core.py) for the patch for the above bug the ldap.dn.str2dn array gets converted to a string which causes naming_rdn to contain [ and then I get an exception on line 1675 because the string has length one. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1375772 Title: Authenicate fails with IndexError exception with LDAP and user_enabled_emulation Status in OpenStack Identity (Keystone): New Bug description: I am running latest keystone from git (82ded4a) and am using keystone configured with the LDAP and using user_enabled_emulation. I get the exception IndexError: string index out of range when trying to authenticate. My research suggests that it's the commit that fixed bug 1340041 that introduced this bug. Everything works when I revert the commit that fixed that. The problem is the following: in line 1672 (keystone/common/ldap/core.py) for the patch for the above bug the ldap.dn.str2dn array gets converted to a string which causes naming_rdn to contain [ and then I get an exception on line 1675 because the string has length one. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1375772/+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 1375783] [NEW] Improper error message during create subnet
Public bug reported: Admin-System-Networks-[click a network name]-Create Subnet Provide a name, click next. The message 'Specify Network Address or clear Create Subnet checkbox.' is displayed, but no Create Subnet checkbox is present. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1375783 Title: Improper error message during create subnet Status in OpenStack Dashboard (Horizon): New Bug description: Admin-System-Networks-[click a network name]-Create Subnet Provide a name, click next. The message 'Specify Network Address or clear Create Subnet checkbox.' is displayed, but no Create Subnet checkbox is present. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1375783/+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 1372441] Re: Creating port in dual-stack network requires IPv4 and IPv6 addresses to be allocated
Fix proposed to branch: master Review: https://review.openstack.org/125061 ** Changed in: neutron Status: Opinion = In Progress ** Changed in: neutron Assignee: (unassigned) = Alexey I. Froloff (raorn) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1372441 Title: Creating port in dual-stack network requires IPv4 and IPv6 addresses to be allocated Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently, when creating port in dual-stack network (network with one ore more IPv4 subnets and one or more IPv6 subnets), Neutron allocates fixed-ip from both, v4 and v6 subnets. If one of the subnets do not have available addresses, it is considered as error. IMO, this is wrong. Operation should succeed if at least one address (IPv4 of IPv6) was allocated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1372441/+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 1375815] [NEW] RFE: detect obvious MTU mismatches for tunnelling and print a warning
Public bug reported: Hi, It was non-obvious to me (and I suspect it will be non-obvious to a lot of others) that it really is absolutely necessary to increase the MTU when using VXLAN encapsulation (and presumably GRE and other tunnelling as well). The principal difficulty in diagnosis is that resulting VM behaviour is just so strange: depending on the guest and hypervisor kernel used and whether GSO is disabled on each using ethtool, network traffic may almost not flow at all, or be almost normal. Very belatedly I spotted the doc note referenced in openstack-manuals commit c3ba506e97d59969ee2ad9476e8d1dfa55001641 , and this is a good start. However, I think more is needed. This RFE is for neutron to sanity check for obvious MTU mismatches at startup (it may not be possible to catch all of them, but surely the obvious ones would be better than nothing) and print out a big warning. For example, I'd say if VXLAN is configured + the MTU on the default gateway is 1500 + the MTU on the VXLAN network is = 1554 (or whatever), then print a warning. Ditto for GRE, etc., etc. It would be good if the warning said something like MTU settings *may* be wrong: consult OpenStack documentation link for more details. ** 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/1375815 Title: RFE: detect obvious MTU mismatches for tunnelling and print a warning Status in OpenStack Neutron (virtual network service): New Bug description: Hi, It was non-obvious to me (and I suspect it will be non-obvious to a lot of others) that it really is absolutely necessary to increase the MTU when using VXLAN encapsulation (and presumably GRE and other tunnelling as well). The principal difficulty in diagnosis is that resulting VM behaviour is just so strange: depending on the guest and hypervisor kernel used and whether GSO is disabled on each using ethtool, network traffic may almost not flow at all, or be almost normal. Very belatedly I spotted the doc note referenced in openstack-manuals commit c3ba506e97d59969ee2ad9476e8d1dfa55001641 , and this is a good start. However, I think more is needed. This RFE is for neutron to sanity check for obvious MTU mismatches at startup (it may not be possible to catch all of them, but surely the obvious ones would be better than nothing) and print out a big warning. For example, I'd say if VXLAN is configured + the MTU on the default gateway is 1500 + the MTU on the VXLAN network is = 1554 (or whatever), then print a warning. Ditto for GRE, etc., etc. It would be good if the warning said something like MTU settings *may* be wrong: consult OpenStack documentation link for more details. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1375815/+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 1209421] Re: nova.tests.virt.test_virt_drivers doesn't produce a support matrix as documented
As noted in comment #5 a patch has been merged which removes the comments in test_virt_drivers indicating a hypervisor matrix should be generated from the unit test compute driver subclass execution. As discussed (above) in this bug; if hypervisor support matrix dynamic generation is needed, we should seek to implement that at the integration test level to provide a more complete picture of driver support. Closing this as as won't fix since there are no current plans to generate a matrix during UT. ** Changed in: nova Status: In Progress = Won't Fix -- 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/1209421 Title: nova.tests.virt.test_virt_drivers doesn't produce a support matrix as documented Status in OpenStack Compute (Nova): Won't Fix Bug description: nova/tests/virt/test_virt_drivers.py has a class called _VirtDriverTestCase That is used to check which functions virt driver support and to help generate a support matrix. But nova/tests/virt/test_virt_drivers.py only tets libvirt, and the fake driver, and does not provide any mechanism to automatically generate the support matrix. This file should test all virt drivers and provide a way to produce a support matrix. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1209421/+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 1375820] [NEW] Html files littered with nbsp;
Public bug reported: In our html files 'nbsp;' are being used to add extra padding in places.The nbsp; should be removed and instead use css to add in the padding if needed. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1375820 Title: Html files littered with nbsp; Status in OpenStack Dashboard (Horizon): New Bug description: In our html files 'nbsp;' are being used to add extra padding in places.The nbsp; should be removed and instead use css to add in the padding if needed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1375820/+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 1361230] Re: ad248f6 jsonutils sync breaks if simplejson 2.2.0 (under python 2.6)
** Changed in: ceilometer Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1361230 Title: ad248f6 jsonutils sync breaks if simplejson 2.2.0 (under python 2.6) Status in OpenStack Telemetry (Ceilometer): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in The Oslo library incubator: Fix Released Status in Oslo library for sending and saving object: Fix Released Status in Taskflow for task-oriented systems.: Fix Committed Bug description: This keystone sync: https://github.com/openstack/keystone/commit/94efafd6d6066f63a9226a6b943d0e86699e7edd Pulled in this change to jsonutils: https://review.openstack.org/#/c/113760/ That uses a flag in json.dumps which is only in simplejson = 2.2.0. If you don't have a new enough simplejson the keystone database migrations fail. Keystone doesn't even list simplejson as a requirement and oslo- incubator lists simplejson = 2.0.9 as a test-requirement since it's optional in the code. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1361230/+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 1319277] Re: volume backend snapshot not set image_type
What level of code are you using? The nova.compute.api.snapshot method calls _create_backup and passes image_type='snapshot' which should be set in the image metadata when the image is created: http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/api.py?id=2014.2.b3#n1944 ** Changed in: nova Status: Confirmed = Invalid -- 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/1319277 Title: volume backend snapshot not set image_type Status in OpenStack Compute (Nova): Invalid Bug description: Snapshot an instance with ephemeral volume, the created image has the image_type which is snapshot. Snapshot an instance with cinder backend volume , the created image doesn't has the image_type. Need to set the image_type with the value snapshot for the instance's snapshot which is cinder backend volume. Modify the function compute_api.snapshot_volume_backed, and add the image_type properties for the image. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1319277/+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 1359407] Re: tempest errors in logs
** Changed in: ceilometer Status: Fix Committed = Fix Released ** Changed in: ceilometer Milestone: None = juno-rc1 -- 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/1359407 Title: tempest errors in logs Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: Incomplete Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): Incomplete Bug description: This is regarding a tempest run on a Keystone change, here's the log: http://logs.openstack.org/73/111573/3/check/check-tempest-dsvm-full/f4e3313/console.html All the tempest tests ran successfully. Then it runs the log checker and there are several errors in the logs. - Log File Has Errors: n-cond nova.quota - Failed to commit reservations ... - Log File Has Errors: n-cpu There's several errors here: glanceclient.common.http -- Request returned failure status 404. (there's several of these) oslo.messaging.rpc.dispatcher -- Exception during message handling: Unexpected task state: expecting (u'powering-off',) but the actual state is None (this generates a lot of logs and there are several of them) - Log File Has Errors: n-api glanceclient.common.http - Request returned failure status 404. (there's several of these) - Log File Has Errors: g-api glance.store.sheepdog [-] Error in store configuration: [Errno 2] No such file or directory swiftclient [-] Container HEAD failed: http://127.0.0.1:8080/v1/AUTH_3c05c27e027f451b9837e04c9d8ae1e5/glance 404 Not Found - Log File Has Errors: c-api ERROR cinder.volume.api Volume status must be available to reserve (There's 4 of these) - Log File Has Errors: ceilometer-alarm-evaluator ceilometer.alarm.service [-] alarm evaluation cycle failed (several of these) - Log File Has Errors: ceilometer-acentral ERROR ceilometer.neutron_client [-] publicURL endpoint for network service not found (there's several errors related to endpoints) - Log File Has Errors: ceilometer-acompute ceilometer.compute.pollsters.disk [-] Ignoring instance instance-0087: internal error: cannot find statistics for device 'virtio-disk1' (there's a few of these) To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1359407/+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 1372049] Re: Launching multiple VMs fails over 63 instances
Able to reproduce on devstack. Inspecting logs (n-cpu, n-api, q-svc) shows that this is not a neutron issue: q-svc sends vif_plugged event in time (no timeout on n-cpu), n-api accepts the event and sends it to n-cpu by RPC. For some reason n-cpu starts to handle this event when timeout has already occured (several minutes past the event was sent from n-api). Increasing vif_plugging_timeout does not solve the issue, so obviosly there is some race in n-cpu. Will dig more into it. ** Changed in: neutron Status: Incomplete = Invalid ** Changed in: nova Importance: Low = High ** Changed in: neutron Assignee: Oleg Bondarev (obondarev) = (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1372049 Title: Launching multiple VMs fails over 63 instances Status in OpenStack Neutron (virtual network service): Invalid Status in OpenStack Compute (Nova): Incomplete Bug description: RHEL-7.0 Icehouse All-In-One Booting 63 VMs at once (with num-instances attribute) works fine. Setup is able to support up to 100 VMs booted in ~50 bulks. Booting 100 VMs at once, without Neutron network, so no network for the VMs, works fine. Booting 64 (and more) VMs boots only 63 VMs. any of the VMs over 63 are booted in ERROR state with details: VirtualInterfaceCreateException: Virtual Interface creation failed Failed VM's port at DOWN state Details: After the initial boot commands goes through, all CPU usage goes down (no neutron/nova CPU consumption) untll nova's vif_plugging_timeout is reached. at which point 1 (= #num_instances - 63) VM is set to ERROR, and the rest of the VMs reach active state. Guess: seems like neutron is going into some deadlock until some of the load is reduced by vif_plugging_timeout disabling neutorn-nova port notifications allows all VMs to be created. Notes: this is recreated also with multiple Compute nodes, and also multiple neutron RPC/API workers Recreate: set nova/neutron quota's to -1 make sure neutorn-nova port notifications is ON on both neutron and nova conf files create a network in your tenant boot more than 64 VMs nova boot --flavor 42 test_VM --image cirros --num-instances 64 [yfried@yfried-mobl-rh ~(keystone_demo)]$ nova list +--+--+++-+-+ | ID | Name | Status | Task State | Power State | Networks| +--+--+++-+-+ | 02d7b680-efd8-4291-8d56-78b43c9451cb | test_VM-02d7b680-efd8-4291-8d56-78b43c9451cb | ACTIVE | - | Running | demo_private=10.0.0.156 | | 05fd6dd2-6b0e-4801-9219-ae4a77a53cfd | test_VM-05fd6dd2-6b0e-4801-9219-ae4a77a53cfd | ACTIVE | - | Running | demo_private=10.0.0.150 | | 09131f19-5e83-4a40-a900-ffca24a8c775 | test_VM-09131f19-5e83-4a40-a900-ffca24a8c775 | ACTIVE | - | Running | demo_private=10.0.0.160 | | 0d3be93b-73d3-4995-913c-03a4b80ad37e | test_VM-0d3be93b-73d3-4995-913c-03a4b80ad37e | ACTIVE | - | Running | demo_private=10.0.0.164 | | 0fcadae4-768c-44a1-9e1c-ac371d1803f9 | test_VM-0fcadae4-768c-44a1-9e1c-ac371d1803f9 | ACTIVE | - | Running | demo_private=10.0.0.202 | | 11a87db1-5b15-4cad-a749-5d53e2fd8194 | test_VM-11a87db1-5b15-4cad-a749-5d53e2fd8194 | ACTIVE | - | Running | demo_private=10.0.0.201 | | 147e4a6b-a77c-46ef-b8fd-d65479ccb8ca | test_VM-147e4a6b-a77c-46ef-b8fd-d65479ccb8ca | ACTIVE | - | Running | demo_private=10.0.0.147 | | 1c5b5f40-d2f3-4cc7-9f80-f5df8de918b9 | test_VM-1c5b5f40-d2f3-4cc7-9f80-f5df8de918b9 | ACTIVE | - | Running | demo_private=10.0.0.187 | | 1d0b7210-f5a0-4827-b338-2014e8f21341 | test_VM-1d0b7210-f5a0-4827-b338-2014e8f21341 | ACTIVE | - | Running | demo_private=10.0.0.165 | | 1df564f6-5aac-4ac8-8361-bd44c305332b | test_VM-1df564f6-5aac-4ac8-8361-bd44c305332b | ACTIVE | - | Running | demo_private=10.0.0.145 | | 2031945f-6305-4cdc-939f-5f02171f82b2 | test_VM-2031945f-6305-4cdc-939f-5f02171f82b2 | ACTIVE | - | Running | demo_private=10.0.0.149 | | 256ff0ed-0e56-47e3-8b69-68006d658ad6 | test_VM-256ff0ed-0e56-47e3-8b69-68006d658ad6 | ACTIVE | - | Running | demo_private=10.0.0.177 | | 2b7256a8-c04a-42cf-9c19-5836b585c0f5 | test_VM-2b7256a8-c04a-42cf-9c19-5836b585c0f5 | ACTIVE | - | Running | demo_private=10.0.0.180 | | 2daac227-e0c9-4259-8e8e-b8a6e93b45e3 | test_VM-2daac227-e0c9-4259-8e8e-b8a6e93b45e3 | ACTIVE | - | Running |
[Yahoo-eng-team] [Bug 1375857] [NEW] It's not possibile to pass the cacert to the swift store
Public bug reported: The swift store device defined in the glance store doesn't allow to pass the ca cert file. When the driver creates a connection via the swift client it is not possible to pass that value. That means that if we have swift running on TLS in some cases we have to set the insecure option equals to True as the client can't correctly complete the handshake as it fails on the verification of the cert. The fix I'd like to propose is to add a new parameter to define the ca cert file and pass this value when we create the connection via the swift client. ** Affects: glance Importance: Undecided Assignee: Andrea Rosa (andrea-rosa-m) Status: New ** Tags: store swift ** Changed in: glance Assignee: (unassigned) = Andrea Rosa (andrea-rosa-m) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: The swift store device defined in the glance store doesn't allow to pass the ca cert file. When the driver creates a connection via the swift client it is not possible to pass that value. That means that if we have swift running on TLS in some cases we have to set the insecure option equals to True as the client can't correctly complete the handshake as it fails on the verification of the cert. The fix I'd like to propose is to add a new parameter to define the ca cert file and pass this value when we create the connection via the swift client. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1375857/+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 1317831] Re: debug level logs should not be translated
This has previously been resolved over the Juno cycle. At this point, I'm going to mark this now as invalid since I'm not finding any debug logs that are still translated (in the case of debug specific messaging). ** Changed in: keystone Status: Triaged = 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/1317831 Title: debug level logs should not be translated Status in OpenStack Identity (Keystone): Invalid Bug description: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317831/+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 1375868] [NEW] libvirt: race between hot unplug and XMLDesc in _get_instance_disk_info
Public bug reported: THis came up when analyzing https://bugs.launchpad.net/nova/+bug/1371677 and there is a lot information on there. The bug in short is that _get_instance_disk_info will rely on db information to filter out the volumes from the list of discs it gets from libvirt XML, but due to the async nature of unplug - this can still contain a volume that does not exist in the DB and will not be filtered out, so the code will assume it's an lvm image and do a blockdev on it which can block for a very long time. The solution is to NOT use libvirt XML in this particular case (but anywhere in Nova really) to find out information about running instances. ** Affects: nova Importance: High Status: New ** Tags: libvirt -- 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/1375868 Title: libvirt: race between hot unplug and XMLDesc in _get_instance_disk_info Status in OpenStack Compute (Nova): New Bug description: THis came up when analyzing https://bugs.launchpad.net/nova/+bug/1371677 and there is a lot information on there. The bug in short is that _get_instance_disk_info will rely on db information to filter out the volumes from the list of discs it gets from libvirt XML, but due to the async nature of unplug - this can still contain a volume that does not exist in the DB and will not be filtered out, so the code will assume it's an lvm image and do a blockdev on it which can block for a very long time. The solution is to NOT use libvirt XML in this particular case (but anywhere in Nova really) to find out information about running instances. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1375868/+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 1375883] [NEW] unbundle bootstrap
Public bug reported: Horizon still has some leftover static file libraries bundled. One of them is the Bootstrap CSS framework. We have the xstatic package for it in the requirements already and all the bugs cleared, so all that is left is to actually unbundle it. ** Affects: horizon Importance: High Assignee: Radomir Dopieralski (thesheep) Status: In Progress ** Changed in: horizon Milestone: None = juno-rc1 ** Changed in: horizon Importance: Undecided = High ** Changed in: horizon Status: New = In Progress ** Changed in: horizon Assignee: (unassigned) = Radomir Dopieralski (thesheep) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1375883 Title: unbundle bootstrap Status in OpenStack Dashboard (Horizon): In Progress Bug description: Horizon still has some leftover static file libraries bundled. One of them is the Bootstrap CSS framework. We have the xstatic package for it in the requirements already and all the bugs cleared, so all that is left is to actually unbundle it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1375883/+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 1375908] [NEW] Login timeouts when logging in with LDAP user with non ascii characters in CN LDAP field
Public bug reported: Connected with bug report: https://bugs.launchpad.net/keystone/+bug/1375139 With enabled debug in local_settings this is the last thing that gets logged before timeout. If I disable Cinder (keystone endpoint delete) login succeed. from http error/debug log: [Tue Sep 30 18:10:08 2014] [error] REQ: curl -i http://192.168.122.11:8776/v1/faabdcb060924e15ab8c193b3f82864e/limits -X GET -H X-Auth-Project-Id: faabdcb060924e15ab8c193b3f82864e -H User-Agent: python-cinderclient -H Accept: application/json -H X-Auth-Token: 7d061e89df785976e2547b48b7ef05e1 ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1375908 Title: Login timeouts when logging in with LDAP user with non ascii characters in CN LDAP field Status in OpenStack Dashboard (Horizon): New Bug description: Connected with bug report: https://bugs.launchpad.net/keystone/+bug/1375139 With enabled debug in local_settings this is the last thing that gets logged before timeout. If I disable Cinder (keystone endpoint delete) login succeed. from http error/debug log: [Tue Sep 30 18:10:08 2014] [error] REQ: curl -i http://192.168.122.11:8776/v1/faabdcb060924e15ab8c193b3f82864e/limits -X GET -H X-Auth-Project-Id: faabdcb060924e15ab8c193b3f82864e -H User-Agent: python-cinderclient -H Accept: application/json -H X-Auth-Token: 7d061e89df785976e2547b48b7ef05e1 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1375908/+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 1375909] [NEW] upgrade_packages broken in zypper/openSUSE
Public bug reported: Given the following setting in user data: #cloud-config package_upgrade: true cloud-init will fail to upgrade packages on openSUSE (and probably SLES) distro. The reason for this is that cloud-init calls cloud.distro.package_command(upgrade) to upgrade packages, where the given argument is passed directly to zypper. But unlike apt-get on Debian-based systems, zypper uses command update to upgrade packages. I am including simple patch to sles.py, which will modify argument in package_command, but it would be probably better to add new function (e. g. upgrade_packages) and call this in cc_package_update_upgrade_install.py instead of package_command(upgrade). ** Affects: cloud-init Importance: Undecided Status: New ** Patch added: Patch for cloudinit/distros/sles.py https://bugs.launchpad.net/bugs/1375909/+attachment/4220455/+files/sles.py.patch -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1375909 Title: upgrade_packages broken in zypper/openSUSE Status in Init scripts for use on cloud images: New Bug description: Given the following setting in user data: #cloud-config package_upgrade: true cloud-init will fail to upgrade packages on openSUSE (and probably SLES) distro. The reason for this is that cloud-init calls cloud.distro.package_command(upgrade) to upgrade packages, where the given argument is passed directly to zypper. But unlike apt-get on Debian-based systems, zypper uses command update to upgrade packages. I am including simple patch to sles.py, which will modify argument in package_command, but it would be probably better to add new function (e. g. upgrade_packages) and call this in cc_package_update_upgrade_install.py instead of package_command(upgrade). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1375909/+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
