[Yahoo-eng-team] [Bug 1213080] Re: no config for multiple conductor workers
** Changed in: nova 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/1213080 Title: no config for multiple conductor workers Status in OpenStack Compute (Nova): Fix Released Bug description: Nova-conductor processes access the database directly. Since the database connection driver is typically implemented in a library beyond the purview of eventlet’s monkeypatching (i.e., a native python extension like _mysql.so), blocking database calls will block all eventlet coroutines. Since much of what nova-conductor does is access the database, a nova-conductor process’s handling of requests is effectively serial. To mitigate this problem, you can simply run more nova-conductor processes. Deploying multiple conductor workers per host avoids serialization on database accesses caused by libmysqlclient.so blocking eventlet's single thread. In an experiment on a 24-core machine, when creating 20 VMs in parallel, maximum creation time was reduced by approx. 10s when using 20 conductor processes vis-a-vis a single conductor process. Profiling showed that all of the savings came from faster calls into nova.db.sqlalchemy.api. To make running multiple nova-conductor processes straightforward, there should be a workers=N option in the [conductor] section of nova.conf -- just like the osapi_compute_workers=N flag in the [DEFAULT] section. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1213080/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1224462] Re: nova interface-attach triggers an AttributeError
*** This bug is a duplicate of bug 1233504 *** https://bugs.launchpad.net/bugs/1233504 ** This bug has been marked a duplicate of bug 1233504 Attach interface to instance failed at compute manage -- 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/1224462 Title: nova interface-attach triggers an AttributeError Status in OpenStack Compute (Nova): Fix Released Bug description: When running the following command: $ nova interface-attach --net-id We get this error: ERROR: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req- 3f9ae1a1-a652-4ac5-a255-f118a0f35042) Traceback: http://paste.openstack.org/show/46845/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1224462/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1207553] Re: CONF.default_flavor is only used in the EC2 API but defined in nova/compute/flavors.py
** Changed in: nova 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/1207553 Title: CONF.default_flavor is only used in the EC2 API but defined in nova/compute/flavors.py Status in OpenStack Compute (Nova): Fix Released Bug description: The Nova API requires a flavor, but the EC2 API does not, it uses flavors.get_flavor_by_name, which returns the default flavor is none is specified. def get_flavor_by_name(name, ctxt=None): """Retrieves single flavor by name.""" if name is None: return get_default_flavor() Since this config option is only used in the EC2 API it should be defined in the EC2 API along with a better help message. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1207553/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1203416] Re: EC2 API errors do not match spec
** Changed in: nova 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/1203416 Title: EC2 API errors do not match spec Status in OpenStack Compute (Nova): Fix Released Bug description: Using code written against the Boto client library and originally tested against EC2 I'm finding I have to retrofit all my exception handling because Nova seems to just wrap its own exceptions as EC2ResponseError, so the error codes have no resemblance to the EC2 API error codes: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/api-error-codes.html For example, when I hit Nova quota limits and try to start new instances I get: File "/opt/local/nimrodg/share/nimrod/boto/ec2/connection.py", line 715, in run_instances verb='POST') File "/opt/local/nimrodg/share/nimrod/boto/connection.py", line 1000, in get_object raise self.ResponseError(response.status, response.reason, body) EC2ResponseError: EC2ResponseError: 400 Bad Request TooManyInstancesQuota exceeded for cores,ram: Request ed 4, but already used 80 of 80 coresreq-74d2e517-c99f-43e6-bfc 1-651ef79737ff But I'm expecting the error code for this from an EC2 compatible API to be InstanceLimitExceeded. Seems like it should be possible be add the equivalent ec2_api_error string to all suitable Nova exceptions and then have Nova's EC2 API use that where available? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1203416/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1175686] Re: Documentation doesn't explain how to install virtualenv
** Changed in: keystone Status: Fix Committed => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1175686 Title: Documentation doesn't explain how to install virtualenv Status in OpenStack Identity (Keystone): Opinion Bug description: In the page "Setting up a Keystone development environment" (http://docs.openstack.org/developer/keystone/setup.html), the section "Installing dependencies", the subsection "PyPi Packages and VirtualEnv" recommends to set up a virtual environment. However, it doesn't explain how to set it up: edu@petra:~/OpenStack/keystone$ python tools/install_venv.py ERROR: virtualenv not found. Keystone development requires virtualenv, please install it using your favorite package management tool The following package is required: sudo apt-get install python-virtualenv To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175686/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1205344] Re: mkfs error in test_stamp_pattern
** Changed in: cinder
Status: Fix Committed => Fix Released
** Tags removed: havana-rc-potential
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1205344
Title:
mkfs error in test_stamp_pattern
Status in Cinder:
Fix Released
Status in OpenStack Compute (Nova):
Confirmed
Status in Tempest:
Fix Released
Bug description:
http://logs.openstack.org/09/38709/5/check/gate-tempest-devstack-vm-
postgres-full/35583/console.html
Error during gate-tempest-devstack-vm-postgres-full:
==
2013-07-26 14:03:32.073 | ERROR:
tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern
2013-07-26 14:03:32.073 |
--
2013-07-26 14:03:32.110 | _StringException: Traceback (most recent call last):
2013-07-26 14:03:32.110 | File
"/opt/stack/new/tempest/tempest/scenario/test_stamp_pattern.py", line 218, in
test_stamp_pattern
2013-07-26 14:03:32.110 | self._create_timestamp(ip_for_server)
2013-07-26 14:03:32.110 | File
"/opt/stack/new/tempest/tempest/scenario/test_stamp_pattern.py", line 188, in
_create_timestamp
2013-07-26 14:03:32.110 | ssh_client.exec_command('sudo
/usr/sbin/mkfs.ext4 /dev/vdb')
2013-07-26 14:03:32.110 | File
"/opt/stack/new/tempest/tempest/common/ssh.py", line 138, in exec_command
2013-07-26 14:03:32.110 | strerror=''.join(err_data))
2013-07-26 14:03:32.110 | SSHExecCommandFailed: Command 'sudo
/usr/sbin/mkfs.ext4 /dev/vdb', exit status: 1, Error:
2013-07-26 14:03:32.110 | mke2fs 1.42.2 (27-Mar-2012)
2013-07-26 14:03:32.110 | Could not stat /dev/vdb --- No such file or
directory
2013-07-26 14:03:32.110 |
2013-07-26 14:03:32.110 | The device apparently does not exist; did you
specify it correctly?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1205344/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1068154] Re: Renaming Instance Name doesn't change hostname on a Rebuild
** Changed in: nova Status: In Progress => Fix Committed ** Changed in: nova Status: Fix Committed => Opinion ** Changed in: nova Status: Opinion => Fix Committed -- 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/1068154 Title: Renaming Instance Name doesn't change hostname on a Rebuild Status in OpenStack Compute (Nova): Fix Committed Bug description: Renaming an instance name via novaclient only changes the display_name, it doesn't actually update the hostname or display_description in the instances table. This means if I want to change the name of an instance, and then rebuild it, it will utilize the original name as set in hostname. Renaming an instance name should also update the other fields. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1068154/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1236875] Re: unable to hotplug additional network interfaces into instances
*** This bug is a duplicate of bug 1233504 *** https://bugs.launchpad.net/bugs/1233504 ** This bug has been marked a duplicate of bug 1233504 Attach interface to instance failed at compute manage -- 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/1236875 Title: unable to hotplug additional network interfaces into instances Status in OpenStack Compute (Nova): New Status in “nova” package in Ubuntu: New Status in “nova” source package in Saucy: New Bug description: Nova RC1 with Neutron OpenvSwitch Plugin on Ubuntu 12.04 from the Havana Cloud Archive Staging PPA. Issuing: nova interface-attach --net-id bab112ff-46c3-4034-8d27-936d7bb1ecd5 06401d17-ec0a-446e-9fac-67cef01a4060 should hotplug an additional network interface into instance 06401d17 -ec0a-446e-9fac-67cef01a4060; but nova throws the following error/trace: 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi Traceback (most recent call last): 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py", line 461, in _process_data 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi **args) 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py", line 172, in dispatch 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi result = getattr(proxyobj, method)(ctxt, **kwargs) 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 3880, in attach_interface 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi self.driver.attach_interface(instance, image_meta, network_info[0]) 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1244, in attach_interface 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi self.vif_driver.plug(instance, vif) 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py", line 539, in plug 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi vif_type = vif['type'] 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi 2013-10-08 13:48:44.158 1106 TRACE nova.api.openstack.wsgi TypeError: string indices must be integers, not str To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1236875/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1239634] [NEW] parameter --pass in user-create shown as optional, but API requires it
You have been subscribed to a public bug: stack@devstack002:~$ keystone user-create --name foobar Expecting to find string in password. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) stack@devstack002:~$ keystone user-create --name foobar --pass testing +--+--+ | Property | Value | +--+--+ | email | | | enabled | True | |id| 84aa899dcc964a2390dcf9818d247c59 | | name | foobar | +--+--+ ** Affects: keystone Importance: Undecided Status: New -- parameter --pass in user-create shown as optional, but API requires it https://bugs.launchpad.net/bugs/1239634 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1237892] Re: UnicodeEncodeError when Running CLI keystone tenant-delete action with non-English characters
Reviewed: https://review.openstack.org/51511 Committed: http://github.com/openstack/keystone/commit/a0ae37eb3ea96a394f10d3f38e8b454d2d7a98e0 Submitter: Jenkins Branch:milestone-proposed commit a0ae37eb3ea96a394f10d3f38e8b454d2d7a98e0 Author: Morgan Fainberg Date: Sun Oct 13 18:34:24 2013 -0700 Handle unicode at the caching layer more elegantly This patchset resolves an issue where in some cases unicode would cause the cache key generator to raise a UnicodeEncodeError due to the name/value being outside of the standard ascii character set. Included is a fix to the cache backend debug code to utilize repr for passing the keys/values to the logger. Tests in test_backend provided by chenxiao Closes-bug: 1237892 Change-Id: Ic99503987851128cd41d83ad1ea50dc4a132fbd3 ** 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/1237892 Title: UnicodeEncodeError when Running CLI keystone tenant-delete action with non-English characters Status in OpenStack Identity (Keystone): Fix Released Bug description: keystone tenant-delete action with non-English characters occurs UnicodeEncodeError in log file, but the tenant has been delete in fact. input below command: [[root@osee22-compute02 ˜]# keystone tenant-delete testソ十豹 [root@osee22-compute02 ˜]# keystone tenant-list +--+-+-+ | id | name | enabled | +--+-+-+ | e7308b169a784693b39c60e152c7d01a | Public | True | | 9b78773f34264a428073412ef7d5485e | service | True | +--+-+-+ log: 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi Traceback (most recent call last): 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi File "/usr/lib/python2.6/site-packages/keystone/common/wsgi.py", line 238, in __call__ 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi result = method(context, **params) 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi File "/usr/lib/python2.6/site-packages/keystone/identity/controllers.py", line 124, in delete_project 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi self.assignment_api.delete_project(tenant_id) 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi File "/usr/lib/python2.6/site-packages/keystone/notifications.py", line 44, in wrapper 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi result = f(*args, **kwargs) 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi File "/usr/lib/python2.6/site-packages/keystone/assignment/core.py", line 93, in delete_project 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi project['domain_id']) 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi File "/usr/lib/python2.6/site-packages/dogpile/cache/region.py", line 939, in invalidate 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi key = key_generator(*arg, **kw) 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi File "/usr/lib/python2.6/site-packages/dogpile/cache/util.py", line 86, in generate_key 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi return namespace + "|" + " ".join(map(to_str, args)) 2013-09-25 21:06:50.280 3622 TRACE keystone.common.wsgi UnicodeEncodeError: 'ascii' codec can't encode characters in position 4-6: ordinal not in range(128) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1237892/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1237989] Re: user can update his password without knowing the old password
Reviewed: https://review.openstack.org/51667 Committed: http://github.com/openstack/horizon/commit/d716bfcdbfe6d4c22df9e1ae5fdb7a54d5150f28 Submitter: Jenkins Branch:milestone-proposed commit d716bfcdbfe6d4c22df9e1ae5fdb7a54d5150f28 Author: Matthias Runge Date: Fri Oct 11 11:17:59 2013 +0200 Hide settings/change password on keystone v3 When using keystone v3, it was possible to change the user password without knowing the old password. Change-Id: I2e3721f9c8a1de4b9a5f85b230432844d2c83507 Closes-Bug: 1237989 ** Changed in: horizon 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/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Committed Status in OpenStack Security Advisories: Incomplete Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1237989] Re: user can update his password without knowing the old password
Reviewed: https://review.openstack.org/50966 Committed: http://github.com/openstack/keystone/commit/3866991918beb818aa26aeab287a247f4732f6e7 Submitter: Jenkins Branch:milestone-proposed commit 3866991918beb818aa26aeab287a247f4732f6e7 Author: Dolph Mathews Date: Thu Oct 10 10:36:00 2013 -0500 set user_update policy to admin_required This changes the default policy.json to prevent users from changing their own attributes such as password, name, or default_project_id. Closes-Bug: 1237989 Change-Id: I7de5fff3d72a76b78113e289c57a9fac2096395f ** 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/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Incomplete Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1239865] Re: Nova API services uses python iso8601 module incorrectly causing a traceback
This was an environmental problem. Disregard. ** 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/1239865 Title: Nova API services uses python iso8601 module incorrectly causing a traceback Status in OpenStack Compute (Nova): Invalid Bug description: Running a command such as 'nova keypair-list' returns a 500. The nova/api.log file shows the following. Editing the code to use iso8601.Utc() instead of iso8601.iso8601.Utc() corrects the problem. This is in the Havana release on RHEL(-ish) 6. 2013-10-14 14:58:50.170 21371 ERROR nova.api.openstack [req-41ef110f-b3fe-4809-a479-59aa94c4c463 cd60cba79d3548bc90b7dee9f2e0ec0d f74b35bfadfb4e0b8141e10ee0d3f6ef] Caught error: 'module' object has no attribute 'iso8601' 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack Traceback (most recent call last): 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/nova/api/openstack/__init__.py", line 119, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return req.get_response(self.application) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/request.py", line 1296, in send 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack application, catch_exc_info=False) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/request.py", line 1260, in call_application 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/dec.py", line 144, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return resp(environ, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 539, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return self.app(env, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/dec.py", line 144, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return resp(environ, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/dec.py", line 144, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return resp(environ, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/Routes-1.12.3-py2.6.egg/routes/middleware.py", line 131, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack response = self.app(environ, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/dec.py", line 144, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return resp(environ, start_response) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/dec.py", line 130, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/webob/dec.py", line 195, in call_func 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py", line 917, in __call__ 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack content_type, body, accept) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py", line 976, in _process_stack 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack action_result = self.dispatch(meth, request, action_args) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py", line 1057, in dispatch 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack return method(req=request, **action_args) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/nova/api/openstack/compute/contrib/keypairs.py", line 147, in index 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack key_pairs = self.api.get_key_pairs(context, context.user_id) 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack File "/usr/lib/python2.6/site-packages/nova/compute/api.py", line 3284, in get_key_pairs 2013-10-14 14:58:50.170 21371 TRACE nova.api.openstack
[Yahoo-eng-team] [Bug 1110852] Re: Log line should be ERROR not INFO
I don't think this should be logged as an error in the nova api logs because users specifying images that may not exist is part of normal expected behaviour. And the missing request image message is returned in the HTTP response to the request. ** 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/1110852 Title: Log line should be ERROR not INFO Status in OpenStack Compute (Nova): Won't Fix Bug description: Had a issue where images had been moved, had a really hard time tracking it down because it was an INFO line and not an ERROR. Thought it might save people some time to adjust this to an ERROR. Running Folsom. Jan 30 17:15:42 vmperf01 2013-01-30 17:15:42 INFO nova.api.openstack.wsgi [req-b48b959a-5146-4de2-aba0-7907ff4be882 2ec0e33fc6f54ff29a0b2c67a901c6c3 06def676fd0d4ffca909c93d08edec66] HTTP exception thrown: Can not find requested image To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1110852/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1226334] Re: nova-schedule should log reason for failure to schedule
** 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/1226334 Title: nova-schedule should log reason for failure to schedule Status in OpenStack Compute (Nova): Fix Released Bug description: If log level is set to INFO, you'll only see a log message about nova- schedule attempting to build n instances then a log message about setting the state to error when the scheduler fails to schedule an instance due to a filter returning 0 hosts. If you set it to DEBUG, you can see clearly which filter it failed. nova-schedule should log which filter failed when on log level INFO. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1226334/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1202963] Re: Unable to run g-api due to sheepdog store
*** This bug is a duplicate of bug 1202098 ***
https://bugs.launchpad.net/bugs/1202098
** This bug has been marked a duplicate of bug 1202098
glance-api failed to startup caused by UnicodeEncodeError in non-English
environment
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1202963
Title:
Unable to run g-api due to sheepdog store
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Bug description:
I am using the latest devstack and openstack code. ./stack.sh will
prompt the following log for g-api:
===g-api===
2013-07-19 03:42:22.387 20198 DEBUG glance.store.location [-] Registering
scheme https with {'store_class': ,
'location_class': }
register_scheme_map /opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.387 20198 DEBUG glance.store [-] Attempting to import
store glance.store.rbd.Store _get_store_class
/opt/stack/glance/glance/store/__init__.py:144
2013-07-19 03:42:22.392 20198 DEBUG glance.store [-] Registering store with schemes ('rbd',) create_stores
/opt/stack/glance/glance/store/__init__.py:174
2013-07-19 03:42:22.393 20198 DEBUG glance.store.base [-] Late loading
location class glance.store.rbd.StoreLocation get_store_location_class
/opt/stack/glance/glance/store/base.py:68
2013-07-19 03:42:22.393 20198 DEBUG glance.store.location [-] Registering
scheme rbd with {'store_class': ,
'location_class': } register_scheme_map
/opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.393 20198 DEBUG glance.store [-] Attempting to import
store glance.store.s3.Store _get_store_class
/opt/stack/glance/glance/store/__init__.py:144
2013-07-19 03:42:22.398 20198 DEBUG glance.store [-] Registering store with schemes ('s3', 's3+http', 's3+https')
create_stores /opt/stack/glance/glance/store/__init__.py:174
2013-07-19 03:42:22.398 20198 DEBUG glance.store.base [-] Late loading
location class glance.store.s3.StoreLocation get_store_location_class
/opt/stack/glance/glance/store/base.py:68
2013-07-19 03:42:22.398 20198 DEBUG glance.store.location [-] Registering
scheme s3 with {'store_class': ,
'location_class': } register_scheme_map
/opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.398 20198 DEBUG glance.store.location [-] Registering
scheme s3+http with {'store_class': ,
'location_class': } register_scheme_map
/opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.399 20198 DEBUG glance.store.location [-] Registering
scheme s3+https with {'store_class': ,
'location_class': } register_scheme_map
/opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.399 20198 DEBUG glance.store [-] Attempting to import
store glance.store.swift.Store _get_store_class
/opt/stack/glance/glance/store/__init__.py:144
2013-07-19 03:42:22.434 20198 DEBUG glance.store [-] Registering store
with schemes ('swift+https', 'swift',
'swift+http') create_stores /opt/stack/glance/glance/store/__init__.py:174
2013-07-19 03:42:22.435 20198 DEBUG glance.store.base [-] Late loading
location class glance.store.swift.StoreLocation get_store_location_class
/opt/stack/glance/glance/store/base.py:68
2013-07-19 03:42:22.435 20198 DEBUG glance.store.location [-] Registering
scheme swift+https with {'store_class': ,
'location_class': }
register_scheme_map /opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.435 20198 DEBUG glance.store.location [-] Registering
scheme swift+http with {'store_class': ,
'location_class': }
register_scheme_map /opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.435 20198 DEBUG glance.store.location [-] Registering
scheme swift with {'store_class': ,
'location_class': }
register_scheme_map /opt/stack/glance/glance/store/location.py:86
2013-07-19 03:42:22.435 20198 DEBUG glance.store [-] Attempting to import
store glance.store.sheepdog.Store _get_store_class
/opt/stack/glance/glance/store/__init__.py:144
2013-07-19 03:42:22.443 20198 DEBUG glance.openstack.common.processutils [-]
Running cmd (subprocess): collie execute
/opt/stack/glance/glance/openstack/common/processutils.py:142
2013-07-19 03:42:22.474 20198 DEBUG glance.openstack.common.processutils [-]
Result was 127 execute
/opt/stack/glance/glance/openstack/common/processutils.py:167
2013-07-19 03:42:22.474 20198 ERROR glance.store.sheepdog [-]
储存配置错误：Unexpected error while running command.
Command: collie
Exit code: 127
Stdout: ''
Stderr: '/bin/sh: 1: collie: not found\n'
2013-07-19 03:42:22.495 20198 CRITICAL glance [-] 'ascii' codec can't encode
characters in position 0-7: ordinal not in range(128)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1202963/+subscriptions
--
Maili
[Yahoo-eng-team] [Bug 1239894] Re: openstack services unable to reach to self-signed keystone
This doesn't appear to be relevant to nova itself
** 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/1239894
Title:
openstack services unable to reach to self-signed keystone
Status in OpenStack Compute (Nova):
Invalid
Status in Python client library for Keystone:
Incomplete
Bug description:
We use self signed certificate with all openstack services. It all
worked so far, but break once keystoneclient v0.4.0 was released last
week.
As per this commit, keystoneclient by default use insecure=False.
https://github.com/openstack/python-keystoneclient/commit/20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
This break self-signed instances. The openstack components {nova,
glance, neutron} are unable to communicate with keystone. We don't use
horion or swift. I presume they are broken as well. The keystone
client is happy though if we use --insecure flag, while using it
directly.
Ideally, we should introduce new config parameter
keystone_api_insecure. The insecure flag in keystoneclient should be
defined based on this parameter. This should be fixed in all openstack
services, nova, glance & neutron.
[barumugam@build tempest]$ keystone --insecure tenant-list
+++-+
| id |name| enabled |
+++-+
| csi-tenant-tempest | csi-tenant-tempest | True |
+++-+
[barumugam@build tempest]$ nova --insecure list
ERROR: Unauthorized (HTTP 401)
Nova log:
2013-10-13 00:01:56,680 (keystoneclient.middleware.auth_token): ERROR
auth_token _http_request HTTP connection exception: [Errno 1] _ssl.c:490:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed
2013-10-13 00:01:56,682 (keystoneclient.middleware.auth_token): DEBUG
auth_token _validate_user_token Token validation failure.
Traceback (most recent call last):
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 808, in _validate_user_token
verified = self.verify_signed_token(user_token)
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 1165, in verify_signed_token
if self.is_signed_token_revoked(signed_text):
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 1127, in is_signed_token_revoked
revocation_list = self.token_revocation_list
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 1217, in token_revocation_list
self.token_revocation_list = self.fetch_revocation_list()
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 1235, in fetch_revocation_list
additional_headers=headers)
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 739, in _json_request
response = self._http_request(method, path, **kwargs)
File
"/usr/local/csi/share/csi-nova.venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py",
line 704, in _http_request
raise NetworkError('Unable to communicate with keystone')
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1239894/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1204994] Re: Seems to be some stray metadata in locations table
** Changed in: glance Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1204994 Title: Seems to be some stray metadata in locations table Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Bug description: Latest devstack: 1) create an image $ glance image-create --name s1 --disk-format raw --container-format bare < /etc/motd +--+--+ | Property | Value| +--+--+ | checksum | 6e99589be801b799dd580ada9493ef55 | | container_format | bare | | created_at | 2013-07-25T16:22:02 | | deleted | False| | deleted_at | None | | disk_format | raw | | id | eef5de15-79e1-4bb1-9482-4609ae404bb5 | | is_public| False| | min_disk | 0| | min_ram | 0| | name | s1 | | owner| ecc4670241e842c991b8737802468e20 | | protected| False| | size | 641 | | status | active | | updated_at | 2013-07-25T16:22:02 | +--+--+ 2) Take a look at the image's entry in the image_locations table: $ mysql -uroot -p -h localhost glance -e 'select * from image_locations where image_id="eef5de15-79e1-4bb1-9482-4609ae404bb5"' ++--+---+-+-++-+---+ | id | image_id | value | created_at | updated_at | deleted_at | deleted | meta_data | ++--+---+-+-++-+---+ | 5 | eef5de15-79e1-4bb1-9482-4609ae404bb5 | swift+http://service%3Aglance:@10.6.101.232:5000/v2.0/glance/eef5de15-79e1-4bb1-9482-4609ae404bb5 | 2013-07-25 16:22:02 | 2013-07-25 16:22:02 | NULL | 0 | }q. | ++--+---+-+-++-+---+ the 'meta_data' field entry (0|}q. looks suspect to me. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1204994/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1212338] Re: Auto-created ports count against port quota
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1212338 Title: Auto-created ports count against port quota Status in OpenStack Neutron (virtual network service): Expired Bug description: Ports that are created for a new network -- lots of them by my experience (one for the L3 agent the tenant router is assigned to and one port for each compute worker in the AZ! -- count against the port quota for a tenant. So, in a practical sense, what this means is that for even a small AZ with 16 compute workers, even though a tenant's default network, subnet, and router quota is 10, the tenant actually won't be able to create more than a couple networks and floating IP addresses, since the port quota would be exhausted almost immediately. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1212338/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
