[Yahoo-eng-team] [Bug 1298158] Re: Miss validation of backup_type
** Changed in: nova Status: New => 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/1298158 Title: Miss validation of backup_type Status in OpenStack Compute (Nova): Invalid Bug description: When backup instance, Nova will don't validate the backup_type. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298158/+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 1298158] [NEW] Miss validation of backup_type
Public bug reported: When backup instance, Nova will don't validate the backup_type. ** Affects: nova Importance: Undecided Assignee: Liusheng (liusheng) Status: New ** Changed in: nova Assignee: (unassigned) => Liusheng (liusheng) -- 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/1298158 Title: Miss validation of backup_type Status in OpenStack Compute (Nova): New Bug description: When backup instance, Nova will don't validate the backup_type. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298158/+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 1298157] [NEW] Miss validation of backup_type
Public bug reported: When backup instance, Nova will don't validate the backup_type. ** 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/1298157 Title: Miss validation of backup_type Status in OpenStack Compute (Nova): New Bug description: When backup instance, Nova will don't validate the backup_type. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298157/+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 1296430] Re: Improve error message when attempting to delete a host agreggate that has hosts
** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) => Facundo Farias (facundo-farias) -- 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/1296430 Title: Improve error message when attempting to delete a host agreggate that has hosts Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Compute (Nova): In Progress Bug description: When you attempt to delete a host aggregate that has associated hosts you get a generic and confusing error message saying: Error: Unable to delete host aggregate: This error should be more specific and tell the user that the action cannot be completed unless the hosts are removed. Once you remove them all, the delete action can be completed without problems. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1296430/+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 1298131] [NEW] improper usage of HTTP 413 status code
Public bug reported:
HTTP 413 is supposed to mean (per RFC2616) that the request entity was
too large. E.g., if you send an enormous body with the request. That is
not at all how it is being used in the server resize request example
below. The nova/api/openstack/compute/servers.py is coded to return 413
for QuotaError and PortLimitExceeded on create as well as for QuotaError
on resize, and there may be other places 413 is being returned
inappropriately.
POST
https://9.5.126.113/powervc/openstack/compute/v2/6ce8fae0510349dcbf9b3965f7a20061/servers/8ebaabfc-9018-4ac1-afc6-630aee8a8ae3/action
Request body: { "resize": {
"flavor": {
"vcpus": 1,
"ram": 99,
"disk": 20
}}}
Response: HTTP 413 (Request Entity Too Large)
Response body:
{
overLimit: {
message: "NV-02B1F9F Quota exceeded for ram: Requested 1410063359, but already
used 6144 of 800 ram"
code: 413
retryAfter: "0"
}
-
}
** 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/1298131
Title:
improper usage of HTTP 413 status code
Status in OpenStack Compute (Nova):
New
Bug description:
HTTP 413 is supposed to mean (per RFC2616) that the request entity was
too large. E.g., if you send an enormous body with the request. That
is not at all how it is being used in the server resize request
example below. The nova/api/openstack/compute/servers.py is coded to
return 413 for QuotaError and PortLimitExceeded on create as well as
for QuotaError on resize, and there may be other places 413 is being
returned inappropriately.
POST
https://9.5.126.113/powervc/openstack/compute/v2/6ce8fae0510349dcbf9b3965f7a20061/servers/8ebaabfc-9018-4ac1-afc6-630aee8a8ae3/action
Request body: { "resize": {
"flavor": {
"vcpus": 1,
"ram": 99,
"disk": 20
}}}
Response: HTTP 413 (Request Entity Too Large)
Response body:
{
overLimit: {
message: "NV-02B1F9F Quota exceeded for ram: Requested 1410063359, but
already used 6144 of 800 ram"
code: 413
retryAfter: "0"
}
-
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298131/+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 1247603] Re: nova-conductor process can't create cosumer connection to qpid after HeartbeatTimeout in heavy workload
Hit this today on latest Havana build, logs below. I reproduced doing some stress testing; create 50 instances boot from volume in one operation. Need to try it in my Icehouse setup next. 2014-03-20 00:42:51.725 17580 INFO nova.compute.manager [req-ef61a326-288b-494d-9d30-f533e7739949 None None] Updating bandwidth usage cache 2014-03-20 00:43:51.843 17580 AUDIT nova.compute.resource_tracker [-] Auditing locally available compute resources 2014-03-20 00:43:52.607 17580 AUDIT nova.compute.resource_tracker [-] Free ram (MB): 257773 2014-03-20 00:43:52.607 17580 AUDIT nova.compute.resource_tracker [-] Free disk (GB): 49 2014-03-20 00:43:52.607 17580 AUDIT nova.compute.resource_tracker [-] Free VCPUS: 48 2014-03-20 00:43:52.677 17580 INFO nova.compute.resource_tracker [-] Compute_service record updated for os-1.solidfire.net:os-1.solidfire.net 2014-03-20 00:44:52.808 17580 AUDIT nova.compute.resource_tracker [-] Auditing locally available compute resources 2014-03-20 00:44:53.589 17580 AUDIT nova.compute.resource_tracker [-] Free ram (MB): 257773 2014-03-20 00:44:53.589 17580 AUDIT nova.compute.resource_tracker [-] Free disk (GB): 49 2014-03-20 00:44:53.590 17580 AUDIT nova.compute.resource_tracker [-] Free VCPUS: 48 2014-03-20 00:44:53.657 17580 INFO nova.compute.resource_tracker [-] Compute_service record updated for os-1.solidfire.net:os-1.solidfire.net 2014-03-20 08:47:05.277 17580 ERROR nova.openstack.common.rpc.impl_qpid [-] Failed to publish message to topic 'conductor': heartbeat timeout 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid Traceback (most recent call last): 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py", line 540, in ensure 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid return method(*args, **kwargs) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py", line 632, in _publisher_send 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid publisher = cls(self.conf, self.session, topic) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py", line 398, in __init__ 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid super(TopicPublisher, self).__init__(conf, session, node_name) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py", line 328, in __init__ 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid self.reconnect(session) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py", line 332, in reconnect 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid self.sender = session.sender(self.address) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "", line 6, in sender 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 592, in sender 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid sender._ewait(lambda: sender.linked) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 799, in _ewait 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid result = self.session._ewait(lambda: self.error or predicate(), timeout) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 566, in _ewait 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid result = self.connection._ewait(lambda: self.error or predicate(), timeout) 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 209, in _ewait 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid self.check_error() 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 202, in check_error 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid raise self.error 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid HeartbeatTimeout: heartbeat timeout 2014-03-20 08:47:05.277 17580 TRACE nova.openstack.common.rpc.impl_qpid 2014-03-20 08:47:05.295 17580 ERROR nova.openstack.common.rpc.impl_qpid [-] Failed to consume message from queue: heartbeat timeout 2014-03-20 08:47
[Yahoo-eng-team] [Bug 1298075] [NEW] Should translate Unauthorized NeutronClientException in allocate_for_instance
Public bug reported: If your auth token expires while allocating the network for an instance with the neutronv2 API in nova, you'll get a 500 from the server because the Unauthorized neutron client exception isn't handled and translated to a more specific NovaException (expecting a 401 in this case). Paste here: http://paste.openstack.org/show/74400/ We could decorate allocate_for_instance to catch Unauthorized and translate it to a more specific NovaException so the nova client gets a 401 instead of a 500. ** Affects: nova Importance: Undecided Status: New ** Tags: network -- 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/1298075 Title: Should translate Unauthorized NeutronClientException in allocate_for_instance Status in OpenStack Compute (Nova): New Bug description: If your auth token expires while allocating the network for an instance with the neutronv2 API in nova, you'll get a 500 from the server because the Unauthorized neutron client exception isn't handled and translated to a more specific NovaException (expecting a 401 in this case). Paste here: http://paste.openstack.org/show/74400/ We could decorate allocate_for_instance to catch Unauthorized and translate it to a more specific NovaException so the nova client gets a 401 instead of a 500. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298075/+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 1298074] [NEW] Horizon does not propagate logout_reason messages for ajax calls
Public bug reported: Horizon propagates logout_reason messages by setting a "logout_reason" cookie in the response. After the user is redirected to logout, the login view is rendered, and the logout_reason appears in the message portion of the login screen. In the case of the response to an ajax request, a redirect to logout results in the creation of a new HttpResponse in horizon.middleware.HorizonMiddleware.process_request() which is then returned to the requestor. The logout_reason cookie from the incoming response is not copied over. In this case, the logout_reason will be lost. ** Affects: horizon Importance: Undecided Assignee: David Lapsley (dlapsley) Status: In Progress -- 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/1298074 Title: Horizon does not propagate logout_reason messages for ajax calls Status in OpenStack Dashboard (Horizon): In Progress Bug description: Horizon propagates logout_reason messages by setting a "logout_reason" cookie in the response. After the user is redirected to logout, the login view is rendered, and the logout_reason appears in the message portion of the login screen. In the case of the response to an ajax request, a redirect to logout results in the creation of a new HttpResponse in horizon.middleware.HorizonMiddleware.process_request() which is then returned to the requestor. The logout_reason cookie from the incoming response is not copied over. In this case, the logout_reason will be lost. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1298074/+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 1298061] [NEW] nova should allow evacuate for an instance in the Error state
Public bug reported: We currently allow reboot/rebuild/rescue for an instance in the Error state if the instance has successfully booted at least once. We should allow "evacuate" as well, since it is essentially a "rebuild" on a different compute node. This would be useful in a number of cases, in particular if an initial evacuation attempt fails (putting the instance into the Error state). ** 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/1298061 Title: nova should allow evacuate for an instance in the Error state Status in OpenStack Compute (Nova): New Bug description: We currently allow reboot/rebuild/rescue for an instance in the Error state if the instance has successfully booted at least once. We should allow "evacuate" as well, since it is essentially a "rebuild" on a different compute node. This would be useful in a number of cases, in particular if an initial evacuation attempt fails (putting the instance into the Error state). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298061/+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 1298053] [NEW] Subnets should be set as lazy='join'
Public bug reported: Currently if one does a net-list tons of queries are issued against the database as the default query mode is 'select' which performs a query when the field is actually accessed. In this patch I change the the mode to 'joined' so subnets are loaded as the networks are loaded. Usually there are only 1 or 2 subnets on a network so loading this data shouldn't help. This patch in my setup with 5000 networks reduces the net-list call from 27 seconds to 7! ** Affects: neutron Importance: High Assignee: Aaron Rosen (arosen) Status: In Progress ** Tags: havana-backport-potential ** Changed in: neutron Assignee: (unassigned) => Aaron Rosen (arosen) ** Changed in: neutron Importance: Undecided => High ** Tags added: havana-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1298053 Title: Subnets should be set as lazy='join' Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently if one does a net-list tons of queries are issued against the database as the default query mode is 'select' which performs a query when the field is actually accessed. In this patch I change the the mode to 'joined' so subnets are loaded as the networks are loaded. Usually there are only 1 or 2 subnets on a network so loading this data shouldn't help. This patch in my setup with 5000 networks reduces the net-list call from 27 seconds to 7! To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1298053/+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 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection)
** 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/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1227321] Re: DBDuplicateEntry not being translated for DB2
** 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/1227321 Title: DBDuplicateEntry not being translated for DB2 Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): Triaged Status in OpenStack Compute (Nova): Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Bug description: The tempest.api.compute.keypairs.test_keypairs.test_create_keypair_with_duplicate_name test fails if you're running with a DB2 backend because the nova code is not currently translating the db integrity error if the backing engine is DB2 (ibm_db_sa) in nova.openstack.common.db.sqlalchemy.session._raise_if_duplicate_entry_error. Per full disclosure, nova is not claiming support for DB2 and there is a lot of work that would need to be done for that which my team is planning for icehouse and there is a blueprint here: https://blueprints.launchpad.net/nova/+spec/db2-database My team does have DB2 10.5 working with nova trunk but we have changes to the migration scripts to support that. Also, you have to run with the DB2 patch for sqlalchemy-migrate posted here: https://code.google.com/p/sqlalchemy-migrate/issues/detail?id=151 And you must run with the ibm-db/ibm-db-sa drivers: https://code.google.com/p/ibm-db/source/clones?repo=ibm-db-sa We're trying to get the sqlalchemy-migrate support for DB2 accepted in the icehouse timeframe but need to show the migrate maintainer that he can use the free express-c version of DB2 in ubuntu for the test backend. Anyway, having said all that, fixing the DBDuplicateEntry translation is part of the story so I'm opening a bug to track it and get the patch up to get the ball rolling. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1227321/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1247443] Re: tests leak file descriptors
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1247443 Title: tests leak file descriptors Status in OpenStack Identity (Keystone): Fix Released Bug description: By the end of a full test run the process with have over 300 sockets listening to various ports. While wasting resources is generally not good, this is particularly bad for new devs using Macs. The default number of file descriptor per process is 256 on a Mac. This situation is very hard to debug because unit tests will fail with errors about not being able to read configuration files. This is because once the process reaches it's limit of file descriptors it can no longer open files and Python will raise an IOError when it tries. oslo.config just catches all IOErrors and returns that generic message. There are no hints that the process has reached the fd limit. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1247443/+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 1266962] Re: Remove set_time_override in timeutils
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1266962 Title: Remove set_time_override in timeutils Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Ironic (Bare Metal Provisioning): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Manila: Fix Released Status in OpenStack Message Queuing Service (Marconi): Fix Released Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Status in Messaging API for OpenStack: Fix Released Status in Python client library for Keystone: Fix Released Status in Python client library for Nova: Fix Released Status in Tuskar: Fix Released Bug description: set_time_override was written as a helper function to mock utcnow in unittests. However we now use mock or fixture to mock our objects so set_time_override has become obsolete. We should first remove all usage of set_time_override from downstream projects before deleting it from oslo. List of attributes and functions to be removed from timeutils: * override_time * set_time_override() * clear_time_override() * advance_time_delta() * advance_time_seconds() To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1266962/+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 1296768] Re: keystone.tests.test_wsgi.ServerTest.test_keepalive_and_keepidle_set MismatchError: 1 != 2
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => icehouse-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/1296768
Title:
keystone.tests.test_wsgi.ServerTest.test_keepalive_and_keepidle_set
MismatchError: 1 != 2
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
The following test consistently fails in OS X:
==
FAIL: keystone.tests.test_wsgi.ServerTest.test_keepalive_and_keepidle_set
--
_StringException: pythonlogging:'': {{{
Adding cache-proxy 'keystone.tests.test_cache.CacheIsolatingProxy' to backend.
Starting /Users/dolph/Environments/os/bin/nosetests on 127.0.0.1:1234
}}}
Traceback (most recent call last):
File "/Users/dolph/Environments/os/lib/python2.7/site-packages/mock.py",
line 1201, in patched
return func(*args, **keywargs)
File "/Users/dolph/Projects/keystone/keystone/tests/test_wsgi.py", line
319, in test_keepalive_and_keepidle_set
self.assertEqual(mock_sock.setsockopt.call_count, 2)
File
"/Users/dolph/Environments/os/lib/python2.7/site-packages/testtools/testcase.py",
line 321, in assertEqual
self.assertThat(observed, matcher, message)
File
"/Users/dolph/Environments/os/lib/python2.7/site-packages/testtools/testcase.py",
line 406, in assertThat
raise mismatch_error
MismatchError: 1 != 2
According to keystone.common.environment.__init__, the expected
behavior varies for OS X:
# Optionally enable keepalive on the wsgi socket.
# This option isn't available in the OS X version of eventlet
But the test is written without the same flexibility. To demonstrate
on OS X:
$ python --version
Python 2.7.6
$ uname
Darwin
$ python -c "import socket; print(socket.TCP_KEEPIDLE)"
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'TCP_KEEPIDLE'
$ python -c "import eventlet; eventlet.patcher.monkey_patch(socket=True);
import socket; print(socket.TCP_KEEPIDLE)"
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'TCP_KEEPIDLE'
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1296768/+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 1283872] Re: webob.exc.HTTPForbidden can't show correct message
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => icehouse-rc1
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1283872
Title:
webob.exc.HTTPForbidden can't show correct message
Status in Cinder:
Fix Released
Status in OpenStack Identity (Keystone):
Fix Released
Status in OpenStack Neutron (virtual network service):
Fix Released
Status in OpenStack Compute (Nova):
Fix Released
Bug description:
In nova/api/ec2/__init__.py there are codes like:
154 def __call__(self, req):
155 access_key = str(req.params['AWSAccessKeyId'])
156 failures_key = "authfailures-%s" % access_key
157 failures = int(self.mc.get(failures_key) or 0)
158 if failures >= CONF.lockout_attempts:
159 detail = _("Too many failed authentications.")
160 raise webob.exc.HTTPForbidden(detail=detail)
But webob.exc.HTTPForbidden should use the 'explanation' parameter to
show the error message.
The source can be referred to
https://github.com/Pylons/webob/blob/master/webob/exc.py#L666
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1283872/+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 1294393] Re: FederatedTokenTests.scope_to_bad_project test is disabled due to its naming
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1294393 Title: FederatedTokenTests.scope_to_bad_project test is disabled due to its naming Status in OpenStack Identity (Keystone): Fix Released Bug description: method test_v3_federation.FederatedTokenTests.scope_to_bad_project() should be renamed to test_scope_to_bad_project in order to be called when testsuite is executed. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1294393/+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 1296862] Re: Keystone doc build fails when built from sdist tarballs
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1296862 Title: Keystone doc build fails when built from sdist tarballs Status in OpenStack Identity (Keystone): Fix Released Bug description: keystone/tests/tmp is not included in the sdist tarballs, hence running sphinx fails with: [ 27s] File "/home/abuild/rpmbuild/BUILD/keystone-2014.1.dev141.g0fb0dfd/keystone/tests/core.py", line 92, in [ 27s] os.mkdir(TMPDIR) [ 27s] OSError: [Errno 2] No such file or directory: '/home/abuild/rpmbuild/BUILD/keystone-2014.1.dev141.g0fb0dfd/keystone/tests/tmp/29703' thats because the parent dir (tests/tmp) is missing. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1296862/+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 1263804] Re: EC2 token creation no longer possible for admin
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1263804 Title: EC2 token creation no longer possible for admin Status in OpenStack Identity (Keystone): Fix Released Bug description: with the security fix for "[OSSA 2013-032] Keystone trust circumvention through EC2-style tokens (CVE-2013-6391)", Bug #1242597, it is no longer possible to create ec2 credentials with just admin service token + service endpoint. Log file gives: 2013-12-23 22:13:12.197 22611 WARNING keystone.common.wsgi [-] Authorization failed. Could not find token, 120726431688. from 192.168.226.81 where 120... is the admin token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1263804/+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 1294781] Re: user_id missing from message about federation roles
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1294781 Title: user_id missing from message about federation roles Status in OpenStack Identity (Keystone): Fix Released Bug description: In the token common provider, the call to _populate_roles_for_groups() is missing the user_id argument, and it is defaulted to None. Thus, whenever a user is associated with a group that has no roles on either scoped project or domain, then the error message will always be: 'User None has no access to project %(project_id)s' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1294781/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1296333] Re: Keystone docs fail to build with SQLAlchemy 0.9
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1296333 Title: Keystone docs fail to build with SQLAlchemy 0.9 Status in OpenStack Identity (Keystone): Fix Released Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: When using SQLAlchemy 0.9, the docs fail to build. This is preventing Keystone from moving up to SQLAlchemy 0.9. There's a commit to update keystone's requirements to SQLAlchemy 0.9 which is failing the docs build: https://review.openstack.org/#/c/82231/ The log there only shows the first failure. When I generate docs on my build system I get the following errors: sphinx.errors.SphinxWarning: /opt/stack/keystone/keystone/common/sql/__init__.py:docstring of keystone.common.sql.relationship:53: ERROR: Unknown interpreted text role "paramref". sphinx.errors.SphinxWarning: /opt/stack/keystone/keystone/openstack/common/db/sqlalchemy/utils.py: docstring of keystone.openstack.common.db.sqlalchemy.utils.or_:26: WARNING: more than one target found for cross-reference u'and_': keystone.common.sql.core.and_, keystone.common.sql.and_ sphinx.errors.SphinxWarning: /opt/stack/keystone/keystone/openstack/common/db/sqlalchemy/utils.py: docstring of keystone.openstack.common.db.sqlalchemy.utils.select:12: WARNING: undefined label: coretutorial_selecting (if the link has no caption the label must precede a section header) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1296333/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1288124] Re: Update docstrings in auth/tokens/plugins/saml2.py and contrib/federation/routers.py
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1288124 Title: Update docstrings in auth/tokens/plugins/saml2.py and contrib/federation/routers.py Status in OpenStack Identity (Keystone): Fix Released Bug description: Files keystone/auth/tokens/plugins/saml2.py and keystone/contrib/federation/routers.py have outdated docstrings. They should be fixed to match the current code. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1288124/+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 1284422] Re: v3 endpoint create should require url
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => icehouse-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/1284422
Title:
v3 endpoint create should require url
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
When create a endpoint, if I do not specify "service_id" I will get the
following reponse:
curl -i -H "X-Auth-Token:admin" -H "Content-Type:application/json"
http://127.0.0.1:35357/v3/endpoints -d '{"endpoint":{"interface":"test"}}'
{"error": {"message": "service_id field is required and cannot be
empty", "code": 400, "title": "Bad Request"}}openstack@openstack-HP-
Compaq-8100-Elite-CMT-PC:~/devstack$
But, if I do not specify "url" I will get another reponse as following:
curl -i -H "X-Auth-Token:admin" -H "Content-Type:application/json"
http://127.0.0.1:35357/v3/endpoints -d
'{"endpoint":{"interface":"test","service_id":"d893b85ae4f842d5bb1727e271cf5be3"}}'
{"error": {"message": "An unexpected error prevented the server from
fulfilling your request. (OperationalError) (1048, \"Column 'url'
cannot be null\") 'INSERT INTO endpoint (id, legacy_endpoint_id,
interface, region, service_id, url, extra) VALUES (%s, %s, %s, %s, %s,
%s, %s)' ('57b1f66ed22f45c3ba43812d7eabac69', None, 'test', None,
'd893b85ae4f842d5bb1727e271cf5be3', None, '{}')", "code": 500,
"title": "Internal Server Error"}}
The url parameter should be required too.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1284422/+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 1291705] Re: Oauth manager created multiple times
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => icehouse-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/1291705
Title:
Oauth manager created multiple times
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
The oauth1.Manager class, which is @dependency.provider('oauth_api'),
is created multiple times when it should only be created once. A
'provider' should only be created once because otherwise the new
instance replaces the one that's stored in the dependency map.
Luckily, the oauth1.Manager doesn't store any state so it's safe to do
in this case, but it makes for a bad example that others are copying
and it might not be safe in those cases.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1291705/+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 1287637] Re: remove hardcoded SQL queries in tests
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1287637 Title: remove hardcoded SQL queries in tests Status in OpenStack Identity (Keystone): Fix Released Bug description: There are several occurrences of hardcoded SQL queries at least in test_sql_upgrade.py: * https://github.com/openstack/keystone/blob/master/keystone/tests/test_sql_upgrade.py#L941 * https://github.com/openstack/keystone/blob/master/keystone/tests/test_sql_upgrade.py#L946 Due to variations in databases these queries might not work all the time, and should be replaced by queries built with sqlalchemy. A code sweep is in order to find and replace any hardcoded queries. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1287637/+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 1195813] Re: All v3 XML responses use v2 namespace. Should use v3 namespace as v2 and v3 are incompatible
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1195813 Title: All v3 XML responses use v2 namespace. Should use v3 namespace as v2 and v3 are incompatible Status in OpenStack Identity (Keystone): Fix Released Bug description: All v3 xml reponse have the same problem eg. Get domains. http://docs.openstack.org/identity/api/v2.0";> http://localhost:5000/v3/domains/5345345345345"/> To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1195813/+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 1255518] Re: name '_' is not defined, under nosetests.
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => icehouse-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/1255518
Title:
name '_' is not defined, under nosetests.
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
When I start keystone unit tests under `nosetests` it is falls with an
error:
NameError: name '_' is not defined
Due to deprecating implicit `_` import, explicit `_` become necessary
. But obvious it is done not everywhere.
(git::master)nosetests -xs
E
==
ERROR: Failure: NameError (name '_' is not defined)
--
Traceback (most recent call last):
File
"/home/ipekelny/workspace/keystone/.tox/py26/lib/python2.6/site-packages/nose/loader.py",
line 413, in loadTestsFromName
addr.filename, addr.module)
File
"/home/ipekelny/workspace/keystone/.tox/py26/lib/python2.6/site-packages/nose/importer.py",
line 47, in importFromPath
return self.importFromDir(dir_path, fqname)
File
"/home/ipekelny/workspace/keystone/.tox/py26/lib/python2.6/site-packages/nose/importer.py",
line 94, in importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File "/home/ipekelny/workspace/keystone/keystone/assignment/__init__.py",
line 18, in
from keystone.assignment.core import *
File "/home/ipekelny/workspace/keystone/keystone/assignment/core.py", line
23, in
from keystone import clean
File "/home/ipekelny/workspace/keystone/keystone/clean.py", line 17, in
from keystone import exception
File "/home/ipekelny/workspace/keystone/keystone/exception.py", line 63, in
class ValidationError(Error):
File "/home/ipekelny/workspace/keystone/keystone/exception.py", line 64, in
ValidationError
message_format = _("Expecting to find %(attribute)s in %(target)s."
NameError: name '_' is not defined
>> begin captured logging <<
keystone.common.environment: INFO: Environment configured as: eventlet
- >> end captured logging << -
--
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1255518/+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 1243392] Re: Can't run live system tests using testr
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1243392 Title: Can't run live system tests using testr Status in OpenStack Identity (Keystone): Fix Released Bug description: The move to testr has broken the ability to run the live system tests. Prior to testr they were run either directly by nose or through run_tests.sh. It seems that testr doesn't like the file names likely because the begin with an _. To fix this I'd like to create a new location for system tests so that they can excluded from the default test run, but can be run by hand. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1243392/+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 1233365] Re: LDAP backend fails when connecting to Active Directory root DN
** 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/1233365
Title:
LDAP backend fails when connecting to Active Directory root DN
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
When using the LDAP backend and connecting to Active Directory, trying
to use the root DN (dc=example,dc=com) as the user_tree_dn (or
tenant/role_tree_dn) fails with "Authorization Failed: Unable to
communicate with identity service: {"error": {"message": "An
unexpected error prevented the server from fulfilling your request.
{'info': '04DC: LdapErr: DSID-0C0906E8, comment: In order to
perform this operation a successful bind must be completed on the
connection., data 0, v1db1', 'desc': 'Operations error'}", "code":
500, "title": "Internal Server Error"}}. (HTTP 500)".
This is because python-ldap chases all referrals with anonymous
access, which is disabled by default in AD for security reasons.
Adding a line in core.py under ldap.initialize to not chase referrals
(self.conn.set_option(ldap.OPT_REFERRALS, 0)) gets around this error,
but then we get "AttributeError: 'list' object has no attribute
'iteritems'" in search_s. This is because while the referrals aren't
chased, they still show up in the results list. The keystone code
can't seem to handle the format the referrals come in. I was able to
work around this by adding an if statement before o.append to ignore
the referral results (if type(dn) is not NoneType). I also added "from
types import *" in the beginning of core.py.
I'm sure this isn't the best workaround for everybody, but in general
I think there should be an option in keystone.conf to enable or
disable chasing of referrals. If it is disabled, then the previous
ldap option should be set and something should be done to remove the
referrals from the results list.
Edit: I'm using the Grizzly packages from the Ubuntu Cloud Archive on
Ubuntu 12.04.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1233365/+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 1297309] Re: Unauthorized: Unknown auth strategy
Not seeing this in nova logs anymore, all logstash hits are for neutron
in last 7 days.
** Changed in: nova
Status: New => Incomplete
** No longer affects: nova
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1297309
Title:
Unauthorized: Unknown auth strategy
Status in OpenStack Neutron (virtual network service):
New
Status in Python client library for Neutron:
Fix Committed
Bug description:
I have seen this error occasionally in various (Nova) logs:
2014-03-25 10:42:58.182 31770 TRACE nova.api.openstack raise
exceptions.Unauthorized(message=_('Unknown auth strategy'))
2014-03-25 10:42:58.182 31770 TRACE nova.api.openstack Unauthorized: Unknown
auth strategy
Full stacktrace can be found with this logstash query:
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVW5hdXRob3JpemVkOiBVbmtub3duIGF1dGggc3RyYXRlZ3lcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiODY0MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxMzk1NzU2MzQxNTc3fQ==
As a first step, it would be nice for neutronclient to say what auth
strategy it is unable to handle.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1297309/+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 1240052] Re: Hardcoded paths prevent tests from being parallelized
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1240052 Title: Hardcoded paths prevent tests from being parallelized Status in OpenStack Identity (Keystone): Fix Released Bug description: The Keystone tests create config files and database files on the fly during the course for a test run. The paths are static and not using tempfile. This means that the tests cannot be run in parallel. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240052/+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 1214064] Re: Trust creation allowed with empty roles list
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1214064 Title: Trust creation allowed with empty roles list Status in OpenStack Identity (Keystone): Fix Released Bug description: The docs state ""A project_id may not be specified without at least one role, and vice versa.", however /OS-TRUST/trusts *does* allow you to create a trust with an empty roles list and project_id specified. This results in 401 responses whenever you try to consume the trust, which is not exactly obvious until you realize what's happening.. It seems odd to allow creation of a trust which is seemingly useless and can never be consumed, so I guess either the code or the docs need updating? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1214064/+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 1282266] Re: enabled attribute missing from GET /v3/endpoints
** 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/1282266
Title:
enabled attribute missing from GET /v3/endpoints
Status in OpenStack Identity (Keystone):
Fix Released
Status in Tempest:
Fix Released
Bug description:
response from current master:
RESP BODY: {"endpoints": [{"links": {"self":
"http://localhost:5000/v3/endpoints/7237fc3ba1ec460595e8de463a5c7132"},
"url": "http://localhost:35357/v3";, "region": "regionOne",
"interface": "admin", "service_id":
"0c8a9efdeada49d689c4d3ef29ecb3d7", "id":
"7237fc3ba1ec460595e8de463a5c7132"}], "links": {"self":
"http://localhost:5000/v3/endpoints";, "previous": null, "next": null}}
response from stable/havana (this is correct):
RESP BODY: {"endpoints": [{"links": {"self":
"http://localhost:5000/v3/endpoints/6e1b54c3423347f1bafb20030dabb412"},
"url": "http://127.0.0.1:35357/";, "region": null, "enabled": true,
"interface": "admin", "service_id":
"f43f1d5cb2e04edda9316077421062c8", "id":
"6e1b54c3423347f1bafb20030dabb412"}], "links": {"self":
"http://localhost:5000/v3/endpoints";, "previous": null, "next": null}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1282266/+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 1269739] Re: an improvement of curl example doc?
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: keystone
Milestone: None => icehouse-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/1269739
Title:
an improvement of curl example doc?
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
In keystone curl example document, it uses "curl -d
'{"auth":{"passwordCredentials":{"username": "joeuser", "password":
"secrete"}}}' -H "Content-type: application/json"
http://localhost:35357/v2.0/tokens"; to get a token, and in next
example, it uses a token to access other service.
Actually without a tenantName in curl body of the first example, the
token we get could be used to access other service directly. I think
in this example, we could add tenantName in it. It is more meaningful
in whole context.
[0] http://docs.openstack.org/developer/keystone/api_curl_examples.html#id3
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1269739/+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 1271706] Re: Misleading warning about MySQL TRADITIONAL mode not being set
** 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/1271706 Title: Misleading warning about MySQL TRADITIONAL mode not being set Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Compute (Nova): New Status in Oslo - a Library of Common OpenStack Code: Fix Released Bug description: common.db.sqlalchemy.session logs a scary warning if create_engine is not being called with mysql_traditional_mode set to True: WARNING keystone.openstack.common.db.sqlalchemy.session [-] This application has not enabled MySQL traditional mode, which means silent data corruption may occur. Please encourage the application developers to enable this mode. That warning is problematic for several reasons: (1) It suggests the wrong mode. Arguably TRADITIONAL is better than the default, but STRICT_ALL_TABLES would actually be more useful. (2) The user has no way to fix the warning. (3) The warning does not take into account that a global sql-mode may in fact have been set via the server-side MySQL configuration, in which case the session *may* in fact be using TRADITIONAL mode all along, despite the warning saying otherwise. This makes (2) even worse. My suggested approach would be: - Remove the warning. - Make the SQL mode a config option. Patches forthcoming. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1271706/+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 1273867] Re: Keystone API v3 lists disabled endpoints and services in catalog
** 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/1273867
Title:
Keystone API v3 lists disabled endpoints and services in catalog
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
When endpoint or service has "enabled" attribute set to "False", it is
still listed in catalog (`keystone catalog` command and/or in catalog
part of token.
Create testing service (simplifies output later):
> localhost:5000
> POST /v3/services
> '{"service":{"name":"My svc","type":"testing"}}'
response:
> {'service': {'id': '',
> 'links': {'self':
'http://localhost:5000/v3/services/'},
> 'name': 'My svc',
> 'type': 'testing'}}
Create disabled endpoint:
> localhost:5000
> POST /v3/endpoints
> '{"endpoint":{
>"enabled":false,
>"name":"My disabled",
>"interface":"public",
>"url":"disabled_URL",
>"service_id":""}}'
response:
> {'endpoint': {'enabled': False,
> 'id': '',
> 'interface': 'public',
> 'links': {'self':
'http://localhost:5000/v3/endpoints/'},
> 'name': 'My disabled',
> 'region': None,
> 'service_id': '',
> 'url': 'disabled_URL'}}
Now request token and see that it's catalog/endpoints part contains:
> localhost:5000
> POST /v3/auth/tokens
> '{"auth":{
> "identity":
>{"methods":["password"],
> "password":{
> "user":{"name":"admin","domain":{"id":"default"},"password":"pass"}}},
> "scope":{"project":{"name":"admin","domain":{"id":"default"}
snippet of response:
> {'token': {'catalog': [
> ...
> {'endpoints': [{'enabled': False,
> 'id': '',
> 'interface': 'public',
> 'legacy_endpoint_id': None,
> 'name': 'My disabled',
> 'region': None,
> 'url': 'disabled_URL'}],
>'id': '',
>'type': 'testing'},
> ...
Also it gets listed in response of `keystone catalog` (API v2):
> # keystone catalog --service testing
> Service: testing
> +---+--+
> | Property | Value |
> +---+--+
> | id| |
> | publicURL |disabled_URL |
> | region | |
> +---+--+
The same example applies to Service with enabled=false.
See https://github.com/openstack/identity-api/blob/master/openstack-
identity-api/src/markdown/identity-api-v3.md#endpoints-v3endpoints for
description of enabled attribute for Endpoint.
And https://github.com/openstack/identity-api/blob/master/openstack-
identity-api/src/markdown/identity-api-v3.md#services-v3services for
description of Service.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1273867/+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 1279492] Re: oauth consumers links missing OS-OAUTH1
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1279492 Title: oauth consumers links missing OS-OAUTH1 Status in OpenStack Identity (Keystone): Fix Released Bug description: I noticed that the consumers controller for OS-OAUTH1 extension does not over-ride the base_url function. As a result, the links section of the result provides an invalid link. It is missing the OS-OAUTH1 portion of the URL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279492/+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 1275145] Re: can't create credential with keystone.conf admin_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/1275145 Title: can't create credential with keystone.conf admin_token Status in OpenStack Identity (Keystone): Fix Released Bug description: 2014-01-31 15:42:14.656 2631 WARNING keystone.common.wsgi [-] Invalid token in _get_trust_id_for_request 2014-01-31 15:42:14.657 2631 WARNING keystone.common.wsgi [-] Authorization failed. The request you have made requires authentication. from 127.0.0.1 Reason is we are doing trust lookup on credential creation and that requires a token. See https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L300 This won't work with the ADMIN token or customize SSL authorization. btw, there shouldn't be an explicit linkage of credential with trust. Trust should be part of auth scope, not the credential itself. This is like linking user password to a trust. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1275145/+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 1291047] Re: Keystone returns traceback for db 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/1291047 Title: Keystone returns traceback for db backend Status in OpenStack Identity (Keystone): Fix Released Bug description: Regression as noted here https://bugs.launchpad.net/keystone/+bug/1039552 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291047/+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 1288009] Re: Default discovery endpoints create an unusable service
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1288009 Title: Default discovery endpoints create an unusable service Status in OpenStack Identity (Keystone): Fix Released Bug description: If a configurer fails to set a public_endpoint or admin_endpoint in the keystone.conf file then it defaults to http://localhost:%(port)d this is a relatively common thing to forget as no-one has been doing much version discovery - or at least not following the links once done. This is a dumb default as for almost all situations the endpoint is wrong. It also has the problem that regardless of whether you arrived at the page via the 'public' endpoint or the 'private' endpoint you will see the same path to consume the service so using the admin URL was essentially useless. A recently written proposal (mine): https://wiki.openstack.org/wiki/VersionDiscovery advocates that discovery services should make this URL relative to stop this confusion however that is unlikely to be acceptable for existing clients. Thus at the very least we should change the default value to be relative to the URL with which the user accessed the site as it will always be available from this same source. (or configurable away) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1288009/+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 1290966] Re: missing auth method configuration in oauth1 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/1290966 Title: missing auth method configuration in oauth1 documentation Status in OpenStack Identity (Keystone): Fix Released Bug description: The oauth1 configuration page (http://docs.openstack.org/developer/keystone/extensions/oauth1-configuration.html) in the documentation should also mention that "oauth1" must be added as a default auth method To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1290966/+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 1291393] Re: domain_id in User/Group/Project should be immutable
** 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/1291393
Title:
domain_id in User/Group/Project should be immutable
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
Today we allow the domain_id in User, Group and Project entities to be
updated….effectively moving the entity between domains. With today's
policy capability this represents a potential security hole if you are
trying to enforce strict domain admin type of roles. We should allow
a cloud provider to disable this current update ability…and make the
domain_id attribute immutable in the same way we do for the id of the
entity.
Here's a recipe for how to create this potential security hole using the v3
policy sample file:
- Have a user with role 'admin' on the domain_A (this makes them a "domain
admin")
- They try and update their user entity (or any other user entity) with
{'domain_id': domain_B}. This will succeed, even though the goal of the v3
policy sample file is to restrict the access for such a user is to only objects
domain_A
- The user is now part of domain_B
- The above does not actually yet give the user ability to authenticate to
domain_B (since they do not have a role on that domain)…but it perhaps lays the
ground work for some other attack to enable that
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1291393/+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 1280965] Re: LDAP dumb user is not filtered when listing role assignments
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1280965 Title: LDAP dumb user is not filtered when listing role assignments Status in OpenStack Identity (Keystone): Fix Released Bug description: When the LDAP assignment driver is used and the "use_dumb_member" configuration option is enabled, the dumb member is listed when listing the role assignments. This can be seen by running the live LDAP tests, as the "test_list_role_assignments_unfiltered" test will fail due to the additional role assignments for the dumb member. We should be filtering out the dumb member in RoleApi.list_role_assignments(), as we already do inRoleApi. get_role_assignments(). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1280965/+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 1290258] Re: Group ids are not validated after SAML2->groups mapping and federated token scoping
** 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/1290258 Title: Group ids are not validated after SAML2->groups mapping and federated token scoping Status in OpenStack Identity (Keystone): Fix Released Bug description: During federated authentication dedicated mechanism called RuleProcessor maps SAML2 parameters into Keystone groups. It's done by matching certain rules added by cloud administrators. However, Keystone doesn't check whether resulting groups are present in the backend. this may lead to errors "mapping doesn't work as expected" due to a typo in the rule, or situations where group was deleted and admins are not aware of that fact. The fix should include a function that checks whether all the groups are present in the backend and if not log a warning and remove nonexisting groups from the list. The same policy should be applied when scoping federated unsoped token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1290258/+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 1284341] Re: keystone-manage db_version broken
** 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/1284341 Title: keystone-manage db_version broken Status in OpenStack Identity (Keystone): Fix Released Bug description: A recent commit appears to have broken keystone-manage: keystone-manage db_version 2014-02-24 21:29:17.392 CRITICAL keystone [-] TypeError: db_version() takes exactly 2 arguments (1 given) It appears to be a regression caused by this patch which was recently merged: https://review.openstack.org/#/c/61073/36/keystone/cli.py The ")"'s on the print statements look to be in the wrong place AFAICS. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1284341/+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 1287219] Re: scope of domain admin too broad in v3 policy sample
** 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/1287219
Title:
scope of domain admin too broad in v3 policy sample
Status in OpenStack Identity (Keystone):
Fix Released
Status in OpenStack Security Advisories:
Won't Fix
Status in OpenStack Security Notes:
New
Bug description:
Using the policies in the new default policy.v3cloudsample.json file,
a domain admin can easily elevate himself and become the cloud admin:
1) Get a token of a domain admin (a user with 'admin' role on any domain
other that the default domain which is the cloud admin's domain)
2) Grant yourself the admin role on the default domain which is the domain of
the cloud admin (PUT
/v3/domains/default/user//roles/
3) Change your domain_id to the id of the default domain (PATCH
/v3/users/ -d '"{user": {"domain_id": "default"}}'
4) Get a new token scoped to the default domain
==> You are now the cloud admin
It is expected that step number 2 should fail. Admins should be able
to grant roles only on their domain and their projects, not on other
projects. Otherwise, it is as if they are not really scoped at all.
NOTE: I am using the default policy.v3cloudsample.json file as is, unchanged.
I only defined the domain of the cloud admins to be the default domain by
editing this rule:
"cloud_admin": "rule:admin_required and domain_id:default",
I think that the default policy file should be changed to prevent
administrators' ability to grant roles on objects of foreign domains
(with the exception of admins in the domain defined by the cloud_admin
rule, of course).
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1287219/+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 1291423] Re: revocation events sync slows responses to all authenticated calls
** 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/1291423 Title: revocation events sync slows responses to all authenticated calls Status in OpenStack Identity (Keystone): Fix Released Bug description: There is a noticable lag when doing multiple calls to Keystone. The server shows in the log: KVS lock acquired for: os-revoke-events acquire /opt/stack/keystone/keystone/common/kvs/core.py:375 Putting the following delay in mitigates it significantly delta = datetime.timedelta(seconds=1) if self._last_fetch and self._last_fetch > timeutils.utcnow() + delta: return To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1291423/+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 1285871] Re: Attempt to call strftime on a str fails revocation_list
** 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/1285871 Title: Attempt to call strftime on a str fails revocation_list Status in OpenStack Identity (Keystone): Fix Released Bug description: This causes heat authenticated operations to fail for me locally 2014-02-28 10:25:10.084 ERROR keystone.common.wsgi [-] 'str' object has no attribute 'strftime' 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi Traceback (most recent call last): 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File "/home/steveb/dev/localstack/keystone/keystone/common/wsgi.py", line 211, in __call__ 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi result = method(context, **params) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File "/home/steveb/dev/localstack/keystone/keystone/openstack/common/versionutils.py", line 102, in wrapped 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi return func(*args, **kwargs) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File "/home/steveb/dev/localstack/keystone/keystone/common/controller.py", line 131, in inner 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi return f(self, context, *args, **kwargs) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File "/home/steveb/dev/localstack/keystone/keystone/token/controllers.py", line 423, in revocation_list 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi t['expires'] = timeutils.isotime(expires) 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi File "/home/steveb/dev/localstack/keystone/keystone/openstack/common/timeutils.py", line 38, in isotime 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi st = at.strftime(_ISO8601_TIME_FORMAT 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi AttributeError: 'str' object has no attribute 'strftime' 2014-02-28 10:25:10.084 TRACE keystone.common.wsgi Possibly the six.text_type check should be six.string_types, but actually that conditional should really be checking for isinstance datetime.datetime explicitly, since that is what timeutils.isotime is assuming. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1285871/+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 1284972] Re: Creating a region using V3 api fails in backend code when missing description
** 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/1284972 Title: Creating a region using V3 api fails in backend code when missing description Status in OpenStack Identity (Keystone): Fix Released Bug description: When creating a region using the V3 API, the request fails out in the backend code. This check should be handled in the controller/manager like it does for other resources (federation does this - https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L43-L44) We could use the same functionality provided in https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L607 to fix this: http://paste.openstack.org/show/69690/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1284972/+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 1290582] Re: missing auth method configuration in federation 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/1290582 Title: missing auth method configuration in federation documentation Status in OpenStack Identity (Keystone): Fix Released Bug description: The federation configuration page in the documentation should also mention that "saml2" must be added as a default auth method. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1290582/+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 1291981] Re: missing type check in SAML RuleProcessor
** 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/1291981
Title:
missing type check in SAML RuleProcessor
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
RuleProcessor assumes every element in context['environment'] can be
splitted as a string as seen here:
https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/utils.py#L172
This is however not always the case:
curl -si -d '{
"auth": {
"identity": {
"methods": [
"saml2"
],
"saml2": {
"identity_provider": "testshib",
"protocol": "admin"
}
}
}' -H "Content-type: application/json" http://XXX:5000/v3/auth/tokens
2014-03-10 23:21:34.869 DEBUG keystone.middleware.core [-] Auth token not in
the request header. Will not build auth contex
t. from (pid=7939) process_request
/opt/stack/keystone/keystone/middleware/core.py:270
2014-03-10 23:21:34.871 DEBUG keystone.common.wsgi [-] arg_dict: {} from
(pid=7939) __call__ /opt/stack/keystone/keystone/common/wsgi.py:180
2014-03-10 23:21:34.877 ERROR keystone.common.wsgi [-] 'Route' object has no
attribute 'split'
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi Traceback (most recent
call last):
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/common/wsgi.py", line 205, in __call__
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi result =
method(context, **params)
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/auth/controllers.py", line 316, in
authenticate_for_token
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi
self.authenticate(context, auth_info, auth_context)
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/auth/controllers.py", line 416, in authenticate
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi auth_context)
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/auth/plugins/saml2.py", line 54, in authenticate
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi fields =
self._handle_unscoped_token(context, auth_payload)
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/auth/plugins/saml2.py", line 77, in
_handle_unscoped_token
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi mapped_properties =
rule_processor.process(assertion)
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/contrib/federation/utils.py", line 172, in process
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi assertion = dict((n,
v.split(';')) for n, v in assertion_data.items())
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/contrib/federation/utils.py", line 172, in
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi assertion = dict((n,
v.split(';')) for n, v in assertion_data.items())
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi AttributeError: 'Route'
object has no attribute 'split'
2014-03-10 23:21:34.877 TRACE keystone.common.wsgi
2014-03-10 23:21:34.881 INFO eventlet.wsgi.server [-] 84.99.59.174 - -
[10/Mar/2014 23:21:34] "POST /v3/auth/tokens HTTP/1.1" 500 331 0.012142
-
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1291981/+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 1297059] Re: Migrate 43 fails on old sqlalchemy
** 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/1297059 Title: Migrate 43 fails on old sqlalchemy Status in OpenStack Identity (Keystone): Fix Released Bug description: When using sqlalchemy 0.7.10 running migration 043_fixup_region_description.py fails with the error: Traceback (most recent call last): File "keystone/tests/test_sql_upgrade.py", line 2546, in test_upgrade_region_unique_description self.upgrade(43) File "keystone/tests/test_sql_upgrade.py", line 139, in upgrade self._migrate(*args, **kwargs) File "keystone/tests/test_sql_upgrade.py", line 156, in _migrate self.schema.runchange(ver, change, changeset.step) File "/home/jamie/.virtualenvs/keystone2/lib/python2.7/site-packages/migrate/versioning/schema.py", line 91, in runchange change.run(self.engine, step) File "/home/jamie/.virtualenvs/keystone2/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 145, in run script_func(engine) File "/home/jamie/work/keystone/keystone/common/sql/migrate_repo/versions/043_fixup_region_description.py", line 78, in upgrade region_table = sql.Table(_REGION_TABLE_NAME, meta, autoload=True) File "/home/jamie/.virtualenvs/keystone2/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 106, in __getattr__ raise AttributeError(key) AttributeError: values Upgrading to sqlalchemy 0.8.5 fixes the error, however our requirements.txt file lists: SQLAlchemy>=0.7.8,<=0.8.99 so this should still be valid. I can't quite tell when the values() function was added, i assume it was 0.8 but i'm not familiar with the migration to know exactly what is being accomplished there. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1297059/+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 1297922] Re: Internationalization is broken when using httpd/keystone.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/1297922 Title: Internationalization is broken when using httpd/keystone.py Status in OpenStack Identity (Keystone): Fix Released Bug description: This was first mentioned on IRC last night: "gyee | yes, running under apache yield a bunch warnings related to _()". I still need more detail on this exception. I setup a devstack to test and noticed that we are not setting things up to be lazily translated. This means that all messages will be translated to the default locale. If messages are translated lazily the messages being returned to users would be translated based on the language specified in the HTTP headers. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1297922/+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 1296348] Re: /v3/auth/tokens cannot be used for issuing unscoped tokens during federated authn
** 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/1296348 Title: /v3/auth/tokens cannot be used for issuing unscoped tokens during federated authn Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack API documentation site: Fix Released Bug description: URL /v3/auth/tokens cannot be used when issuing unscoped federated tokens, as such URL must be configured as protected in the mod_shib configuration. Thus, a dedicated URL must be able to run federated authentication. Also, as usually during federated authentication initial data used by the client is lost (due to many HTTP redirections between SP and IdP) it's advised for clients to access URL with IdP and protocol specified in the URL. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1296348/+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 1294150] Re: Keystone fails when returning unscoped federated token as XML
** 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/1294150 Title: Keystone fails when returning unscoped federated token as XML Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack API documentation site: Fix Released Bug description: Keystone fails when unscoped token is serialized to the XML output. 'OS-FEDERATION:groups' tag is invalid. Traceback: ERROR keystone.middleware.core Serializer failed TRACE keystone.middleware.core Traceback (most recent call last): TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/middleware/core.py", line 167, in process_response TRACE keystone.middleware.core response.body = serializer.to_xml(body_obj) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 67, in to_xml TRACE keystone.middleware.core return serialize(d, xmlns) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 218, in __call__ TRACE keystone.middleware.core self.populate_element(root, d[name]) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 323, in populate_element TRACE keystone.middleware.core self._populate_tree(element, value) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 357, in _populate_tree TRACE keystone.middleware.core self._populate_dict(element, k, v) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 294, in _populate_dict TRACE keystone.middleware.core self.populate_element(child, v) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 323, in populate_element TRACE keystone.middleware.core self._populate_tree(element, value) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 359, in _populate_tree TRACE keystone.middleware.core self._populate_list(element, k, v) TRACE keystone.middleware.core File "/opt/stack/keystone/keystone/common/serializer.py", line 272, in _populate_list TRACE keystone.middleware.core container = etree.Element(k) TRACE keystone.middleware.core File "lxml.etree.pyx", line 2811, in lxml.etree.Element (src/lxml/lxml.etree.c:65352) TRACE keystone.middleware.core File "apihelpers.pxi", line 103, in lxml.etree._makeElement (src/lxml/lxml.etree.c:13888) TRACE keystone.middleware.core File "apihelpers.pxi", line 1575, in lxml.etree._tagValidOrRaise (src/lxml/lxml.etree.c:27942) TRACE keystone.middleware.core ValueError: Invalid tag name u'OS-FEDERATION:groups' To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1294150/+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 1293436] Re: Allow filtering variables passed to the RuleProcessor
** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => icehouse-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/1293436 Title: Allow filtering variables passed to the RuleProcessor Status in OpenStack Identity (Keystone): Fix Released Bug description: During SAML2 authentication the whole environment dictionary is passed to the RuleProcessor object (this dictionary will only contain basestring inheriting values after the bug #1290258 is fixed). It'd be much better to additionally let users filter what can be passed to the RuleProcessor by choosing only parameters with a certain prefix. A new configuration parameter - ''assertion_prefix'' should be added, defaulting to an empty string, which would not impact users who don't want to use this filtering method. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1293436/+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 1294292] Re: is_revoked bails out on first unrelated branch
** 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/1294292 Title: is_revoked bails out on first unrelated branch Status in OpenStack Identity (Keystone): Fix Released Bug description: When verifying if token is revoked using revocation tree, is_revoked immediately returns False if on another level we get first tree in a bundle that has no branches related to the token. This happens because new bundle is verified too early. This check needs to be shifted to upper level. Example: * create a token for one user in some project; * revoke some other user's tokens; * revoke this user's tokens in the same project. The token created in the first step will still be considered valid. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1294292/+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 1294293] Re: domain_id should be immutable by default
** 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/1294293 Title: domain_id should be immutable by default Status in OpenStack Identity (Keystone): Fix Released Bug description: An option is already provided to make the domain_id attribute in the User, Group and Project entities immutable. This can be used to prevent a domain admin persona (as implemented by a suitable policy file such as policy.v3cloudsample) from moving entities into domains for which they do not have permission. The option of making the domain_id immutable is controlled by a config option - and the default is that domain_id is mutable. In reality, almost all non-trivial production deployments will want to prevent such a movement of entities. Given this, we should therefore make the domain_id immutable by default, even though this changes functionality from previous versions. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1294293/+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 1293781] Re: Ensure sample config is up-to-date [Icehouse RC]
** 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/1293781 Title: Ensure sample config is up-to-date [Icehouse RC] Status in OpenStack Identity (Keystone): Fix Released Bug description: This is a release-blocking bug to ensure the sample configuration is up to date prior to cutting RC. This should be the last bug to be closed prior to cutting RC. This also allows any/all other config syncs to be ignored until the milestone is ready to be cut. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1293781/+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 1291099] Re: revoke_api is loaded by default and is causing 401s on horizon switch tenants
** 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/1291099 Title: revoke_api is loaded by default and is causing 401s on horizon switch tenants Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Identity (Keystone): Fix Released Bug description: On the top bar, there are two items listed (admin and demo) under tenant switcher. Log in as admin and try to select demo in the tenant switcher. Switching to demo results in "unauthorized Access " HTTP error 401. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1291099/+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 1289935] Re: Revoke API calls non-existant method in revoke map syncronize
** 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/1289935
Title:
Revoke API calls non-existant method in revoke map syncronize
Status in OpenStack Identity (Keystone):
Fix Released
Status in “keystone” package in Ubuntu:
Fix Released
Status in “keystone” source package in Trusty:
Fix Released
Bug description:
The "revoke_api" calls a non-existent method on the revoke tree object
during the synchronize method. This results in a non-recoverable error
in checking validity of a token if there are expired revocation
events.
Code block in question:
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/contrib/revoke/core.py?id=a240705b07b852616e39a2b93253f0a9a09a3ef9#n79
with self._store.get_lock(_TREE_KEY):
for e in self._current_events:
if e.revoked_at < cutoff:
self.revoke_map.remove(e)
self._current_events.remove(e)
else:
break
The code should call self.revoke_map.remove_event(e) not
self.revoke_map.remove(e).
Example traceback:
2014-03-08 20:20:59.338 TRACE keystone.common.wsgi TypeError: object of type
'NoneType' has no len()
2014-03-08 20:20:59.338 TRACE keystone.common.wsgi
2014-03-08 20:20:59.340 INFO eventlet.wsgi.server [-] 172.16.28.1 - -
[08/Mar/2014 20:20:59] "POST /v2.0/tokens HTTP/1.1" 400 239 0.004711
2014-03-08 20:20:59.351 DEBUG keystone.middleware.core [-] Auth token not in
the request header. Will not build auth context. from (pid=14327)
process_request /opt/stack/keystone/keystone/middleware/core.py:253
2014-03-08 20:20:59.352 DEBUG keystone.common.wsgi [-] arg_dict: {} from
(pid=14327) __call__ /opt/stack/keystone/keystone/common/wsgi.py:180
2014-03-08 20:20:59.353 ERROR keystone.common.wsgi [-] object of type
'NoneType' has no len()
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi Traceback (most recent
call last):
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/common/wsgi.py", line 205, in __call__
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi result =
method(context, **params)
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/openstack/common/versionutils.py", line 102, in
wrapped
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi return func(*args,
**kwargs)
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/token/controllers.py", line 97, in authenticate
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi context, auth)
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi File
"/opt/stack/keystone/keystone/token/controllers.py", line 255, in
_authenticate_local
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi if len(username) >
CONF.max_param_size:
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi TypeError: object of type
'NoneType' has no len()
2014-03-08 20:20:59.353 TRACE keystone.common.wsgi
2014-03-08 20:20:59.355 INFO eventlet.wsgi.server [-] 172.16.28.1 - -
[08/Mar/2014 20:20:59] "POST /v2.0/tokens HTTP/1.1" 400 239 0.004078
2014-03-08 20:20:59.385 DEBUG keystone.common.wsgi [-] arg_dict: {} from
(pid=14327) __call__ /opt/stack/keystone/keystone/common/wsgi.py:180
2014-03-08 20:20:59.386 INFO eventlet.wsgi.server [-] 172.16.28.100 - -
[08/Mar/2014 20:20:59] "GET / HTTP/1.1" 300 1103 0.001378
2014-03-08 20:20:59.401 DEBUG keystone.middleware.core [-] Auth token not in
the request header. Will not build auth context. from (pid=14327)
process_request /opt/stack/keystone/keystone/middleware/core.py:253
2014-03-08 20:20:59.403 DEBUG keystone.common.wsgi [-] arg_dict: {} from
(pid=14327) __call__ /opt/stack/keystone/keystone/common/wsgi.py:180
2014-03-08 20:20:59.412 DEBUG keystone.notifications [-] CADF Event:
{'typeURI': 'http://schemas.dmtf.org/cloud/audit/1.0/event', 'initiator':
{'typeURI': 'service/security/account/user', 'host': {'agent':
'python-requests/1.2.3 CPython/2.7.5+ Linux/3.11.0-12-generic', 'address':
'172.16.28.100'}, 'id': 'openstack:b0d57b38-6f65-43aa-b0ef-b807db297e5b',
'name': u'5b55216e7b1742978dca4ce4f721a6d3'}, 'target': {'typeURI':
'service/security/account/user', 'id':
'openstack:006ecd17-f59d-4bc4-9fb5-cde076e7607c'}, 'observer': {'typeURI':
'service/security', 'id': 'openstack:5b7eecb3-de9b-486c-9683-11d50d965cf8'},
'eventType': 'activity', 'eventTime': '2014-03-08T19:20:59.412018+',
'action': 'authenticate', 'outcome': 'pending', 'id':
'openstack:41e1caa6-4e8d-47f9-8a87-3e5d23c2e22d'} from (pid=14327)
_send_audit_notification /opt/stack/keystone/keystone/notifications.py:289
2014-03-08 20:20:59.447 DEBUG keystone.notifications [-] CADF Event:
{'typeURI': 'http://schemas.dmtf.org/cloud/a
[Yahoo-eng-team] [Bug 1294971] Re: gate-grenade-dsvm-partial-ncpu Failure in upgrade-keystone
** 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/1294971
Title:
gate-grenade-dsvm-partial-ncpu Failure in upgrade-keystone
Status in Grenade - OpenStack upgrade testing:
Invalid
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
http://logs.openstack.org/03/81603/2/gate/gate-grenade-dsvm-partial-ncpu/4165949/console.html#_2014-03-20_01_34_10_033
console.log:
2014-03-20 01:34:10.033 | [ERROR] /opt/stack/new/devstack/lib/keystone:439
keystone did not start
2014-03-20 01:34:11.034 | + die 249 'Failure in upgrade-keystone'
2014-03-20 01:34:11.035 | + local exitcode=1
2014-03-20 01:34:11.035 | + set +o xtrace
2014-03-20 01:34:11.035 | [Call Trace]
2014-03-20 01:34:11.035 | ./grenade.sh:249:die
2014-03-20 01:34:11.073 | [ERROR] ./grenade.sh:249 Failure in upgrade-keystone
screen-key.log
http://logs.openstack.org/03/81603/2/gate/gate-grenade-dsvm-partial-ncpu/4165949/logs/new/screen-key.txt.gz#_2014-03-20_01_32_10_651
2014-03-20 01:32:10.651 30797 CRITICAL keystone [-] NameError: global name
'_' is not defined
2014-03-20 01:32:10.651 30797 TRACE keystone Traceback (most recent call
last):
2014-03-20 01:32:10.651 30797 TRACE keystone File
"/opt/stack/new/keystone/bin/keystone-all", line 146, in
2014-03-20 01:32:10.651 30797 TRACE keystone serve(*servers)
2014-03-20 01:32:10.651 30797 TRACE keystone File
"/opt/stack/new/keystone/bin/keystone-all", line 80, in serve
2014-03-20 01:32:10.651 30797 TRACE keystone logging.exception(_('Failed
to start the %(name)s server') % {
2014-03-20 01:32:10.651 30797 TRACE keystone NameError: global name '_' is
not defined
2014-03-20 01:32:10.651 30797 TRACE keystone
key failed to start
To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1294971/+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 1295261] Re: test_v3_os_revoke.OSRevokeTests: invalid event issued_before time; Too early
** 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/1295261
Title:
test_v3_os_revoke.OSRevokeTests: invalid event issued_before time; Too
early
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
This occurred in a gate run (lost the link for the moment):
FAIL:
keystone.tests.test_v3_os_revoke.OSRevokeTests.test_disabled_project_in_list
tags: worker-1
--
pythonlogging:'': {{{
Adding cache-proxy 'keystone.tests.test_cache.CacheIsolatingProxy' to backend.
Callback: `keystone.contrib.revoke.core.Manager._trust_callback` subscribed
to event `identity.OS-TRUST:trust.deleted`.
Callback: `keystone.contrib.revoke.core.Manager._consumer_callback`
subscribed to event `identity.OS-OAUTH1:consumer.deleted`.
Callback: `keystone.contrib.revoke.core.Manager._access_token_callback`
subscribed to event `identity.OS-OAUTH1:access_token.deleted`.
Callback: `keystone.contrib.revoke.core.Manager._role_callback` subscribed to
event `identity.role.deleted`.
Callback: `keystone.contrib.revoke.core.Manager._user_callback` subscribed to
event `identity.user.deleted`.
Callback: `keystone.contrib.revoke.core.Manager._user_callback` subscribed to
event `identity.user.disabled`.
Callback: `keystone.contrib.revoke.core.Manager._project_callback` subscribed
to event `identity.project.deleted`.
Callback: `keystone.contrib.revoke.core.Manager._project_callback` subscribed
to event `identity.project.disabled`.
Callback: `keystone.contrib.revoke.core.Manager._domain_callback` subscribed
to event `identity.domain.disabled`.
CACHE_SET: Key: "'bed0a2f296a94d3598098bca72c3c2e3bef836b9'" Value:
"({'enabled': True, 'id': 'a1c7e9c7c24e4ed0992b6c1c71a715df', 'name':
'e0c8292cff164d0cba7eb93692fa65fc', 'description':
'46be6831b7934ae086f4e2237b00e73c'}, {'v': 1, 'ct': 1395322845.632957})"
CACHE_SET: Key: "'60cee77d1bb7192469a3c40b86e5b33e2fd7ac19'" Value:
"({'enabled': True, 'id': 'a1c7e9c7c24e4ed0992b6c1c71a715df', 'name':
'e0c8292cff164d0cba7eb93692fa65fc', 'description':
'46be6831b7934ae086f4e2237b00e73c'}, {'v': 1, 'ct': 1395322845.633679})"
found extension EntryPoint.parse('qpid =
oslo.messaging._drivers.impl_qpid:QpidDriver')
found extension EntryPoint.parse('zmq =
oslo.messaging._drivers.impl_zmq:ZmqDriver')
found extension EntryPoint.parse('kombu =
oslo.messaging._drivers.impl_rabbit:RabbitDriver')
found extension EntryPoint.parse('rabbit =
oslo.messaging._drivers.impl_rabbit:RabbitDriver')
found extension EntryPoint.parse('fake =
oslo.messaging._drivers.impl_fake:FakeDriver')
found extension EntryPoint.parse('log =
oslo.messaging.notify._impl_log:LogDriver')
found extension EntryPoint.parse('messagingv2 =
oslo.messaging.notify._impl_messaging:MessagingV2Driver')
found extension EntryPoint.parse('noop =
oslo.messaging.notify._impl_noop:NoOpDriver')
found extension EntryPoint.parse('routing =
oslo.messaging.notify._impl_routing:RoutingDriver')
found extension EntryPoint.parse('test =
oslo.messaging.notify._impl_test:TestDriver')
found extension EntryPoint.parse('messaging =
oslo.messaging.notify._impl_messaging:MessagingDriver')
CACHE_SET: Key: "'5ec78fa245b6d4094510876ae4afc7435c60cbf4'" Value:
"({'description': '8c27b380e06d4af8be1f3b3fa8916a13', 'enabled': True, 'id':
'07746a4e1979445182c96eba082d593b', 'name': '7fc4100921d84f05ac2738e7d25c3574',
'domain_id': 'a1c7e9c7c24e4ed0992b6c1c71a715df'}, {'v': 1, 'ct':
1395322845.641914})"
CACHE_SET: Key: "'e35808a841485cda6d2b42cb870bfb11261b0e46'" Value:
"({'description': '8c27b380e06d4af8be1f3b3fa8916a13', 'enabled': True, 'id':
'07746a4e1979445182c96eba082d593b', 'name': '7fc4100921d84f05ac2738e7d25c3574',
'domain_id': 'a1c7e9c7c24e4ed0992b6c1c71a715df'}, {'v': 1, 'ct':
1395322845.642477})"
CACHE_GET: Key: "'bed0a2f296a94d3598098bca72c3c2e3bef836b9'" Value:
"({'enabled': True, 'id': 'a1c7e9c7c24e4ed0992b6c1c71a715df', 'name':
'e0c8292cff164d0cba7eb93692fa65fc', 'description':
'46be6831b7934ae086f4e2237b00e73c'}, {'v': 1, 'ct': 1395322845.632957})"
CACHE_SET: Key: "'935a80a8b7b81bc94c1c17864dd103a9fb93a015'" Value:
"({'description': '7bc81fd73cf04d6a82760ebcbc3ffaa2', 'enabled': True, 'id':
'678d7e87fb794c3e941adf5294b13ea6', 'name': 'd8debaadff324df9870055e2ea07ea4b',
'domain_id': 'default'}, {'v': 1, 'ct': 1395322845.717836})"
CACHE_SET: Key: "'2ecc52c74d45fbd9344d1d5453f7669bccafbf3a'" Value:
"({'description': '7bc81fd73cf04d6a82760ebcbc3ffaa2', 'enabled': True, 'id':
'678d7e87fb794c3e941adf5294b13ea6', 'name': 'd8debaadff324df9870055e2ea07ea4b',
'domain_id': 'default'}, {'v': 1, 'ct': 1395322845.718511})"
CACHE_GET: Key: "'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3'" Value:
""
NeedRegenerationException
no value,
[Yahoo-eng-team] [Bug 1298039] [NEW] Glance Tests Will Fail With psutil 2.0.0
Public bug reported: psutil recently released a new version in which the majorly broke API backwards-compatibility. Currently, the requirement for psutil is 'psutil>=1.1.1'. We should limit the psutil version to 'psutil>=1.1.1,<2.0.0' so as to not break the multiprocessing tests, which use psutil. ** Affects: glance 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/1298039 Title: Glance Tests Will Fail With psutil 2.0.0 Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: psutil recently released a new version in which the majorly broke API backwards-compatibility. Currently, the requirement for psutil is 'psutil>=1.1.1'. We should limit the psutil version to 'psutil>=1.1.1,<2.0.0' so as to not break the multiprocessing tests, which use psutil. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1298039/+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 1298034] [NEW] Nova Hyper-V driver fails occasionally with a x_wmi_uninitialised_thread exception
Public bug reported:
The Nova Hyper-V driver can fail occasionally with:
x_wmi_uninitialised_thread ("WMI returned a syntax error: you're
probably running inside a thread without first calling
pythoncom.CoInitialize[Ex]"
http://64.119.130.115/82904/14/Hyper-V_logs/hv-compute1/neutron-hyperv-
agent.log.gz
Each thread that uses COM needs to initialize COM by calling
pythoncom.CoInitialize or pythoncom.CoInitializeEx.
Error stack trace:
http://64.119.130.115/82904/14/Hyper-V_logs/hv-compute1/neutron-hyperv-
agent.log.gz
** Affects: nova
Importance: Low
Status: New
** Tags: hyper-v
** Tags added: hyper-v
** Changed in: nova
Importance: Undecided => Low
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1298034
Title:
Nova Hyper-V driver fails occasionally with a
x_wmi_uninitialised_thread exception
Status in OpenStack Compute (Nova):
New
Bug description:
The Nova Hyper-V driver can fail occasionally with:
x_wmi_uninitialised_thread ("WMI returned a syntax error: you're
probably running inside a thread without first calling
pythoncom.CoInitialize[Ex]"
http://64.119.130.115/82904/14/Hyper-V_logs/hv-compute1/neutron-
hyperv-agent.log.gz
Each thread that uses COM needs to initialize COM by calling
pythoncom.CoInitialize or pythoncom.CoInitializeEx.
Error stack trace:
http://64.119.130.115/82904/14/Hyper-V_logs/hv-compute1/neutron-
hyperv-agent.log.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298034/+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 1298005] [NEW] API returns http url instead of https for create image
Public bug reported:
The response to image create returns a http url when it should be https
REQ: curl -i
'https://iad.servers.api.rackspacecloud.com/v2//servers//action'
-X POST -H "X-Auth-Project-Id: " -H "User-Agent: python-
novaclient" -H "Content-Type: application/json" -H "Accept:
application/json" -H "X-Auth-Token: " -d '{"createImage":
{"name": "Blogtest", "metadata": {}}}'
RESP: [202] CaseInsensitiveDict({'content-length': '0', 'via': '1.1
Repose (Repose/2.12)', 'x-compute-request-id': 'req-
da7323e1-c616-4122-8615-b4fec7c302eb', 'server':
'Jetty(8.0.y.z-SNAPSHOT)', 'location':
'http://iad.servers.api.rackspacecloud.com/v2//images/', 'date': 'Tue, 31 Dec 2013 15:30:03 GMT', 'content-type':
'text/html;charset=UTF-8'})
Note the 'http://...' location in the response. This is caused by SSL
termination happening before nova-api, which seems to be the recommended setup,
and the way image locations are generated via the request url. Because SSL
termination happens before nova-api it doesn't see an https request and
therefore builds the location improperly.
Long term the proper fix is probably to generate the location based on
the service catalog returned for a user. But that gets into feature
territory. For now we should take advantage of the
'osapi_glance_link_prefix' config option which is in place for almost
precisely this purpose.
** Affects: nova
Importance: Low
Assignee: Andrew Laski (alaski)
Status: In Progress
** Changed in: nova
Importance: Undecided => Low
** Changed in: nova
Status: New => In Progress
** Changed in: nova
Assignee: (unassigned) => Andrew Laski (alaski)
--
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/1298005
Title:
API returns http url instead of https for create image
Status in OpenStack Compute (Nova):
In Progress
Bug description:
The response to image create returns a http url when it should be
https
REQ: curl -i
'https://iad.servers.api.rackspacecloud.com/v2//servers//action'
-X POST -H "X-Auth-Project-Id: " -H "User-Agent: python-
novaclient" -H "Content-Type: application/json" -H "Accept:
application/json" -H "X-Auth-Token: " -d '{"createImage":
{"name": "Blogtest", "metadata": {}}}'
RESP: [202] CaseInsensitiveDict({'content-length': '0', 'via': '1.1
Repose (Repose/2.12)', 'x-compute-request-id': 'req-
da7323e1-c616-4122-8615-b4fec7c302eb', 'server':
'Jetty(8.0.y.z-SNAPSHOT)', 'location':
'http://iad.servers.api.rackspacecloud.com/v2//images/', 'date': 'Tue, 31 Dec 2013 15:30:03 GMT', 'content-type':
'text/html;charset=UTF-8'})
Note the 'http://...' location in the response. This is caused by SSL
termination happening before nova-api, which seems to be the recommended setup,
and the way image locations are generated via the request url. Because SSL
termination happens before nova-api it doesn't see an https request and
therefore builds the location improperly.
Long term the proper fix is probably to generate the location based on
the service catalog returned for a user. But that gets into feature
territory. For now we should take advantage of the
'osapi_glance_link_prefix' config option which is in place for almost
precisely this purpose.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298005/+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 1298002] [NEW] Nova does not inject DHCP config to guest OS
Public bug reported: When booting servers using Nova configured for injecting network setup into the guest OS, Nova is not injecting DHCP network configurations. Nova.conf has these set: # Whether to attempt to inject network setup into guest # (boolean value) flat_injected=true # Template file for injected network (string value) injected_network_template=$pybasedir/nova/virt/interfaces.template When you boot a server with a DHCP network, the network configuration is not included on the config drive at /openstack/content/. The network configuration does get transmitted if you boot with a static fixed IP like this: nova --image myimage --flavor 2 myVM --config-drive=true --nic net-id=a6222a6b-d3f5-4cdd-8afd-6c7b29d65906,v4-fixed-ip=192.168.0.10 This prevents you from being able to capture a snapshot of a VM that is configured with a static IP address and deploy/boot the snapshot image using a DHCP configured network. The resulting VM will still come up on the capture source's static IP. ** 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/1298002 Title: Nova does not inject DHCP config to guest OS Status in OpenStack Compute (Nova): New Bug description: When booting servers using Nova configured for injecting network setup into the guest OS, Nova is not injecting DHCP network configurations. Nova.conf has these set: # Whether to attempt to inject network setup into guest # (boolean value) flat_injected=true # Template file for injected network (string value) injected_network_template=$pybasedir/nova/virt/interfaces.template When you boot a server with a DHCP network, the network configuration is not included on the config drive at /openstack/content/. The network configuration does get transmitted if you boot with a static fixed IP like this: nova --image myimage --flavor 2 myVM --config-drive=true --nic net-id=a6222a6b-d3f5-4cdd-8afd-6c7b29d65906,v4-fixed-ip=192.168.0.10 This prevents you from being able to capture a snapshot of a VM that is configured with a static IP address and deploy/boot the snapshot image using a DHCP configured network. The resulting VM will still come up on the capture source's static IP. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298002/+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 1297998] [NEW] VMWare: spawn refactor - _power_on_vm
Public bug reported: refactor this method and add unit tests as part of the spawn refactor effort ** 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/1297998 Title: VMWare: spawn refactor - _power_on_vm Status in OpenStack Compute (Nova): New Bug description: refactor this method and add unit tests as part of the spawn refactor effort To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297998/+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 1297992] [NEW] deleting an interface hits a race condition and fails
Public bug reported:
We are seeing nova REST calls to delete an attached interface fail to work:
DELETE http://127.0.0.1:8774/v3/servers/UUID/os-attach-interfaces/UUID
DELETE http://127.0.0.1:8774/v2/UUID/servers/UUID/os-interface/UUID
In nova-cpu we see
DEBUG neutronclient.client [-] RESP:{'status': '200', 'content-length': '13',
'content-location':
'http://127.0.0.1:9696/v2.0/ports.json?network_id=0c95c39b-611f-4880-9e56-cae0eb948225&device_owner=network%3Adhcp',
'date': 'Wed, 26 Mar 2014 00:44:04 GMT', 'content-type': 'application/json;
charset=UTF-8', 'x-openstack-request-id':
'req-59333b8f-072d-4bce-b5cc-03d9af48dcc8'} {"ports": []}
/python-neutronclient/neutronclient/common/utils.py:179
nova.network.api [req-61feb3de-431b-4dcc-81c7-8a8e5b6b03ed
AttachInterfacesV3Test-673399961 AttachInterfacesV3Test-295185211] Updating
cache with info: [VIF({'ovs_interfaceid':
u'530319a7-b4d7-4289-80f8-2a1ec39c642a', 'network': Network({'bridge':
'br-int', 'subnets': [Subnet({'ips': [FixedIP({'meta': {}, 'version': 4,
'type': 'fixed', 'floating_ips': [], 'address': u'10.100.0.4'})], 'version': 4,
'meta': {}, 'dns': [], 'routes': [], 'cidr': u'10.100.0.0/28', 'gateway':
IP({'meta': {}, 'version': 4, 'type': 'gateway', 'address': u'10.100.0.1'})})],
'meta': {'injected': False, 'tenant_id': u'e9a96753b0004178bf8dd2007b01d55f'},
'id': u'0c95c39b-611f-4880-9e56-cae0eb948225', 'label':
u'AttachInterfacesV3Test-1465112406-network'}), 'devname': u'tap530319a7-b4',
'qbh_params': None, 'meta': {}, 'address': u'fa:16:3e:e8:72:f4', 'active':
True, 'type': u'ovs', 'id': u'530319a7-b4d7-4289-80f8-2a1ec39c642a',
'qbg_params': None}), VIF({'ovs_interfaceid':
u'8077e5f2-e683-42f4-b9df-9c049be25cad'
, 'network': Network({'bridge': 'br-int', 'subnets': [Subnet({'ips':
[FixedIP({'meta': {}, 'version': 4, 'type': 'fixed', 'floating_ips': [],
'address': u'10.100.0.2'})], 'version': 4, 'meta': {}, 'dns': [], 'routes': [],
'cidr': u'10.100.0.0/28', 'gateway': IP({'meta': {}, 'version': 4, 'type':
'gateway', 'address': u'10.100.0.1'})})], 'meta': {'injected': False,
'tenant_id': u'e9a96753b0004178bf8dd2007b01d55f'}, 'id':
u'0c95c39b-611f-4880-9e56-cae0eb948225', 'label':
u'AttachInterfacesV3Test-1465112406-network'}), 'devname': u'tap8077e5f2-e6',
'qbh_params': None, 'meta': {}, 'address': u'fa:16:3e:83:34:a9', 'active':
True, 'type': u'ovs', 'id': u'8077e5f2-e683-42f4-b9df-9c049be25cad',
'qbg_params': None})] update_instance_cache_with_nw_info
/opt/stack/new/nova/nova/network/api.py:74
ERROR oslo.messaging.rpc.dispatcher [-] Exception during message handling: Port
760ab1e4-10ae-4170-b491-54ec71efd952 is not attached
TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last):
TRACE oslo.messaging.rpc.dispatcher File
"/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py", line 133, in
_dispatch_and_reply
TRACE oslo.messaging.rpc.dispatcher incoming.message))
TRACE oslo.messaging.rpc.dispatcher File
"/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py", line 176, in
_dispatch
TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint,
method, ctxt, args)
TRACE oslo.messaging.rpc.dispatcher File
"/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py", line 122, in
_do_dispatch
TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint,
method)(ctxt, **new_args)
TRACE oslo.messaging.rpc.dispatcher File
"/opt/stack/new/nova/nova/compute/manager.py", line 399, in decorated_function
TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args,
**kwargs)
TRACE oslo.messaging.rpc.dispatcher File
"/opt/stack/new/nova/nova/compute/manager.py", line 4370, in detach_interface
TRACE oslo.messaging.rpc.dispatcher "attached") % port_id)
TRACE oslo.messaging.rpc.dispatcher PortNotFound: Port
760ab1e4-10ae-4170-b491-54ec71efd952 is not attached
TRACE oslo.messaging.rpc.dispatcher
ERROR oslo.messaging._drivers.common [-] Returning exception Port
760ab1e4-10ae-4170-b491-54ec71efd952 is not attached to caller
ERROR oslo.messaging._drivers.common [-] ['Traceback (most recent call
last):\n', ' File
"/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py", line 133, in
_dispatch_and_reply\nincoming.message))\n', ' File
"/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py", line 176, in
_dispatch\nreturn self._do_dispatch(endpoint, method, ctxt, args)\n', '
File "/opt/stack/new/oslo.messaging/oslo/messaging/rpc/dispatcher.py", line
122, in _do_dispatch\nresult = getattr(endpoint, method)(ctxt,
**new_args)\n', ' File "/opt/stack/new/nova/nova/compute/manager.py", line
399, in decorated_function\nreturn function(self, context, *args,
**kwargs)\n', ' File "/opt/stack/new/nova/nova/compute/manager.py", line 4370,
in detach_interface\n"attached") % port_id)\n', 'PortNotFound: Port
760ab1e4-10ae-4170-b491-54ec71efd952 is not attached\n']
http://logs.openstack.org/2
[Yahoo-eng-team] [Bug 1297291] Re: Django proxy objects are printed during tests execution
** Changed in: nova Status: New => 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/1297291 Title: Django proxy objects are printed during tests execution Status in OpenStack Compute (Nova): Invalid Bug description: During the execution of the tests, the following is printed: . .. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297291/+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 1297127] Re: nova can't detach volume after force detach in cinder
I'd say this is a reasonable thing to propose, although since forcing in cinder is an admin only command - I am thinking this should be as well. Also I fear there could be edge cases where we really should not allow even the force detach (see https://bugs.launchpad.net/nova/+bug/1240922 where we might want to disable attach for suspended instances). Having all this in mind makes me think this needs to be a BP rather than a bug - so I will move this to Won't fix, and the reporter might propose this as a Bluepring for Juno. ** Changed in: nova Status: New => 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/1297127 Title: nova can't detach volume after force detach in cinder Status in OpenStack Compute (Nova): Won't Fix Bug description: There is use case: we have two nova components（call them nova A and nova B） and one cinder component. Attach a volume to an instance in nova A and then services of nova A become abnormal. Because the volume also want to be used in nova B, so using cinder api "force detach volume" to free this volume. But when nova A is normal, nova can't detach this volume from instance by using nova api "detach volume" , as nova check the volume state must be "attached". I think should we add "force detach" function to nova just like "attach" and "detach", because if using force detach volume in cinder, there is still some attach information in nova which can't be cleaned by using nova api "detach". To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297127/+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 1297795] Re: nova python client is not process safe
** Also affects: python-novaclient 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/1297795 Title: nova python client is not process safe Status in OpenStack Compute (Nova): New Status in Python client library for Nova: New Bug description: Nova python clients shares sockets between process: this code: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L42-L52 And sharing socket between process is last thing that you would like to see in your code. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297795/+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 1297962] [NEW] Nova-compute doesnt start
Public bug reported:
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 77, in tworker
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup rv =
meth(*args,**kwargs)
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/dist-packages/libvirt.py", line 3127, in baselineCPU
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup if ret is
None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self)
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup libvirtError:
this function is not supported by the connection driver: virConnectBaselineCPU
** Affects: nova
Importance: Undecided
Status: Incomplete
** 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/1297962
Title:
Nova-compute doesnt start
Status in OpenStack Compute (Nova):
Incomplete
Bug description:
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 77, in tworker
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup rv =
meth(*args,**kwargs)
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup File
"/usr/lib/python2.7/dist-packages/libvirt.py", line 3127, in baselineCPU
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup if ret is
None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self)
2014-03-26 13:08:21.268 TRACE nova.openstack.common.threadgroup libvirtError:
this function is not supported by the connection driver: virConnectBaselineCPU
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1297962/+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 1297796] Re: nova python client is not process safe
** Also affects: python-novaclient Importance: Undecided Status: New ** No longer affects: nova -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1297796 Title: nova python client is not process safe Status in Python client library for Nova: New Bug description: Nova python clients shares sockets between process: this code: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L42-L52 And sharing socket between process is last thing that you would like to see in your code. To manage notifications about this bug go to: https://bugs.launchpad.net/python-novaclient/+bug/1297796/+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 1288098] Re: v3 Service Catalog doesn't expose service name
Reviewed: https://review.openstack.org/81975 Committed: https://git.openstack.org/cgit/openstack/identity-api/commit/?id=3b87be34c9ce48ea58e2af12cb3f59d63947d609 Submitter: Jenkins Branch:master commit 3b87be34c9ce48ea58e2af12cb3f59d63947d609 Author: Jamie Lennox Date: Fri Mar 21 13:28:07 2014 +1000 Add service name to service catalog This should have always been a part of the catalog but was overlooked in implementation. Make sure it is correctly defined in the spec to prevent it happening again. Closes-Bug: #1288098 Change-Id: I4184ae663ea06ddef924f07b881759bcae211da8 ** Changed in: openstack-api-site Status: New => 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/1288098 Title: v3 Service Catalog doesn't expose service name Status in OpenStack Identity (Keystone): In Progress Status in OpenStack API documentation site: Fix Released Bug description: Service name is a provided (though i don't think required) value for creating a service. In the V2 API this name is exposed as part of the service catalog. This name value can be filtered through the nova, glance and other clients however is not currently provided by the v3 API. I can only assume that it was dropped in the V3 API either accidentally or it was deemed that the service name should only have been needed via the domain admins. I can't see that this is a concern and the service name value should be provided as a part of the service catalog. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1288098/+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 1297469] Re: Neutron + security group + OVS is broken
OK adding OSSA task to judge the need for advisory ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1297469 Title: Neutron + security group + OVS is broken Status in OpenStack Neutron (virtual network service): Confirmed Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Incomplete Bug description: Because of this bug. https://review.openstack.org/#/c/49660/5 In order to fix this bug we need to fix https://launchpad.net/bugs/1112912, however it looks too late for Icehouse. In this bug fix, we will add new VIF driver which works with Neutron + OVS To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1297469/+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 1297890] Re: API documentation lists wrong URLs for group roles
Relevant role assignment operations are documented starting around here:
https://github.com/openstack/identity-api/blob/master/openstack-
identity-api/v3/src/markdown/identity-api-v3.md#list-groups-roles-on-
domain-get-domainsdomain_idgroupsgroup_idroles
** Project changed: keystone => openstack-api-site
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1297890
Title:
API documentation lists wrong URLs for group roles
Status in OpenStack API documentation site:
Confirmed
Bug description:
Look in http://api.openstack.org/api-ref-identity.html
It lists the APIs to manage group roles on projects:
GET v3/projects/{project_id}/groups/{group_id}/roles Lists roles for
a project group.
PUT v3/projects/{project_id}/{role_id} Grants a role to a project
group.
HEAD v3/projects/{project_id}/{role_id} Validates that a project
group has a role.
DELETE v3/projects/{project_id}/{role_id} Revokes a role from a
project group.
Only the 1st url in the above list is correct, the rest are missing
/groups/{group_id}... You get a "resource not found" error if you try
the wrong urls.
Looks like a mistake in the documentation.
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-api-site/+bug/1297890/+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 1297922] [NEW] Internationalization is broken when using httpd/keystone.py
Public bug reported: This was first mentioned on IRC last night: "gyee | yes, running under apache yield a bunch warnings related to _()". I still need more detail on this exception. I setup a devstack to test and noticed that we are not setting things up to be lazily translated. This means that all messages will be translated to the default locale. If messages are translated lazily the messages being returned to users would be translated based on the language specified in the HTTP headers. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1297922 Title: Internationalization is broken when using httpd/keystone.py Status in OpenStack Identity (Keystone): New Bug description: This was first mentioned on IRC last night: "gyee | yes, running under apache yield a bunch warnings related to _()". I still need more detail on this exception. I setup a devstack to test and noticed that we are not setting things up to be lazily translated. This means that all messages will be translated to the default locale. If messages are translated lazily the messages being returned to users would be translated based on the language specified in the HTTP headers. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1297922/+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 1297920] [NEW] Completely disabled availability zone cause horizon to trace at availability zones list
Public bug reported: If all compute nodes in some availability zone are disabled, horizon trace at availability zones list. Steps to reproduce: 1. Create host aggregate and availability zone (nova aggreage-create some some) 2. Add some (at least one) host to that host aggregate (nova aggreage-add-host some compute_host) 3. Disable service at all compute_hosts (nova service-disable compute_host nova-compute) 4. Go to (in dashboard) Admin -> System Info -> Availability Zones Expected result: Output with list of availabilizy zones Actual Result: TemplateSyntaxError at /admin/info/ 'NoneType' object has no attribute 'items' Request Method: GET Request URL:http://78.140.137.204/horizon/admin/info/ Django Version: 1.5.4 Exception Type: TemplateSyntaxError Exception Value: 'NoneType' object has no attribute 'items' Exception Location: /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/admin/info/tables.py in get_hosts, line 60 Python Executable: /usr/bin/python Python Version: 2.7.3 Python Path: ['/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../..', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/share/openstack-dashboard/', '/usr/share/openstack-dashboard/openstack_dashboard'] Server time:Wed, 26 Mar 2014 15:53:32 + P. S. +--+--+---+--+---++-+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +--+--+---+--+---++-+ | nova-scheduler | pp1 | internal | enabled | up| 2014-03-26T15:54:34.00 | None| | nova-consoleauth | pp1 | internal | enabled | up| 2014-03-26T15:54:32.00 | None| | nova-conductor | pp1 | internal | enabled | up| 2014-03-26T15:54:39.00 | None| | nova-cert| pp1 | internal | enabled | up| 2014-03-26T15:54:35.00 | None| | nova-compute | pp7 | test,nova | disabled | up| 2014-03-26T15:54:34.00 | None| | nova-compute | pp4 | nova | enabled | up| 2014-03-26T15:54:33.00 | None| | nova-compute | pp3 | nova | enabled | up| 2014-03-26T15:54:39.00 | None| +--+--+---+--+---++-+ ** 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/1297920 Title: Completely disabled availability zone cause horizon to trace at availability zones list Status in OpenStack Dashboard (Horizon): New Bug description: If all compute nodes in some availability zone are disabled, horizon trace at availability zones list. Steps to reproduce: 1. Create host aggregate and availability zone (nova aggreage-create some some) 2. Add some (at least one) host to that host aggregate (nova aggreage-add-host some compute_host) 3. Disable service at all compute_hosts (nova service-disable compute_host nova-compute) 4. Go to (in dashboard) Admin -> System Info -> Availability Zones Expected result: Output with list of availabilizy zones Actual Result: TemplateSyntaxError at /admin/info/ 'NoneType' object has no attribute 'items' Request Method: GET Request URL: http://78.140.137.204/horizon/admin/info/ Django Version: 1.5.4 Exception Type: TemplateSyntaxError Exception Value: 'NoneType' object has no attribute 'items' Exception Location: /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/admin/info/tables.py in get_hosts, line 60 Python Executable:/usr/bin/python Python Version: 2.7.3 Python Path: ['/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../..', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/share/openstack-dashboard/', '/usr/share/openstack-dashboard/openstack_dashboard'] Server time:Wed, 26 Mar 2014 15:53:32 + P. S. +--+--+---+--+---++-+ | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | +
[Yahoo-eng-team] [Bug 1261631] Re: Reconnect on failure for multiple servers always connects to first server
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => Ihar Hrachyshka (ihar-hrachyshka) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1261631 Title: Reconnect on failure for multiple servers always connects to first server Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Status in Messaging API for OpenStack: Fix Released Bug description: In attempting to reconnect to an AMQP server when a communication failure occurs, both the qpid and rabbit drivers target the configured servers in the order in which they were provided. If a connection to the first server had failed, the subsequent reconnection attempt would be made to that same server instead of trying one that had not yet failed. This could increase the time to failover to a working server. A plausible workaround for qpid would be to decrease the value for qpid_timeout, but since the problem only occurs if the failed server is the first configured, the results of the workaround would depend on the order that the failed server appears in the configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1261631/+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 1297902] [NEW] [UI] Cleanup import compatibility for Folsom
Public bug reported: There are several instances where the code is using importany to potentially grab horizon.api modules for the sake of Folsom compatibility. Now that Folsom is no longer a supported release, those should be removed. ** Affects: horizon Importance: Undecided Assignee: Chad Roberts (croberts) Status: New ** Changed in: horizon Assignee: (unassigned) => Chad Roberts (croberts) -- 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/1297902 Title: [UI] Cleanup import compatibility for Folsom Status in OpenStack Dashboard (Horizon): New Bug description: There are several instances where the code is using importany to potentially grab horizon.api modules for the sake of Folsom compatibility. Now that Folsom is no longer a supported release, those should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1297902/+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 1297894] [NEW] make it configurable to change or not change the ID of a flavor when updating a flavor
Public bug reported: When updating a flavor it will be removed and afterwards it will be created again with the same name but with a random UUID as ID. I would like to have the choice to update a flavor without changing the ID. ** 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/1297894 Title: make it configurable to change or not change the ID of a flavor when updating a flavor Status in OpenStack Dashboard (Horizon): New Bug description: When updating a flavor it will be removed and afterwards it will be created again with the same name but with a random UUID as ID. I would like to have the choice to update a flavor without changing the ID. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1297894/+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 1297890] [NEW] API documentation lists wrong URLs for group roles
Public bug reported:
Look in http://api.openstack.org/api-ref-identity.html
It lists the APIs to manage group roles on projects:
GET v3/projects/{project_id}/groups/{group_id}/roles Lists roles for a
project group.
PUT v3/projects/{project_id}/{role_id} Grants a role to a project group.
HEAD v3/projects/{project_id}/{role_id} Validates that a project group
has a role.
DELETE v3/projects/{project_id}/{role_id} Revokes a role from a project
group.
Only the 1st url in the above list is correct, the rest are missing
/groups/{group_id}... You get a "resource not found" error if you try
the wrong urls.
Looks like a mistake in the documentation.
Thank you.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1297890
Title:
API documentation lists wrong URLs for group roles
Status in OpenStack Identity (Keystone):
New
Bug description:
Look in http://api.openstack.org/api-ref-identity.html
It lists the APIs to manage group roles on projects:
GET v3/projects/{project_id}/groups/{group_id}/roles Lists roles for
a project group.
PUT v3/projects/{project_id}/{role_id} Grants a role to a project
group.
HEAD v3/projects/{project_id}/{role_id} Validates that a project
group has a role.
DELETE v3/projects/{project_id}/{role_id} Revokes a role from a
project group.
Only the 1st url in the above list is correct, the rest are missing
/groups/{group_id}... You get a "resource not found" error if you try
the wrong urls.
Looks like a mistake in the documentation.
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1297890/+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 1297875] [NEW] some tests call "called_once_with_args" with no assert, those lines are ignored
Public bug reported:
A few tests use "called_once_with_args" instead of mock's
"assert_called_once_with_args"
without checking the result.
That means that we're not asserting for that to happen.
Those tests need to be fixed.
[majopela@f20-devstack neutron]$ grep ".called_once_with" * -R | grep -v assert
neutron/tests/unit/test_dhcp_agent.py:
disable.called_once_with_args(network.id)
neutron/tests/unit/test_dhcp_agent.py:
uuid5.called_once_with(uuid.NAMESPACE_DNS, 'localhost')
neutron/tests/unit/test_post_mortem_debug.py:
mock_print_exception.called_once_with(*exc_info)
neutron/tests/unit/test_db_migration.py:
mock_open.write.called_once_with('a')
neutron/tests/unit/test_agent_netns_cleanup.py:
ovs_br_cls.called_once_with('br-int', conf.AGENT.root_helper)
neutron/tests/unit/test_metadata_agent.py:
self.eventlet.wsgi.server.called_once_with(
** 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/1297875
Title:
some tests call "called_once_with_args" with no assert, those lines
are ignored
Status in OpenStack Neutron (virtual network service):
New
Bug description:
A few tests use "called_once_with_args" instead of mock's
"assert_called_once_with_args"
without checking the result.
That means that we're not asserting for that to happen.
Those tests need to be fixed.
[majopela@f20-devstack neutron]$ grep ".called_once_with" * -R | grep -v
assert
neutron/tests/unit/test_dhcp_agent.py:
disable.called_once_with_args(network.id)
neutron/tests/unit/test_dhcp_agent.py:
uuid5.called_once_with(uuid.NAMESPACE_DNS, 'localhost')
neutron/tests/unit/test_post_mortem_debug.py:
mock_print_exception.called_once_with(*exc_info)
neutron/tests/unit/test_db_migration.py:
mock_open.write.called_once_with('a')
neutron/tests/unit/test_agent_netns_cleanup.py:
ovs_br_cls.called_once_with('br-int', conf.AGENT.root_helper)
neutron/tests/unit/test_metadata_agent.py:
self.eventlet.wsgi.server.called_once_with(
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1297875/+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 1297853] [NEW] failed to launch an instance from ISO image: TRACE nova.compute.manager MessagingTimeout: Timed out waiting for a reply to message ID
Public bug reported: Description of problem: The Openstack is installed as AIO (with nova networking) on fedora 20. The instance was launched on a flavor that has the following parameters: +--+---+---+--+---+--+---+-+---+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +--+---+---+--+---+--+---+-+---+ | 8ddee6ea-c7b3-4482-97b3-f4c9ca6a2c19 | m1.medium | 4096 | 40 | 40 | | 2 | 1.0 | True | +--+---+---+--+---+--+---+-+---+ On the first try the instance status was stuck on 'spawning', even after a time out stopped the process. On the second try the instance status was changed from 'spawning' to 'Error'. The nova compute log: 2014-03-26 15:33:58.548 15699 DEBUG nova.compute.manager [-] An error occurred _heal_instance_info_cache /usr/lib/python2.7/site-packages/nova/compute/manager.py:4569 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager Traceback (most recent call last): 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 4565, in _heal_instance_info_cache 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager self._get_instance_nw_info(context, instance, use_slave=True) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 908, in _get_instance_nw_info 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager instance) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 94, in wrapped 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager return func(self, context, *args, **kwargs) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 389, in get_instance_nw_info 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager result = self._get_instance_nw_info(context, instance) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 405, in _get_instance_nw_info 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager nw_info = self.network_rpcapi.get_instance_nw_info(context, **args) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 222, in get_instance_nw_info 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager host=host, project_id=project_id) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py", line 150, in call 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager wait_for_reply=True, timeout=timeout) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/transport.py", line 90, in _send 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager timeout=timeout) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line 409, in send 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager return self._send(target, ctxt, message, wait_for_reply, timeout) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line 400, in _send 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager result = self._waiter.wait(msg_id, timeout) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line 280, in wait 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager reply, ending, trylock = self._poll_queue(msg_id, timeout) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line 220, in _poll_queue 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager message = self.waiters.get(msg_id, timeout) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py", line 126, in get 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager 'to message ID %s' % msg_id) 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager MessagingTimeout: Timed out waiting for a reply to message ID 2b184725ad034655bf5e55c59a643758 2014-03-26 15:33:58.548 15699 TRACE nova.compute.manager Version-Release number of selected component (if applicable): python-novaclient-2.16.0
[Yahoo-eng-team] [Bug 1280033] Re: Remove dependent module py3kcompat
** Changed in: python-keystoneclient Status: Fix Committed => Fix Released ** Changed in: python-keystoneclient Milestone: None => 0.7.0 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1280033 Title: Remove dependent module py3kcompat Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): Fix Released Status in OpenStack Compute (Nova): New Status in Messaging API for OpenStack: In Progress Status in Python client library for Ceilometer: Fix Committed Status in Python client library for Cinder: In Progress Status in Python client library for Glance: In Progress Status in Python client library for heat: Fix Committed Status in Python client library for Ironic: In Progress Status in Python client library for Keystone: Fix Released Status in Python client library for Nova: In Progress Status in Python client library for Sahara (ex. Savanna): Fix Committed Status in Trove client binding: In Progress Status in OpenStack Data Processing (Sahara, ex. Savanna): In Progress Status in OpenStack contribution dashboard: Fix Committed Bug description: Everything in module py3kcompat is ready in six > 1.4.0, we don't need this module now . It was removed from oslo-incubator recently, see https://review.openstack.org/#/c/71591/. This make us don't need maintain this module any more, use six directly. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1280033/+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 1239757] Re: Let users update their own password with Identity API v3
** Changed in: python-keystoneclient Status: Fix Committed => Fix Released ** Changed in: python-keystoneclient Milestone: None => 0.7.0 -- 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/1239757 Title: Let users update their own password with Identity API v3 Status in OpenStack Dashboard (Horizon): In Progress Status in Python client library for Keystone: Fix Released Bug description: As part of bug 1237989, the 'Change Own Password' settings panel is deactivated when using Keystone v3. Once there is an API in v3 for users to update their own password (see https://blueprints.launchpad.net/keystone/+spec/v3-user-update-own- password ) we need to reenable this panel. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1239757/+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 1294862] Re: Token expiration time with memcache->kvs->dogpile is wrong
Actually appears to be the offending code in 0.3.2, which has since been fixed: https://github.com/openstack/python- keystoneclient/blob/0.3.2/keystoneclient/middleware/auth_token.py#L1022-L1025 ** Changed in: keystone Status: Incomplete => 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/1294862 Title: Token expiration time with memcache->kvs->dogpile is wrong Status in OpenStack Identity (Keystone): Invalid Bug description: There seems to be a bug somewhere when creating the expiration field for tokens when using the new memcached->kvs->dogpile->memcached storage for tokens. Aystems are UTC+1 (HW clock, TZ Europe/Oslo), and "[token] expiration = 3600" in configuration, wich is the default. No requests to any API services (except keystone) worked, all systems reported that token is expired. Put in some debugging, and it seems the expiration is set to UTC + conf.token.expiration, wich in my case actually is the same time as now(). Setting expiration to a higher value than 3600 makes the token valid. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1294862/+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 1282089] Re: keystone client is leaving hanging connections to the server
** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- 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/1282089 Title: keystone client is leaving hanging connections to the server Status in Django OpenStack Auth: In Progress Status in OpenStack Dashboard (Horizon): New Status in Python client library for Keystone: Fix Released Bug description: This is remarkable noticeable from Horizon which use keystoneclient to connect to the keystone server and at each request this later is left hanged there which consume the keystone server and at one point this will result to having keystone server process exceeding the limit of connection that is allowed to handle (ulimit of open filed). ## How to check: If you have horizon installed so just keep using it normally (creating instances ) while keeping an eye on the server number of opened files "lsof -p " you can see that the number increment pretty quickly. To reproduce this bug very fast try launching 40 instances at the same time for example using "Instance Count" field. ## Why: This because keystone client doesn't reuse the http connection pool, so in a long running service (e.g. horizon) the effect will be a new connections created for each request no connection reuse. Patch coming soon with more details. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1282089/+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 1277168] Re: having oslo.sphinx in namespace package causes issues with devstack
** Also affects: marconi Importance: Undecided Status: New ** Changed in: marconi Status: New => In Progress ** Changed in: marconi Assignee: (unassigned) => Sergey Lukjanov (slukjanov) -- 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/1277168 Title: having oslo.sphinx in namespace package causes issues with devstack Status in OpenStack Telemetry (Ceilometer): Fix Released Status in Cinder: In Progress Status in Django OpenStack Auth: Fix Committed Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Message Queuing Service (Marconi): In Progress Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Core Infrastructure: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in Messaging API for OpenStack: Fix Released Status in Tempest: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: http://lists.openstack.org/pipermail/openstack- dev/2014-January/023759.html We've decided to rename oslo.sphinx to oslosphinx. This will require small changes in the doc builds for a lot of the other projects. The problem seems to be when we pip install -e oslo.config on the system, then pip install oslo.sphinx in a venv. oslo.config is unavailable in the venv, apparently because the namespace package for o.s causes the egg-link for o.c to be ignored. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1277168/+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 1297795] [NEW] nova python client is not process safe
Public bug reported: Nova python clients shares sockets between process: this code: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L42-L52 And sharing socket between process is last thing that you would like to see in your code. ** 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/1297795 Title: nova python client is not process safe Status in OpenStack Compute (Nova): New Bug description: Nova python clients shares sockets between process: this code: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L42-L52 And sharing socket between process is last thing that you would like to see in your code. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297795/+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 1297796] [NEW] nova python client is not process safe
Public bug reported: Nova python clients shares sockets between process: this code: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L42-L52 And sharing socket between process is last thing that you would like to see in your code. ** Affects: nova Importance: High Assignee: Boris Pavlovic (boris-42) Status: New ** Changed in: nova Assignee: (unassigned) => Boris Pavlovic (boris-42) ** Changed in: nova Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1297796 Title: nova python client is not process safe Status in OpenStack Compute (Nova): New Bug description: Nova python clients shares sockets between process: this code: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L42-L52 And sharing socket between process is last thing that you would like to see in your code. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297796/+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 1297782] [NEW] regular mac learning still happen even when using l2 pop
Public bug reported: The Openvswitch mac learning rules are still used even when the l2 population driver is loaded and pre populate ovs. So that we have duplicated rules in the br-tun. ** Affects: neutron Importance: Undecided Status: New ** Tags: l2-pop ml2 ovs -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1297782 Title: regular mac learning still happen even when using l2 pop Status in OpenStack Neutron (virtual network service): New Bug description: The Openvswitch mac learning rules are still used even when the l2 population driver is loaded and pre populate ovs. So that we have duplicated rules in the br-tun. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1297782/+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 1196982] Re: Horizon git repo shouldn't include the .mo files
Adding a task on django_openstack_auth, which should follow the same policy. IIRC the problem with the initial patch was that we wanted to regenerate the mo files automatically later. I'm not sure how the other OpenStack projects handle this? ** Also affects: django-openstack-auth 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/1196982 Title: Horizon git repo shouldn't include the .mo files Status in Django OpenStack Auth: New Status in OpenStack Dashboard (Horizon): Confirmed Bug description: There is no reason why Horizon should include the .mo files. They are binary files, which makes them very good candidate for merge failures. Also, they are supposed to be generated out of the .po files, and to enforce that .mo are generated from source, a good way is to simply remove them from the Git repository. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1196982/+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 1201334] Re: libvirt disk_mappings returns bad root disk for Xen paravirtualization
I think this was already solved in https://review.openstack.org/#/c/58999/ ** Tags added: xen ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1201334 Title: libvirt disk_mappings returns bad root disk for Xen paravirtualization Status in OpenStack Compute (Nova): Fix Released Bug description: I noticed that during launching Xen paravirtualization instances over libvirt driver, root_device_name is returned as '/dev/xvda' and has to be '/dev/xvda1'. /usr/lib64/python2.6/site-packages/nova/virt/libvirt/driver.py lines 2190-2228 if CONF.libvirt_type == "xen" and guest.os_type == vm_mode.XEN: > guest.os_root = root_device_name else: guest.os_type = vm_mode.HVM I would like propose some simple patch for this and replace hard coded root device by pygrub option. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1201334/+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 1297412] Re: Rename "Images" to "Images & Snapshots"
Liz, Ju, Kieran - thanks for popping by with your feedback, this is helpful! I hadn't picked up on the fact that the command for creating instance snapshots is called "image-create". We'll probably want to bring the action name in Horizon in line with the CLI command name at some point. Kieran's "Snapshot to Image"bridge sounds like it could do the job :-) ** Changed in: horizon Status: New => Invalid -- 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/1297412 Title: Rename "Images" to "Images & Snapshots" Status in OpenStack Dashboard (Horizon): Invalid Bug description: When the Volume Snapshots were removed from the "Images & Snapshots" panel, the panel was also renamed to "Images". https://github.com/openstack/horizon/commit/3d25f1d5951beca1a73683567725ed26620ab373 I think it would make sense to rename the panel "Images & Snapshots". End-users can create Instances Snapshots from the "Instances" panel and might not know that an "instance snapshot" is the same as an "image". I think it can make it confusing to find "where did my snapshots end up?" (Note: I'm only suggesting changing the Panel "name" string, not renaming the classes and directory structure as was done in the initial patch). I understand there is however an additional element of confusion in that volumes can have snapshots too, and these live in the Volume panel... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1297412/+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 1297701] [NEW] Create VM use another tenant's port, the VM can't communicate with other
Public bug reported:
An admin user create port for another project, then use this port Create
VM, the VM can't communicate with other, because the security rule does
not work. the vm in nova can not show IP.
root@ubuntu01:/var/log/neutron# neutron port-show
66c2d6bd-7d39-4948-b561-935cb9d264eb
+---+---+
| Field | Value
|
+---+---+
| admin_state_up| True
|
| allowed_address_pairs | {"ip_address": "169.254.16.253", "mac_address":
"fa:16:3e:48:73:a7"} |
| binding:capabilities | {"port_filter": false}
|
| binding:host_id |
|
| binding:vif_type | unbound
|
| device_id |
|
| device_owner |
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id": "5519e015-fc83-44c2-99ad-d669b3c2c9d7",
"ip_address": "10.10.10.4"} |
| id| 66c2d6bd-7d39-4948-b561-935cb9d264eb
|
| mac_address | fa:16:3e:48:73:a7
|
| name |
|
| network_id| 255f3e92-5a6e-44a5-bbf9-1a62bf5d5935
|
| security_groups | 94ad554f-392d-4dd5-8184-357f37b75111
|
| status| DOWN
|
| tenant_id | 3badf700bbc749ec9d9869fddc63899f
|
+---+---+
root@ubuntu01:/var/log/neutron# keystone tenant-list
+--+-+-+
|id| name | enabled |
+--+-+-+
| 34fddbc22c184214b823be267837ef81 | admin | True |
| 48eb4330b6e74a9f9e74d3e191a0fa2e | service | True |
+--+-+-+
root@ubuntu01:/var/log/neutron# nova list
+--+---+++-+--+
| ID | Name | Status | Task State | Power
State | Networks |
+--+---+++-+--+
| 5ce98599-75cb-49db-aa76-668491ee3bd0 | test3 | ACTIVE | None | Running
| |
+--+---+++-+--+
** Affects: neutron
Importance: Undecided
Assignee: shihanzhang (shihanzhang)
Status: New
** Affects: nova
Importance: Undecided
Assignee: shihanzhang (shihanzhang)
Status: New
** Changed in: neutron
Assignee: (unassigned) => shihanzhang (shihanzhang)
** Also affects: nova
Importance: Undecided
Status: New
** Changed in: nova
Assignee: (unassigned) => shihanzhang (shihanzhang)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1297701
Title:
Create VM use another tenant's port, the VM can't communicate with
other
Status in OpenStack Neutron (virtual network service):
New
Status in OpenStack Compute (Nova):
New
Bug description:
An admin user create port for another project, then use this port
Create VM, the VM can't communicate with other, because the security
rule does not work. the vm in nova can not show IP.
root@ubuntu01:/var/log/neutron# neutron port-show
66c2d6bd-7d39-4948-b561-935cb9d264eb
+---+---+
| Field | Value
|
+---+---+
| admin_state_up| True
|
| allowed_
[Yahoo-eng-team] [Bug 1297685] [NEW] Spaces in SSH public key comment breaks cloud-init
Public bug reported: A Nova generated public SSH key contains the comment 'Generated by Nova'. Earlier versions of cloud-init (prior to 0.7.2) can't properly handle spaces in key comments and as a result, fail to disable the root account (if configured to do so). Earlier Nova versions (Essex and older) didn't have spaces in the comment. Problem introduced by commit: 114109dbf4094ae6b6333d41c84bebf6f85c4e48 cloud-init bug report: https://bugs.launchpad.net/ubuntu/+source/cloud- init/+bug/1220273 ** Affects: nova Importance: Undecided Assignee: Juerg Haefliger (juergh) Status: New ** Changed in: nova Assignee: (unassigned) => Juerg Haefliger (juergh) -- 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/1297685 Title: Spaces in SSH public key comment breaks cloud-init Status in OpenStack Compute (Nova): New Bug description: A Nova generated public SSH key contains the comment 'Generated by Nova'. Earlier versions of cloud-init (prior to 0.7.2) can't properly handle spaces in key comments and as a result, fail to disable the root account (if configured to do so). Earlier Nova versions (Essex and older) didn't have spaces in the comment. Problem introduced by commit: 114109dbf4094ae6b6333d41c84bebf6f85c4e48 cloud-init bug report: https://bugs.launchpad.net/ubuntu/+source /cloud-init/+bug/1220273 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1297685/+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 1297661] [NEW] neutron-lbaas-agent does not monit if haproxy is still alive
Public bug reported: Hi all, When neutron-lbaas-agent use haproxy , and if haproxy process itself is crash. neutron-lbaas-agent will not restart haproxy. I think neutron-lbaas-agent need to restart haproxy. ** Affects: neutron Importance: Undecided Assignee: Liping Mao (limao) Status: New ** Changed in: neutron Assignee: (unassigned) => Liping Mao (limao) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1297661 Title: neutron-lbaas-agent does not monit if haproxy is still alive Status in OpenStack Neutron (virtual network service): New Bug description: Hi all, When neutron-lbaas-agent use haproxy , and if haproxy process itself is crash. neutron-lbaas-agent will not restart haproxy. I think neutron-lbaas-agent need to restart haproxy. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1297661/+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 1297620] Re: keystone logrotate configuration causing service disruption
This looks like an downstream bug for RedHat? If so, I believe it should
be filed here: https://bugzilla.redhat.com/enter_bug.cgi?product=RDO
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1297620
Title:
keystone logrotate configuration causing service disruption
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
Logrotate is configured to rotate the keystone logs every 24 hours.
The problem is that restart keystone is added after logrotate. This
causes a disruption in service.
/var/log/keystone/keystone.log {
daily
missingok
rotate 5
postrotate
restart keystone >/dev/null 2>&1 || true
endscript
compress
delaycompress
notifempty
}
Just removing the line "restart keystone >/dev/null 2>&1 || true"
fixes this problem. Moreover, logging also happens to keystone.log
itself rather than keystone.log.1 even when logrotate is triggered
after deleting the restart line.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1297620/+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
