[Yahoo-eng-team] [Bug 1426241] [NEW] pci plugin needs to be re-enabled for V2 microversions
Public bug reported: The PCI API support was enabled for v3 but never for V2. However V2.1 is built on v3 and it includes everything in v3. So we are disabling pci support in v3. and then will renable in the v2 microversions as one of the early microversion changes. This bug is to keep track of this work. ** 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/1426241 Title: pci plugin needs to be re-enabled for V2 microversions Status in OpenStack Compute (Nova): New Bug description: The PCI API support was enabled for v3 but never for V2. However V2.1 is built on v3 and it includes everything in v3. So we are disabling pci support in v3. and then will renable in the v2 microversions as one of the early microversion changes. This bug is to keep track of this work. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1426241/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1394022] [NEW] v2.1 api sample tests taking a long time to run
Public bug reported: There have been reports that the api sample tests for v2.1 are taking significantly longer to run that the v2 versions. This needs to be investigated and fixed. Eg. is it setup time (stevedore?), is it jsonschema input validation? Or something else ** 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/1394022 Title: v2.1 api sample tests taking a long time to run Status in OpenStack Compute (Nova): New Bug description: There have been reports that the api sample tests for v2.1 are taking significantly longer to run that the v2 versions. This needs to be investigated and fixed. Eg. is it setup time (stevedore?), is it jsonschema input validation? Or something else To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1394022/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1381061] Re: VMware: ESX hosts must not be externally routable
** Changed in: nova Status: New = Confirmed ** Also affects: openstack-manuals 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/1381061 Title: VMware: ESX hosts must not be externally routable Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Manuals: New Bug description: Change I70fd7d3ee06040d6ce49d93a4becd9cbfdd71f78 removed passwords from VNC hosts. This change is fine because we proxy the VNC connection and do access control at the proxy, but it assumes that ESX hosts are not externally routable. In a non-OpenStack VMware deployment, accessing a VM's console requires the end user to have a direct connection to an ESX host. This leads me to believe that many VMware administrators may leave ESX hosts externally routable if not specifically directed otherwise. The above change makes a design decision which requires ESX hosts not to be externally routable. There may also be other reasons. We need to ensure that this is very clearly documented. This may already be documented, btw, but I don't know how our documentation is organised, and would prefer that somebody more familiar with it assures themselves that this has been given appropriate weight. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1381061/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1375564] Re: unable to delete correct security rules
This is already implemented in Juno as secgroup-delete-group-rule ** 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/1375564 Title: unable to delete correct security rules Status in OpenStack Compute (Nova): Invalid Bug description: Description: == Version: Icehouse/stable Try to add a security group rule, like: stack@ThinkCentre:~$ nova secgroup-add-group-rule default default tcp 121 121 +-+---+-+--+--+ | IP Protocol | From Port | To Port | IP Range | Source Group | +-+---+-+--+--+ | tcp | 121 | 121 | | default | +-+---+-+--+--+ = Now try to delete that group rule : stack@ThinkCentre:~$ nova secgroup-delete-group-rule default default tcp 121 121 ERROR (AttributeError): 'NoneType' object has no attribute 'upper' Now try to add invalid group rule : stack@tcs-ThinkCentre:~$ nova secgroup-add-group-rule default default tcp -1 -1 ERROR (BadRequest): Invalid port range -1:-1. Valid TCP ports should be between 1-65535 (HTTP 400) (Request-ID: req-4fb01dfe-c0f6-4309-87fb-e61777e980e2) = Now try to add group rule of icmp protocol : stack@ThinkCentre:~$ nova secgroup-add-group-rule default default icmp -1 -1 +-+---+-+--+--+ | IP Protocol | From Port | To Port | IP Range | Source Group | +-+---+-+--+--+ | icmp| -1| -1 | | default | +-+---+-+--+--+ this group rule is added because port range define as( -1 to 255) for icmp. === Now try to add one more group rule as : stack@ThinkCentre:~$ nova secgroup-add-group-rule default default icmp -2 -2 ERROR (BadRequest): Invalid port range -2:-2. For ICMP, the type:code must be valid (HTTP 400) (Request-ID: req-24432ef8-ef05-4d6c-bbfd-8c2d199340e0) == Now check the group rule list: stack@ThinkCentre-M91P:~$ nova secgroup-list-rules default +-+---+-+--+--+ | IP Protocol | From Port | To Port | IP Range | Source Group | +-+---+-+--+--+ | | tcp | 12| 12 | | default | || | | | default | || | | | default | | icmp | -1 | -1 | | default | || | | | | +-+---+-+--+--+ = Actual results: Only valid rules can be created but not able to delete them. Expected results: There should be a way to delete them. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1375564/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 940430] Re: nova-api should check UTF8 char in parameters
This doesn't appear to be reproducible anymore and we now handle utf8
host names correctly
** Changed in: nova
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/940430
Title:
nova-api should check UTF8 char in parameters
Status in OpenStack Compute (Nova):
Invalid
Bug description:
I got following error.
root@localhost:~# nova --debug list
connect: (keystone.thefreecloud.org, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
keystone.thefreecloud.org:5000\r\nContent-Length: 108\r\ncontent-type:
application/json\r\naccept-encoding: gzip, deflate\r\nuser-agent:
python-novaclient\r\n\r\n{auth: {tenantName: admin,
passwordCredentials: {username: admin, password: X}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json; charset=UTF-8
header: Content-Length: 1148
header: Date: Fri, 24 Feb 2012 16:13:00 GMT
connect: (nova-api.thefreecloud.org, 8774)
send: u'GET /v1.1/1/servers/detail HTTP/1.1\r\nHost:
nova-api.thefreecloud.org:8774\r\nx-auth-project-id: admin\r\nx-auth-token:
XX g\r\naccept-encoding: gzip, deflate\r\nuser-agent:
python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 500 Internal Server Error\r\n'
header: Content-Length: 133
header: Content-Type: application/json; charset=UTF-8
header: Date: Fri, 24 Feb 2012 16:13:00 GMT
Traceback (most recent call last):
File /usr/local/bin/nova, line 9, in module
load_entry_point('python-novaclient==2012.1', 'console_scripts', 'nova')()
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 338, in
main
OpenStackComputeShell().main(sys.argv[1:])
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 289, in
main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py, line 480,
in do_list
utils.print_list(cs.servers.list(search_opts=search_opts), columns,
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/servers.py, line
247, in list
return self._list(/servers%s%s % (detail, query_string), servers)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 69, in
_list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 130, in
get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 118, in
_cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 101, in
request
raise exceptions.from_response(resp, body)
novaclient.exceptions.ClientException: The server has either erred or is
incapable of performing the requested operation. (HTTP 500)
I got error
byte 0xe7 in position 8: unexpected end of data
(nova.api.openstack): TRACE: Traceback (most recent call last):
(nova.api.openstack): TRACE: File
/opt/stack/nova/nova/api/openstack/__init__.py, line 64, in __call__
(nova.api.openstack): TRACE: return req.get_response(self.application)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/request.py, line 1053, in get_response
(nova.api.openstack): TRACE: application, catch_exc_info=False)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/request.py, line 1022, in call_application
(nova.api.openstack): TRACE: app_iter = application(self.environ,
start_response)
(nova.api.openstack): TRACE: File
/usr/lib/python2.7/dist-packages/keystone/middleware/auth_token.py, line 212,
in __call__
(nova.api.openstack): TRACE: return self._forward_request(env,
start_response, proxy_headers)
(nova.api.openstack): TRACE: File
/usr/lib/python2.7/dist-packages/keystone/middleware/auth_token.py, line 344,
in _forward_request
(nova.api.openstack): TRACE: return self.app(env, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/dec.py, line 159, in __call__
(nova.api.openstack): TRACE: return resp(environ, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/dec.py, line 159, in __call__
(nova.api.openstack): TRACE: return resp(environ, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/dec.py, line 159, in __call__
(nova.api.openstack): TRACE: return resp(environ, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/routes/middleware.py, line 131, in __call__
(nova.api.openstack): TRACE: response = self.app(environ, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/dec.py, line 159, in __call__
(nova.api.openstack): TRACE: return resp(environ, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/dec.py, line 159, in
[Yahoo-eng-team] [Bug 1212195] Re: Flavor Extra Specs should check Metadata Items Quota
It's an admin api so I don't think we need to quota restrict it. ** Changed in: nova Status: Triaged = 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/1212195 Title: Flavor Extra Specs should check Metadata Items Quota Status in OpenStack Compute (Nova): Won't Fix Bug description: The flavor extra specs extension does not actually adhere to any quota restrictions during create. The API handles the MetadataLimitExceeded exception (see https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/flavorextraspecs.py#L76) , but it looks like this exception would never get raised. By default the Metadata Items quota for a tenant is 128. With the current code, more than 128 flavor extra spec items can be created. Either of the two should be done: 1. Enforce the metadata limit (use _check_metadata_properties_quota() just as used in instance metadata) , Or, 2. If this limit should not be enforced, then the exception handling code should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1212195/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1365259] Re: Lack of failure information (Failure due to host key verification failure)displayed, during instance migration from one host to another
As mentioned above, this is an async call so we have already returned from the API before we know the migration failed. The tasks API will address this in the future (you'll need to poll but you will be able to find out what happened). ** Changed in: nova Status: Confirmed = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1365259 Title: Lack of failure information (Failure due to host key verification failure)displayed, during instance migration from one host to another Status in OpenStack Compute (Nova): Invalid Bug description: I am using (1 controller + compute1 + compute 2) openstack environment. During live migrate server from one compute host to another using CLI - If migration is failed due to host key verification failure from one compute host to another, then failure information should be as a output to console. otherwise user will not be able to know what is happening. For user, migration is successful but actually it is failed. Set of operation is as - 1. root@nechldcst-PowerEdge-2950:# nova list +--+-+++-+---+ | ID | Name| Status | Task State | Power State | Networks | +--+-+++-+---+ | 1aea212b-0bee-498b-a10d-5b58a69e3293 | test-server | ACTIVE | - | Running | demo-net=203.0.113.26 | +--+-+++-+---+ 2. root@nechldcst-PowerEdge-2950:# nova migrate 1aea212b-0bee-498b-a10d-5b58a69e3293 root@nechldcst-PowerEdge-2950:# At this point user thinks that migration is successful but see below - 3. root@nechldcst-PowerEdge-2950:# nova list +--+-+++-+---+ | ID | Name| Status | Task State | Power State | Networks | +--+-+++-+---+ | 1aea212b-0bee-498b-a10d-5b58a69e3293 | test-server | ERROR | - | Running | demo-net=203.0.113.26 | +--+-+++-+---+ 4. root@nechldcst-PowerEdge-2950:# nova show 1aea212b-0bee-498b-a10d-5b58a69e3293 +--+---+ | Property | Value | +--+---+ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | compute2 | | OS-EXT-SRV-ATTR:hypervisor_hostname | compute2 | | OS-EXT-SRV-ATTR:instance_name| instance-0003 | | OS-EXT-STS:power_state | 1 | | OS-EXT-STS:task_state| - | | OS-EXT-STS:vm_state | error | | OS-SRV-USG:launched_at | 2014-09-04T03:41:08.00 | | OS-SRV-USG:terminated_at | -
[Yahoo-eng-team] [Bug 1208743] Re: network uuid hasn't been checked in create server
** Changed in: nova
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1208743
Title:
network uuid hasn't been checked in create server
Status in OpenStack Compute (Nova):
Invalid
Bug description:
when I port a negative tempest tests into v3, this test cann't pass
but it can pass when use nova v2 api. I think there is no validation
for networks.
@attr(type=['negative', 'gate'])
def test_create_with_invalid_network_uuid(self):
# Pass invalid network uuid while creating a server
networks = [{'fixed_ip': '10.0.1.1', 'uuid':
'a-b-c-d-e-f-g-h-i-j'}]
self.assertRaises(exceptions.BadRequest,
self.create_server,
networks=networks)
The following is the log:
==
FAIL:
tempest.api.compute.servers.v3.test_servers_negative.ServersNegativeV3TestJSON.test_create_with_invalid_network_uuid[gate,negative]
--
_StringException: Traceback (most recent call last):
File
/opt/stack/tempest/tempest/api/compute/servers/v3/test_servers_negative.py,
line 153, in test_create_with_invalid_network_uuid
networks=networks)
File
/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py,
line 394, in assertRaises
self.assertThat(our_callable, matcher)
File
/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py,
line 417, in assertThat
raise MismatchError(matchee, matcher, mismatch, verbose)
MismatchError: bound method type.create_server of class
'tempest.api.compute.servers.v3.test_servers_negative.ServersNegativeV3TestJSON'
returned ({'status': '202', 'content-length': '345', 'x-compute-request-id':
'req-0d34c7cf-5047-4c75-848b-d30df693ead6', 'location':
'http://192.168.1.101:8774/v3/servers/d91862ce-d80d-44d0-957c-8b28370dd460',
'date': 'Tue, 06 Aug 2013 09:03:28 GMT', 'content-type': 'application/json'},
{u'links': [{u'href':
u'http://192.168.1.101:8774/v3/servers/d91862ce-d80d-44d0-957c-8b28370dd460',
u'rel': u'self'}, {u'href':
u'http://192.168.1.101:8774/servers/d91862ce-d80d-44d0-957c-8b28370dd460',
u'rel': u'bookmark'}], u'id': u'd91862ce-d80d-44d0-957c-8b28370dd460',
u'security_groups': [{u'name': u'default'}], u'adminPass': u'r8vSmWK5W8rC'})
begin captured logging
tempest.common.rest_client: INFO: Request: POST
http://192.168.1.101:8774/v3/servers
tempest.common.rest_client: DEBUG: Request Headers: {'Content-Type':
'application/json', 'Accept': 'application/json', 'X-Auth-Token': 'Token
omitted'}
tempest.common.rest_client: DEBUG: Request Body: {server: {flavorRef: 42,
name: ServersNegativeV3TestJSON-instance1742202142, imageRef:
cade0819-2939-484b-a52f-600d039aefc1, networks: [{fixed_ip: 10.0.1.1,
uuid: a-b-c-d-e-f-g-h-i-j}]}}
tempest.common.rest_client: INFO: Response Status: 202
tempest.common.rest_client: DEBUG: Response Headers: {'content-length':
'345', 'location':
'http://192.168.1.101:8774/v3/servers/d91862ce-d80d-44d0-957c-8b28370dd460',
'date': 'Tue, 06 Aug 2013 09:03:28 GMT', 'x-compute-request-id':
'req-0d34c7cf-5047-4c75-848b-d30df693ead6', 'content-type': 'application/json'}
tempest.common.rest_client: DEBUG: Response Body: {server:
{security_groups: [{name: default}], id:
d91862ce-d80d-44d0-957c-8b28370dd460, links: [{href:
http://192.168.1.101:8774/v3/servers/d91862ce-d80d-44d0-957c-8b28370dd460;,
rel: self}, {href:
http://192.168.1.101:8774/servers/d91862ce-d80d-44d0-957c-8b28370dd460;,
rel: bookmark}], adminPass: r8vSmWK5W8rC}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1208743/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1370954] [NEW] glance 500's when passed image name with a 4-byte utf-8 character
Public bug reported:
Glance currently 500's when passed an image name with a 4-byte utf-8
character in the name. This is because the mysql utf-8 type only handles
up to 3-byte utf-8 characters:
See http://stackoverflow.com/questions/10957238/incorrect-string-value-
when-trying-to-insert-utf-8-into-mysql-via-jdbc
You can replicate this by using the tempest test:
test_create_image_specify_multibyte_character_image_name (the positive not
negative one)
You'll need to change utf8_name to
utf8_name = data_utils.rand_name('\xF0\x9F\x92\xA9')
(note removal of unicode prefix)
Backtrace from nova request to glance that triggers this:
2014-09-18 07:35:47.343 843 DEBUG routes.middleware
[797abe72-9a70-488e-9254-c71888536278 a2bb050fa6e647398991ebc635741cb1
33760203c2944644
a9ee2a0433f45d0b - - -] Route path: '/images', defaults: {'action': u'create',
'controller': glance.common.wsgi.Resource object at 0x7f90c
47a6d10} __call__
/usr/local/lib/python2.7/dist-packages/routes/middleware.py:102
2014-09-18 07:35:47.343 843 DEBUG routes.middleware
[797abe72-9a70-488e-9254-c71888536278 a2bb050fa6e647398991ebc635741cb1
33760203c2944644
a9ee2a0433f45d0b - - -] Match dict: {'action': u'create', 'controller':
glance.common.wsgi.Resource object at 0x7f90c47a6d10} __call__ /u
sr/local/lib/python2.7/dist-packages/routes/middleware.py:103
2014-09-18 07:35:47.348 843 ERROR glance.registry.api.v1.images
[797abe72-9a70-488e-9254-c71888536278 a2bb050fa6e647398991ebc635741cb1 3376
0203c2944644a9ee2a0433f45d0b - - -] Unable to create image None
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images Traceback (most
recent call last):
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/opt/stack/glance/glance/registry/api/v1/images.py, line 424, in c
reate
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images image_data
= self.db_api.image_create(req.context, image_data)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/opt/stack/glance/glance/db/sqlalchemy/api.py, line 124, in image_
create
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images return
_image_update(context, values, None, purge_props=False)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/local/lib/python2.7/dist-packages/retrying.py, line 92, in wr
apped_f
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images return
Retrying(*dargs, **dkw).call(f, *args, **kw)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/local/lib/python2.7/dist-packages/retrying.py, line 239, in c
all
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images return
attempt.get(self._wrap_exception)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
reraise(self.value[0], self.value[1], self.value[2])
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/local/lib/python2.7/dist-packages/retrying.py, line 233, in call
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images attempt =
Attempt(fn(*args, **kwargs), attempt_number, False)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/opt/stack/glance/glance/db/sqlalchemy/api.py, line 759, in _image_update
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
image_ref.save(session=session)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/opt/stack/glance/glance/db/sqlalchemy/models.py, line 77, in save
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
super(GlanceBase, self).save(session or db_api.get_session())
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/local/lib/python2.7/dist-packages/oslo/db/sqlalchemy/models.py, line 48,
in save
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
session.flush()
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1818, in
flush
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
self._flush(objects)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1936, in
_flush
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
transaction.rollback(_capture_exception=True)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py, line 58, in
__exit__
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
compat.reraise(exc_type, exc_value, exc_tb)
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1900, in
_flush
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images
flush_context.execute()
2014-09-18 07:35:47.348 843 TRACE glance.registry.api.v1.images File
[Yahoo-eng-team] [Bug 1006725] Re: Nova allows creating an Image name with invalid utf8 (thus breaking tools further down the pipeline)
It turns out that both the JSON and XML deserializers in nova will
detect invalid utf8 sequences so this bug is invalid. The only issue is
on the tempest test side
** Changed in: nova
Status: In Progress = 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/1006725
Title:
Nova allows creating an Image name with invalid utf8 (thus breaking
tools further down the pipeline)
Status in OpenStack Compute (Nova):
Invalid
Status in Tempest:
Fix Released
Bug description:
Our tempest tests that checks for 400 Bad Request return code fails
with a ComputeFault instead.
Pass multi-byte character image name during Create Image
Actual Response Code: ComputeFault, 500
Expected Response Code: 400 Bad Request
Return an error if the server name has a multi-byte character ... FAIL
==
FAIL: Return an error if the server name has a multi-byte character
--
Traceback (most recent call last):
File /opt/stack/tempest/tests/test_images.py, line 251, in
test_create_image_specify_multibyte_character_server_name
self.fail(Should return 400 Bad Request if multi byte characters
AssertionError: Should return 400 Bad Request if multi byte characters are
used for image name
begin captured logging
tempest.config: INFO: Using tempest config file
/opt/stack/tempest/etc/tempest.conf
tempest.common.rest_client: ERROR: Request URL:
http://10.2.3.164:8774/v2/1aeac1cfbfdd43c2845b2cb3a4f15790/images/24ceff93-1af3-41ab-802f-9fc4d8b90b69
tempest.common.rest_client: ERROR: Request Body: None
tempest.common.rest_client: ERROR: Response Headers: {'date': 'Thu, 31 May
2012 06:02:33 GMT', 'status': '404', 'content-length': '62', 'content-type':
'application/json; charset=UTF-8', 'x-compute-request-id':
'req-7a15d284-e934-47a1-87f4-7746e949c7a2'}
tempest.common.rest_client: ERROR: Response Body: {itemNotFound:
{message: Image not found., code: 404}}
tempest.common.rest_client: ERROR: Request URL:
http://10.2.3.164:8774/v2/1aeac1cfbfdd43c2845b2cb3a4f15790/servers/ecb51dfb-493d-4ef8-9178-1adc3d96a04d/action
tempest.common.rest_client: ERROR: Request Body: {createImage: {name:
\ufeff43802479847}}
tempest.common.rest_client: ERROR: Response Headers: {'date': 'Thu, 31 May
2012 06:02:44 GMT', 'status': '500', 'content-length': '128', 'content-type':
'application/json; charset=UTF-8', 'x-compute-request-id':
'req-1a9505f5-4dfc-44e7-b04a-f8daec0f956e'}
tempest.common.rest_client: ERROR: Response Body: {u'computeFault':
{u'message': u'The server has either erred or is incapable of performing the
requested operation.', u'code': 500}}
- end captured logging -
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1006725/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1333471] Re: Checking security group in nova immediately after instance is created results in error
Backport patch for this was merged actually merged afew days ago. https://review.openstack.org/#/c/106674/ Sorry should have linked to it earlier. ** Changed in: nova Status: Won't Fix = 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/1333471 Title: Checking security group in nova immediately after instance is created results in error Status in OpenStack Compute (Nova): Fix Committed Bug description: Environment: Openstack Havana with Neutron for networking and security groups Error: Response from nova: The server could not comply with the request since it is either malformed or otherwise incorrect., code: 400 In nova-api log 014-06-19 00:48:39.483 17462 ERROR nova.api.openstack.wsgi [req-60aa8941-d129-4018-a30f-f815f0770118 10764ccc2d154d0a919f5104872fb9a8 2b60ae3ba5bd41d893674d0e57ae4390] Exception handling resource: 'NoneType' object is not iterable 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi Traceback (most recent call last): 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi File /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 997, in _process_stack 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi action_result = self.dispatch(meth, request, action_args) 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi File /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 1078, in dispatch 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi return method(req=request, **action_args) 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi File /usr/lib/python2.7/dist-packages/nova/api/openstack/compute/contrib/security_groups.py, line 438, in index 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi for group in groups] 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi TypeError: 'NoneType' object is not iterable 2014-06-19 00:48:39.483 17462 TRACE nova.api.openstack.wsgi 2014-06-19 00:48:39.485 17462 INFO nova.osapi_compute.wsgi.server [req-60aa8941-d129-4018-a30f-f815f0770118 10764ccc2d154d0a919f5104872fb9a8 2b60ae3ba5bd41d893674d0e57ae4390] 10.147.22.73,54.225.248.128 GET /v2/2b60ae3ba5bd41d893674d0e57ae4390/servers/c7e5f472-57fb-4a95-95cf-45c6506db0cd/os-security-groups HTTP/1.1 status: 400 len: 362 time: 0.0710380 Steps to reproduce: 1) Create new instance 2) Immediately check security group through nova (/v2/$tenant/servers/$server_id/os-security-groups 3) Wait several seconds and try again (Works if given a small delay between instance creation and checking sec group) Notes: This error did not come up in earlier versions of havana, but started after a recent upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1333471/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 977192] Re: Error message not user friendly while creating security group
This is a novaclient bug not a nova bug (it never reaches Nova). But regardless I'm not convinced we should fix this. Its stock standard unix command line syntax that something starting with '-' would be interpreted as an option rather than an argument unless specially quoted. ** Also affects: python-novaclient Importance: Undecided Status: New ** Changed in: python-novaclient Status: New = Confirmed ** Changed in: python-novaclient Importance: Undecided = Wishlist ** Changed in: nova Status: Confirmed = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/977192 Title: Error message not user friendly while creating security group Status in OpenStack Compute (Nova): Invalid Status in Python client library for Nova: Confirmed Bug description: While creating Security Group with a name which starts with '-' followed by an alphabet then the Error message is not user friendly Steps to reproduce: nova secgroup-create -A34f ghjk Expected Result: Error message which indicates name is not an appropriate name Actual Result: usage: nova secgroup-create name description error: too few arguments To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/977192/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1369358] [NEW] Improve secgroup create error message
Public bug reported: When secgroup-create is passed a name or description which is an empty string the error message does not specify which field is invalid. We should fix this. ** Affects: nova Importance: Undecided Assignee: Christopher Yeoh (cyeoh-0) Status: In Progress -- 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/1369358 Title: Improve secgroup create error message Status in OpenStack Compute (Nova): In Progress Bug description: When secgroup-create is passed a name or description which is an empty string the error message does not specify which field is invalid. We should fix this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369358/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1367132] [NEW] quota delete api should do better input validation
Public bug reported: The quota delete rest api should have better input validation as bad input data can currently silently fail ** Affects: nova Importance: Undecided Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1367132 Title: quota delete api should do better input validation Status in OpenStack Compute (Nova): New Bug description: The quota delete rest api should have better input validation as bad input data can currently silently fail To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1367132/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1064854] Re: nova should have a option to reset(or delete) the user quota to default
Agreed, looks like this is already implemented ** Changed in: nova Status: New = Fix Released ** Changed in: python-novaclient Status: New = 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/1064854 Title: nova should have a option to reset(or delete) the user quota to default Status in OpenStack Compute (Nova): Fix Released Status in Python client library for Nova: Fix Released Bug description: At present nova client has following commands for the quota operation. $nova --help | grep quota quota-defaults List the default quotas for a tenant. quota-show List the quotas for a tenant. quota-updateUpdate the quotas for a tenant. It will be very helpful to have a command to reset(or delete) quota values to defaults . For ex: User who wants to do huge tests on the system and rollback once the test is done. So a new command quota-reset need to be added to the nova client which reverts the quota value supplied for the tenant ,to the default. Something similar to nova quota-reset( tenant-id key) we can use nova quota-defaults to list the default quotas then use the quota-update to update the quota's to default, but the problem with this approach is that if you then change the default quotas, they are not reflected for the tenant. similar discussion I have started here :https://lists.launchpad.net/openstack/msg17306.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1064854/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1352950] Re: os-interface create API docs are wrong
** 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/1352950 Title: os-interface create API docs are wrong Status in OpenStack API documentation site: Confirmed Bug description: Was looking at bug 1338551 and the API docs for the attach_interface create method: http://docs.openstack.org/api/openstack-compute/2/content/POST_os- interface- v2_createAttachInterface__v2__tenant_id__servers__server_id__os- interface_ext-os-interface.html The API docs say that port_id is required in the request but it's actually optional: http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/contrib/attach_interfaces.py#n80 You can send in port_id/net_id/fixed_ips, net_id and port_id are mutually exclusive, and requesting a specific fixed_ip without a net_id is a 400 BadRequest also. If the port_id isn't provided, the network API will allocate one on the given network. If net_id isn't provided, the network associated with the instance in the network info cache will be used. The API docs also don't list any error codes, of which there are 400, 404, 409, 500, and 501 (because nova-network doesn't implement this API). To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-api-site/+bug/1352950/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1352186] [NEW] Uncaught exception resize api
, context, instance, *args, **kwargs) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/compute/api.py, line 215, in _wrapped 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return fn(self, context, instance, *args, **kwargs) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/compute/api.py, line 169, in inner 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return f(self, context, instance, *args, **kw) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/compute/api.py, line 2333, in resize 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack resource=resource) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack TooManyInstances: Quota exceeded for ram: Requested 51137, but already used 128 of 51200 ram 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack ** Affects: nova Importance: Low Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1352186 Title: Uncaught exception resize api Status in OpenStack Compute (Nova): New Bug description: [req-b445d808-9bd4-4573-824b-d5b00bbb09fd ServersAdminTestJSON630630154-user ServersAdminTestJSON630630154-tenant] Caught error: Quota exceeded for ram: Requested 51137, but already used 128 of 51200 ram 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack Traceback (most recent call last): 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/__init__.py, line 119, in __call__ 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return req.get_response(self.application) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1296, in send 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack application, catch_exc_info=False) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1260, in call_application 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return resp(environ, start_response) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 663, in __call__ 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return self.app(env, start_response) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /usr/lib/python2.7/dist-packages/routes/middleware.py, line 131, in __call__ 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack response = self.app(environ, start_response) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/wsgi.py, line 938, in __call__ 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack content_type, body, accept) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/wsgi.py, line 997, in _process_stack 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack action_result = self.dispatch(meth, request, action_args) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/wsgi.py, line 1078, in dispatch 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return method(req=request, **action_args) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/compute/servers.py, line 1248, in _action_resize 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack return self._resize(req, id, flavor_ref, **kwargs) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/compute/servers.py, line 1113, in _resize 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack self.compute_api.resize(context, instance, flavor_id, **kwargs) 2014-08-04 05:27:04.305 12275 TRACE nova.api.openstack File /opt/stack/new/nova/nova/compute/api.py, line 198
[Yahoo-eng-team] [Bug 1352659] [NEW] race in server show api
Public bug reported: Because of the instance object lazy loading its possible to get into situations where the API code is half way through assembling data to return to the client when the instance disappears underneath it. We really need to ensure everything we will need is retreived up front so we have a consistent snapshot view of the instance [req-5ca39eb3-c1d2-433b-8dac-1bf5f338ce1f ServersAdminNegativeV3Test-1453501114 ServersAdminNegativeV3Test-364813115] Unexpected exception in API method 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions Traceback (most recent call last): 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/api/openstack/extensions.py, line 473, in wrapped 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions return f(*args, **kwargs) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/api/openstack/compute/plugins/v3/servers.py, line 410, in show 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions return self._view_builder.show(req, instance) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/api/openstack/compute/views/servers.py, line 268, in show 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions _inst_fault = self._get_fault(request, instance) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/api/openstack/compute/views/servers.py, line 214, in _get_fault 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions fault = instance.fault 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/objects/base.py, line 67, in getter 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions self.obj_load_attr(name) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/objects/instance.py, line 520, in obj_load_attr 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions expected_attrs=[attrname]) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/objects/base.py, line 153, in wrapper 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions result = fn(cls, context, *args, **kwargs) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/objects/instance.py, line 310, in get_by_uuid 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions use_slave=use_slave) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/db/api.py, line 676, in instance_get_by_uuid 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions columns_to_join, use_slave=use_slave) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/db/sqlalchemy/api.py, line 167, in wrapper 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/db/sqlalchemy/api.py, line 1715, in instance_get_by_uuid 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions columns_to_join=columns_to_join, use_slave=use_slave) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions File /opt/stack/new/nova/nova/db/sqlalchemy/api.py, line 1727, in _instance_get_by_uuid 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions raise exception.InstanceNotFound(instance_id=uuid) 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions InstanceNotFound: Instance fcff276a-d410-4760-9b98-4014024b1353 could not be found. 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions http://logs.openstack.org/periodic-qa/periodic-tempest-dsvm- nova-v3-full-master/a278802/logs/screen-n-api.txt ** Affects: nova Importance: Medium Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1352659 Title: race in server show api Status in OpenStack Compute (Nova): New Bug description: Because of the instance object lazy loading its possible to get into situations where the API code is half way through assembling data to return to the client when the instance disappears underneath it. We really need to ensure everything we will need is retreived up front so we have a consistent snapshot view of the instance [req-5ca39eb3-c1d2-433b-8dac-1bf5f338ce1f ServersAdminNegativeV3Test-1453501114 ServersAdminNegativeV3Test-364813115] Unexpected exception in API method 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions Traceback (most recent call last): 2014-08-04 06:37:25.738 21228 TRACE nova.api.openstack.extensions
[Yahoo-eng-team] [Bug 1352141] [NEW] uncaught exception in floating ip creation when pool is not found with neutron backend
Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1352141 Title: uncaught exception in floating ip creation when pool is not found with neutron backend Status in OpenStack Compute (Nova): New Bug description: 2014-07-31 07:14:07.574 ERROR nova.api.openstack [req-98b42d5d-575f-4209-b711-4cb2ae8ef14e FloatingIPsNegativeTestXML-1138647745 FloatingIPsNegativeTestXML-1764448859] Caught error: Floating ip pool not found. 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack Traceback (most recent call last): 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/__init__.py, line 125, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return req.get_response(self.application) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1320, in send 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack application, catch_exc_info=False) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/request.py, line 1284, in call_application 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack app_iter = application(self.environ, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return resp(environ, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/python-keystoneclient/keystoneclient/middleware/auth_token.py, line 663, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return self.app(env, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return resp(environ, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return resp(environ, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/lib/python2.7/dist-packages/routes/middleware.py, line 131, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack response = self.app(environ, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return resp(environ, start_response) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack resp = self.call_func(req, *args, **self.kwargs) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /usr/local/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return self.func(req, *args, **kwargs) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/wsgi.py, line 917, in __call__ 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack content_type, body, accept) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/wsgi.py, line 983, in _process_stack 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack action_result = self.dispatch(meth, request, action_args) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/wsgi.py, line 1070, in dispatch 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack return method(req=request, **action_args) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/api/openstack/compute/contrib/floating_ips.py, line 158, in create 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack address = self.network_api.allocate_floating_ip(context, pool) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/network/neutronv2/api.py, line 927, in allocate_floating_ip 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/network/neutronv2/api.py, line 927, in allocate_floating_ip 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack pool_id = self._get_floating_ip_pool_id_by_name_or_id(client, pool) 2014-07-31 07:14:07.574 28614 TRACE nova.api.openstack File /opt/stack/new/nova/nova/network/neutronv2/api.py, line
[Yahoo-eng-team] [Bug 1334297] Re: Strange response from os-server-groups with bad parameter
So in the end I don't think this is a Nova bug. The first line of the
request to the Nova API server looks like this:
DELETE /v2/f9cea8784d7245e5a8022a259bb92d90/os-server-
groups/{u'policies': [u'affinity'], u'name': u'server-group-1646113520',
u'id': u'b5316a4a-f6eb-4a7f-8b24-028b799bf6a9', u'members': [],
u'metadata': {}} HTTP/1.1
Which is not a valid header. It is so badly formatted that I believe a
reasonable parser implementation could not necessarily know that the
client is requesting a response in HTTP/1.1 format as the uri is so
corrupt. Looking from the end it can be clearly seen, but the request is
definitely corrupt. BaseHTTPServer by default responds in HTTP/0.9
protocol if its not sure.
So it does return a 400, but in HTTP/0.9 protocol:
titleError response/title
/head
body
h1Error response/h1
pError code 400.
pMessage: Bad request syntax (DELETE
/v2/f9cea8784d7245e5a8022a259bb92d90/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1646113520', u'id':
u'b5316a4a-f6eb-4a7f-8b24-028b799bf6a9', u'members': [], u'metadata': {}}
HTTP/1.1).
pError code explanation: 400 = Bad request syntax or unsupported method.
/body
httplib2 on the tempest side made the request in HTTP/1.1 protocol, but
does not appear to try to parse it in HTTP/0.9 format if it doesn't get
an HTTP/1.1 header. According to RFC 1945 it should be able to do so. So
technically its a tempest bug. Not sure if its worth fixing though
** Also affects: tempest
Importance: Undecided
Status: New
** Changed in: tempest
Importance: Undecided = Low
** Changed in: nova
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1334297
Title:
Strange response from os-server-groups with bad parameter
Status in OpenStack Compute (Nova):
Invalid
Status in Tempest:
New
Bug description:
There was a bug in tempest that caused a call to DELETE os-server-
groups with a bad id. Here is the call from the tempest log:
2014-06-25 12:07:03.162 25653 INFO tempest.common.rest_client [-]
Request (ServerGroupTestJSON:tearDownClass): 200 DELETE
http://127.0.0.1:8774/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-
groups/{u'policies': [u'affinity'], u'name': u'server-
group-1944635656', u'id': u'7c6a13c1-6d8b-4314-9d16-4eb6418a2170',
u'members': [], u'metadata': {}} 0.001s
Normally DELETE will return 204 and in this case I would have expected
400. But the call returns 200. What can be seen in the nova log seems
to indicate 400 but that is not what is actually getting sent back:
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1944635656', u'id':
u'7c6a13c1-6d8b-4314-9d16-4eb6418a2170', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1944635656', u'id':
u'7c6a13c1-6d8b-4314-9d16-4eb6418a2170', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'd361d100-fc59-4393-b61b-30a2d4b27b6e', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'd361d100-fc59-4393-b61b-30a2d4b27b6e', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'9f8574d7-78b9-4926-98ea-61f2da971478', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'9f8574d7-78b9-4926-98ea-61f2da971478', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-2072440191', u'id':
u'01342594-9661-47fb-8816-e816ad2cae37', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-2072440191', u'id':
u'01342594-9661-47fb-8816-e816ad2cae37', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03]
[Yahoo-eng-team] [Bug 1334903] [NEW] Should use 403 status code instead of 413 when out of quota
Public bug reported: We should fix the remaining API cases where the 413 status code is used instead of 403 when the failure is due to running out of quota ** Affects: nova Importance: Low Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1334903 Title: Should use 403 status code instead of 413 when out of quota Status in OpenStack Compute (Nova): New Bug description: We should fix the remaining API cases where the 413 status code is used instead of 403 when the failure is due to running out of quota To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334903/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1234418] Re: nova resize return 202 and host left in ERROR state
The resize call is asynchronous - eg the API returns the 202 to the client possibly before the actual resize attempt is made. 202 just means that the request has been accepted, not that it has been accepted. In order to determine if the resize has succeded you need to poll ** 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/1234418 Title: nova resize return 202 and host left in ERROR state Status in OpenStack Compute (Nova): Invalid Bug description: The nova resize return 202, but leave the host in ERROR state. The new size is within the quota. Steps to reproduce: 1. create a node with m1.tiny flavor using nova boot. 2. wait for the state to change as ACTIVE 3. resize the node to m1.small flavor. Obtained result: The resize is successful. 202 code is returned. The state is set as ERROR. This cause the following tempest tests fail. The tests attempt to resize the host beyond the quota and expect OverLimit exception. Since the API return 202 status, the tests fail. test_resize_server_using_overlimit_ram test_resize_server_using_overlimit_vcpus Refer to the debug output for details: http://pastebin.com/XD3ZbEL5 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1234418/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1281014] Re: unfriendly user experience if no valid host selected in nova scheduler
The resize call (and many others) are asynchronous. 202 just means that the request has been accepted, not that it has succeeded. The API returns to the client before the resize is attempted - it doesn't know if it is going to succeed or not. In order to determine if the resize succeeded you need to poll - either through the instance actions interface or with the upcoming tasks api ** Changed in: nova Status: In Progress = 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/1281014 Title: unfriendly user experience if no valid host selected in nova scheduler Status in OpenStack Compute (Nova): Invalid Bug description: nova version: 2.15.0 If no enough resource available on any computer node, command like 'nova resize instancevm 100' will exit silently with no enough error or warning message. Users can be confused, not knowing what's wrong and what to do next. Although, there is warning message in /var/log/conductor.log as follows, not much user can find it easily: 2014-02-17 03:43:29.000 6320 WARNING nova.scheduler.utils [req-c0d5f130-c5a9-41b7-8fe4-4d08be4cc774 9ed1534f040c43e98293f6bc6b632e96 bd5848810607480d968b6d1ca9a36637] Failed to compute_task_migrate_server: No valid host was found. Traceback (most recent call last): File /usr/lib/python2.6/site-packages/nova/openstack/common/rpc/common.py, line 420, in catch_client_exception return func(*args, **kwargs) File /usr/lib/python2.6/site-packages/nova/scheduler/manager.py, line 298, in select_destinations filter_properties) File /usr/lib/python2.6/site-packages/nova/scheduler/filter_scheduler.py, line 148, in select_destinations raise exception.NoValidHost(reason='') NoValidHost: No valid host was found. It's better to report some error or warning message if such situation happens. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1281014/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1283214] Re: Need documentation of fix to bug 1203680
I don't see how this is a Nova bug? ** 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/1283214 Title: Need documentation of fix to bug 1203680 Status in devstack - openstack dev environments: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): Invalid Bug description: The fix to https://bugs.launchpad.net/devstack/+bug/1203680 is useless unless people know to set the new variable when doing a DevStack install. The DevStack documentation should be updated to mention this, as should the various places that describe how to do unit testing. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1283214/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 918238] Re: wrong error message of nova-api after failing to login to rabbitmq-server
Sorry doesn't appear to be fixable atm
** Changed in: nova
Status: Confirmed = 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/918238
Title:
wrong error message of nova-api after failing to login to rabbitmq-
server
Status in OpenStack Compute (Nova):
Won't Fix
Bug description:
the rabbitmq-server is not unreachable. the error message is wrong, it
should be login failed or something like that.
log if nova-api:
2012-01-18 14:55:29,625 ERROR nova.rpc [-] AMQP server on
192.168.53.132:5672 is unreachable: Socket closed. Trying again in 1
seconds.
log of rabbitmq-server:
=INFO REPORT 18-Jan-2012::14:55:30 ===
starting TCP connection 0.762.0 from 192.168.53.130:42483
=ERROR REPORT 18-Jan-2012::14:55:33 ===
exception on TCP connection 0.762.0 from 192.168.53.130:42483
{channel0_error,starting,
{amqp_error,access_refused,
AMQPLAIN login refused: user 'guest' - invalid
credentials,
'connection.start_ok'}}
=INFO REPORT 18-Jan-2012::14:55:33 ===
closing TCP connection 0.762.0 from 192.168.53.130:42483
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/918238/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1054501] Re: Fail safe wsgi logging
The first thing we do is log the exception. This happens before we attempt to return any information to the client or do any other processing. So I don't think we need any other fallback. Unless you have a testcase which demonstrates this is necessary. ** Changed in: nova Status: In Progress = Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1054501 Title: Fail safe wsgi logging Status in Cinder: In Progress Status in OpenStack Compute (Nova): Won't Fix Bug description: If there are any uncaught exceptions from api controllers, they are handled in nova/api/openstack/__init__.py:FaultWrapper, logged the handled exception and HTTP 500 response is sent to the client. There could be error while logging these uncaught exceptions and we missout them in the nova logs. In such a case, these exceptions should be logged into syslog for further investigation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1054501/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1327005] Re: Need change host to host_name in host resources
This is a python-novaclient bug, not a nova bug ** Also affects: python-novaclient Importance: Undecided Status: New ** 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/1327005 Title: Need change host to host_name in host resources Status in OpenStack Compute (Nova): Invalid Status in Python client library for Nova: New Bug description: step to reproduce: In python Terminal , from novaclient.v1_1 import client ct = client.Client(admin,password,admin,http://192.168.1.100:5000/v2.0;) ct.hosts.get(hostname) error: File stdin, line 1, in module File /opt/stack/python-novaclient/novaclient/v1_1/hosts.py, line 24, in __repr__ return Host: %s % self.host_name File /opt/stack/python-novaclient/novaclient/openstack/common/apiclient/base.py, line 464, in __getattr__ raise AttributeError(k) AttributeError: host_name To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1327005/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1323981] Re: Can't determine instance's server_group via 'DescribeInstance()'
Marking this as WontFix only because I think its a feature request, not a bug and we don't need to keep track of it in the bugs database. Please submit this as a proposal to nova-specs and blueprint ** 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/1323981 Title: Can't determine instance's server_group via 'DescribeInstance()' Status in OpenStack Compute (Nova): Won't Fix Bug description: The 'server_group' function is implemented in Icehouse. But we can't determine VM's server_group via 'DescribeInstance()'. The only way to get this info is to filter from all server_groups' memberships. That's not an elegant convenient way. Imagine the use case below: 1. One environment has lots of(like 100) server_groups, and each server_group involves 100 instances inside. 2. One instance has been created into one server_group before. Now I need to create another one with anti-affinity policy with it. 3. Now how can I determine which server_group should I choose? 4. The only way here is to list all server_groups info, and filter their membership using vm's uuid. 5. More and more workloads will be increased if environment has much more server_groups. So, we need to add one item like 'server_group' in 'DescribeInstance()'s response IMO. The server_group info is already stored in db. We only need to feedback the relationship of instance and server_group via the API. In this case, the step above can be simplified into one step: 1. Execute 'DescirbeInstance()' to get the server_group's uuid. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1323981/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1318770] Re: nova usage list to show tenant name.
This is a novaclient feature, not a nova one ** Also affects: python-novaclient Importance: Undecided Status: New ** Changed in: nova Status: New = Invalid ** Changed in: python-novaclient Importance: Undecided = Wishlist -- 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/1318770 Title: nova usage list to show tenant name. Status in OpenStack Compute (Nova): Invalid Status in Python client library for Nova: New Bug description: $nova --version 2.17.0.75 When I issue nova usage list command , I get the following details. $ nova usage-list Usage from 2014-04-11 to 2014-05-10: +--+-+--+---+---+ | Tenant ID| Servers | RAM MB-Hours | CPU Hours | Disk GB-Hours | +--+-+--+---+---+ | 41a0db24bc8940b6a2f3297bef5f6cee | 3 | 1478.70 | 23.10 | 0.00 | | 0dceee00627f44838174cccb6bf29421 | 3 | 172.36 | 1.36 | 0.00 | +--+-+--+---+---+ From the Tenant ID, I cannot able to know what tenant name it is . I want to know the tenant name. Because tenant ID is long to remember. To get tenant name , we have to use keystone tenant list. My proposal is to include tenant name in the current columns of nova usage list. So that user can easily recognize its tenant name. As the same thing is available in Horizon Dashboard. Is their any problems or dependices so that we are not including tenant name. If yes, please share the details for it. I would like to do the code executions for this. Thank you RITESH. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1318770/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1303781] [NEW] V3 API multinic extension missing expected_errors decorators
Public bug reported: The V3 API multinic extension is missing the expected errors decorator. This means that unexpected exceptions from Nova internals are not properly caught. ** Affects: nova Importance: Undecided Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api -- 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/1303781 Title: V3 API multinic extension missing expected_errors decorators Status in OpenStack Compute (Nova): New Bug description: The V3 API multinic extension is missing the expected errors decorator. This means that unexpected exceptions from Nova internals are not properly caught. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1303781/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1298771] Re: GET /servers/{server_id} should return 400 on invalid server_id but returns 404
The URL supplied is invalid if /tenant_id/servers/{server_id} does not
exist because server_id is not a valid server id. So 404 is the
appropriate response code.
** 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/1298771
Title:
GET /servers/{server_id} should return 400 on invalid server_id but
returns 404
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Currently,
Call to GET /${tenant_id}/servers/${server_id} validates the server_id
(uuid_like/int_like) and if found invalid, returns a 404 with
''Instance could not be found'' message.
On invalid server_id, it should return 400 (Bad Request) with the
message like Invalid server_id
more info:
ref: https://review.openstack.org/#/c/72637/13/nova/compute/api.py
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298771/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1289135] Re: cinderclient AmbiguousEndpoints in Nova API when deleting nested stack
Thanks Mike - any chance you could attach the output from keystone
service-list and endpoint-list ?
Adding python-cinderclient as I'm guessing the problem might be in there
somewhere.
** Also affects: python-cinderclient
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/1289135
Title:
cinderclient AmbiguousEndpoints in Nova API when deleting nested stack
Status in OpenStack Compute (Nova):
New
Status in Python client library for Cinder:
New
Bug description:
While chasing down some errors I found the first one was the
following, found in the log from the Nova API process.
2014-03-06 22:17:41.713 ERROR nova.api.openstack
[req-0a2e7b6b-8ea8-48f1-b6c9-4c6a20ba27b4 admin admin] Caught error:
AmbiguousEndpoints: [{u'url':
u'http://10.10.0.24:8776/v1/a4c140dd5649439987f9c61d0a91c76e', u'region':
u'RegionOne', u'legacy_endpoint_id': u'58ac5510148c4641ab48e1499c0bb4ec',
'serviceName': None, u'interface': u'admin', u'id':
u'154c830dce20478a8b269b5f85f7bca3'}, {u'url':
u'http://10.10.0.24:8776/v1/a4c140dd5649439987f9c61d0a91c76e', u'region':
u'RegionOne', u'legacy_endpoint_id': u'58ac5510148c4641ab48e1499c0bb4ec',
'serviceName': None, u'interface': u'public', u'id':
u'4129f440fa42491f997984455b9727af'}, {u'url':
u'http://10.10.0.24:8776/v1/a4c140dd5649439987f9c61d0a91c76e', u'region':
u'RegionOne', u'legacy_endpoint_id': u'58ac5510148c4641ab48e1499c0bb4ec',
'serviceName': None, u'interface': u'internal', u'id':
u'7f2013973d0248f1ba64ece67e3df7bb'}]
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack Traceback (most recent
call last):
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/opt/stack/nova/nova/api/openstack/__init__.py, line 125, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
req.get_response(self.application)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/request.py, line 1296, in send
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack application,
catch_exc_info=False)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/request.py, line 1260, in
call_application
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack app_iter =
application(self.environ, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
resp(environ, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py,
line 596, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
self.app(env, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
resp(environ, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
resp(environ, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/routes/middleware.py, line 131, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack response =
self.app(environ, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/dec.py, line 144, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
resp(environ, start_response)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/dec.py, line 130, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack resp =
self.call_func(req, *args, **self.kwargs)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/usr/lib/python2.7/dist-packages/webob/dec.py, line 195, in call_func
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack return
self.func(req, *args, **kwargs)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/opt/stack/nova/nova/api/openstack/wsgi.py, line 925, in __call__
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack content_type,
body, accept)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/opt/stack/nova/nova/api/openstack/wsgi.py, line 987, in _process_stack
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack action_result =
self.dispatch(meth, request, action_args)
2014-03-06 22:17:41.713 17339 TRACE nova.api.openstack File
/opt/stack/nova/nova/api/openstack/wsgi.py,
[Yahoo-eng-team] [Bug 1246987] Re: check_policy does not work correctly
** Changed in: nova Status: Incomplete = 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/1246987 Title: check_policy does not work correctly Status in OpenStack Compute (Nova): Invalid Bug description: function check_policy(context, 'method', target) If target is instance object, this check_policy function does not work like expected. Because target is not dict. e.g. /etc/nova/policy.json: startstop_api: is_admin:True or (project_id:%(project_id)s and role:comp_startstop and user_id:%(user_id)s), compute:start: rule:startstop_api, compute:stop: rule:startstop_api, above controls does not work never. ./nova/compute/api.py should revise. I fixed like below. [root@nova-all0001 compute]# diff -rup api.old.py api.py --- api.old.py 2013-11-01 15:42:22.086922939 +0900 +++ api.py 2013-11-01 14:38:12.407905965 +0900 @@ -194,7 +194,10 @@ def policy_decorator(scope): def outer(func): @functools.wraps(func) def wrapped(self, context, target, *args, **kwargs): -check_policy(context, func.__name__, target, scope) +if not isinstance(target, dict):# Y.Kawada +r_target = dict(target.iteritems()) + +check_policy(context, func.__name__, r_target, scope) return func(self, context, target, *args, **kwargs) return wrapped return outer To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246987/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1168488] Re: host-list policy irrelevant
This is getting handled as part of the process of bubbling up all of the policy checks to the API level - although targetted for the V3 API it will also affect the V2 API. https://blueprints.launchpad.net/nova/+spec/v3-api-policy So I'm closing this bug as it will be tracked through the blueprint instead. ** Changed in: nova Status: Triaged = 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/1168488 Title: host-list policy irrelevant Status in OpenStack Compute (Nova): Won't Fix Bug description: There are some compute REST APIs where the policy setting is irrelevant because they require admin. host-list is an example. To recreate, start with devstack, set up so that you're running as demo user. $ export OS_USERNAME=demo $ export OS_PASSWORD=mypwd $ export OS_TENANT_NAME=demo $ export OS_AUTH_URL=http://localhost:5000/v2.0 $ export OS_NO_CACHE=1 # First try with the default policy: $ grep compute_extension:hosts /etc/nova/policy.json compute_extension:hosts: rule:admin_api, $ nova host-list ERROR: Policy doesn't allow compute_extension:hosts to be performed. (HTTP 403) (Request-ID: req-b2b9408c-4498-4994-aee7-100cf6acf571) # Change policy so that anyone can view hosts: $ grep compute_extension:hosts /etc/nova/policy.json compute_extension:hosts: , $ nova host-list ERROR: User does not have admin privileges (HTTP 403) (Request-ID: req-48983c2e-784c-4bb5-82ac-6116a67f6fe1) It was expected that since I configured the policy so that anyone could view hosts that a non-admin user could list hosts. Nova should respect the policy that the admin configured and not force its own. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1168488/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1240831] Re: Changing policy.json is invalid for creating an aggregate
Since this is being handled by the v3-api-policy blueprint and being tracked by that blueprint, I'm closing this bug report ** Changed in: nova Status: Confirmed = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1240831 Title: Changing policy.json is invalid for creating an aggregate Status in OpenStack Compute (Nova): Invalid Bug description: In default, Aggregate actions require the admin-user to operate. In order to give rights to normal-user, I change it in the policy.json , like this: from compute_extension:aggregates: rule:admin_api, to compute_extension:aggregates: , But the operation result is also rejected. I check the codes in Nova, the fault dues to def require_admin_context() in /nova/db/sqlalchemy/api.py. That means Nova has checked the policy of one API twice. So why twice? The policy has already checked in the api-layer. That cause the problem happens~ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1240831/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1245764] Re: The response of availability-zone's index is inconsistent between xml and json format
XML support is going away so closing this bug
** Changed in: nova
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1245764
Title:
The response of availability-zone's index is inconsistent between xml
and json format
Status in OpenStack Compute (Nova):
Invalid
Bug description:
json format:
{
availability_zone_info: [
{
hosts: null,
zone_name: nova,
zone_state: {
available: true
}
}
]
}
xml format:
?xml version='1.0' encoding='UTF-8'?
availability_zones
xmlns:os-availability-zone=http://docs.openstack.org/compute/ext/availabilityzone/api/v3;
availability_zone name=nova
zone_state available=True/
metadata/
/availability_zone
/availability_zones
Json format use 'availability_zone_info', but xml format use
'availability_zones', we should make it consistent.
I prefer to use 'availability_zones'
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1245764/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1290326] [NEW] Input validation broken for os-server-groups create method
Public bug reported: Input validation of the name field for the create method for os-server- groups extension is broken in that it accepts integers, floats, etc as well as strings as the nova internals code quietly converts these to strings. This was not picked up by the unittests because they were correctly all the invalid data passed as the data was also missing the policies parameter which is compulsory. Also we should be tightening the name field to also fail on trailing and leading spaces as allowing this tends to cause confusing situations for users (this is where we have been headed in other places in the API). ** Affects: nova Importance: High Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api ** 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/1290326 Title: Input validation broken for os-server-groups create method Status in OpenStack Compute (Nova): New Bug description: Input validation of the name field for the create method for os- server-groups extension is broken in that it accepts integers, floats, etc as well as strings as the nova internals code quietly converts these to strings. This was not picked up by the unittests because they were correctly all the invalid data passed as the data was also missing the policies parameter which is compulsory. Also we should be tightening the name field to also fail on trailing and leading spaces as allowing this tends to cause confusing situations for users (this is where we have been headed in other places in the API). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1290326/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1282535] Re: The real api is os-interface but in nova doc is os-attach-interfaces
We can't fix this in Nova V2 as it is a backwards incompatible change, so the only place we can fix it is the docs. Sorry. ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: nova Status: In Progress = Invalid ** Tags added: api -- 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/1282535 Title: The real api is os-interface but in nova doc is os-attach- interfaces Status in OpenStack Compute (Nova): Invalid Status in OpenStack Manuals: New Bug description: hi all: when I get interface use api os-attach-interfaces which is in nova doc, it return 404. but use the api os-interface,it return the result. os-attach-interfaces has replaced the os-interface.so we must modify this bug. doc url: http://api.openstack.org/api-ref-compute-ext.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1282535/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1286936] [NEW] v2 API sample for os-assisted-volume snapshot is incorrect
Public bug reported: The v2 API sample for os-assisted volume snapshot is wrong and given it is used for documentation misleading to users of the API ** Affects: nova Importance: Undecided Assignee: Christopher Yeoh (cyeoh-0) Status: New ** Tags: api ** Tags added: api ** Changed in: nova Assignee: (unassigned) = Christopher Yeoh (cyeoh-0) -- 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/1286936 Title: v2 API sample for os-assisted-volume snapshot is incorrect Status in OpenStack Compute (Nova): New Bug description: The v2 API sample for os-assisted volume snapshot is wrong and given it is used for documentation misleading to users of the API To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1286936/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1269066] Re: Call to dns related APIs are not implemented when using neutron
So rather than multiple bug reports documenting bits missing in the proxying of neutron information in Nova I think instead we should do this as a single blueprint which covers all of the different areas where we need better neutron support. Though note that the long term goal is to remove proxying of neutron information in Nova. ** 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/1269066 Title: Call to dns related APIs are not implemented when using neutron Status in OpenStack Compute (Nova): Invalid Bug description: The following methods in nova.network.neutron.v2.api are not implemented (well, they throw NotImplemented exceptions) - create_private_dns_domains - create_public_dns_domains - get_dns_entries_by_address - get_dns_entries_by_name - get_dns_domains - add_dns_entry - modify_dns_entry - delete_dns_entry - delete_dns_domain To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1269066/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1269065] Re: Calls for basic network operations are not implemented when using neutron
So rather than multiple bug reports documenting bits missing in the proxying of neutron information in Nova I think instead we should do this as a single blueprint which covers all of the different areas where we need better neutron support. Though note that the long term goal is to remove proxying of neutron information in Nova. ** 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/1269065 Title: Calls for basic network operations are not implemented when using neutron Status in OpenStack Compute (Nova): Invalid Bug description: Certain methods that are related to network lifecycle and association with projects/tenants are not implemented when using neutron. - add_project_to_network - delete - disassociate It may be unreasonable to implement these in the nova.network.neutronv2.api module, but it does have an impact on dropping in neutron as a nova-network replacement. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1269065/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1273556] [NEW] Servers sometimes fail to startup in the gate with a permission denied
Public bug reported: Sometimes servers fail to startup - intermittent gate/check bug Example error: 2014-01-28 02:14:36.309 ERROR nova.scheduler.filter_scheduler [req-a617cb8a-4f34-42f9-a4a7-e951cf538219 InstanceActionsTestJSON-tempest-857832860-user InstanceActionsTestJSON-tempest-857832860-tenant] [instance: 0f9850c1-b5a8-4d62-98ab-11b04ba41165] Error from last host: devstack-precise-1390529664 (node devstack-precise-1390529664): [u'Traceback (most recent call last): ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 1068, in _build_instance set_access_ip=set_access_ip) ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 354, in decorated_function return function(self, context, *args, **kwargs) ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 1478, in _spawn LOG.exception(_(\'Instance failed to spawn\'), instance=instance) ', u' File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 68, in __exit__ six.reraise(self.type_, self.value, self.tb) ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 1475, in _spawn block_device_info) ', u' File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2187, in spawn admin_pass=admin_password) ', u' File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2490, in _create_image project_id=instance[\'project_id\']) ', u' File /opt/stack/new/nova/nova/virt/libvirt/imagebackend.py, line 180, in cache imagecache.refresh_timestamp(base) ', u' File /opt/stack/new/nova/nova/virt/libvirt/imagecache.py, line 261, in refresh_timestamp inner_refresh_timestamp() ', u' File /opt/stack/new/nova/nova/openstack/common/lockutils.py, line 249, in inner return f(*args, **kwargs) ', u' File /opt/stack/new/nova/nova/virt/libvirt/imagecache.py, line 258, in inner_refresh_timestamp os.utime(base_file, None) ', uOSError: [Errno 13] Permission denied: '/opt/stack/data/nova/instances/_base/307971e863bbda9ebaf13fcfedcb13498a5dbde6' ] From here: http://logs.openstack.org/91/58191/4/check/check-tempest-dsvm- full/0dc8d4d/logs/screen-n-sch.txt.gz#_2014-01-28_02_14_36_309 ** 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/1273556 Title: Servers sometimes fail to startup in the gate with a permission denied Status in OpenStack Compute (Nova): New Bug description: Sometimes servers fail to startup - intermittent gate/check bug Example error: 2014-01-28 02:14:36.309 ERROR nova.scheduler.filter_scheduler [req-a617cb8a-4f34-42f9-a4a7-e951cf538219 InstanceActionsTestJSON-tempest-857832860-user InstanceActionsTestJSON-tempest-857832860-tenant] [instance: 0f9850c1-b5a8-4d62-98ab-11b04ba41165] Error from last host: devstack-precise-1390529664 (node devstack-precise-1390529664): [u'Traceback (most recent call last): ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 1068, in _build_instance set_access_ip=set_access_ip) ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 354, in decorated_function return function(self, context, *args, **kwargs) ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 1478, in _spawn LOG.exception(_(\'Instance failed to spawn\'), instance=instance) ', u' File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 68, in __exit__ six.reraise(self.type_, self.value, self.tb) ', u' File /opt/stack/new/nova/nova/compute/manager.py, line 1475, in _spawn block_device_info) ', u' File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2187, in spawn admin_pass=admin_password) ', u' File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2490, in _create_image project_id=instance[\'project_id\']) ', u' File /opt/stack/new/nova/nova/virt/libvirt/imagebackend.py, line 180, in cache imagecache.refresh_timestamp(base) ', u' File /opt/stack/new/nova/nova/virt/libvirt/imagecache.py, line 261, in refresh_timestamp inner_refresh_timestamp() ', u' File /opt/stack/new/nova/nova/openstack/common/lockutils.py, line 249, in inner return f(*args, **kwargs) ', u' File /opt/stack/new/nova/nova/virt/libvirt/imagecache.py, line 258, in inner_refresh_timestamp os.utime(base_file, None) ', uOSError: [Errno 13] Permission denied: '/opt/stack/data/nova/instances/_base/307971e863bbda9ebaf13fcfedcb13498a5dbde6' ] From here: http://logs.openstack.org/91/58191/4/check/check-tempest-dsvm- full/0dc8d4d/logs/screen-n-sch.txt.gz#_2014-01-28_02_14_36_309 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1273556/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help
[Yahoo-eng-team] [Bug 1271146] [NEW] V2 API instance_actions does not catch InstanceNotFound exceptions
Public bug reported: The V2 API instance_actions extension (addFloatingIp) does not catch InstanceNotFound exceptions which causes a traceback in the nova api log ** Affects: nova Importance: Undecided Assignee: Christopher Yeoh (cyeoh-0) Status: In Progress -- 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/1271146 Title: V2 API instance_actions does not catch InstanceNotFound exceptions Status in OpenStack Compute (Nova): In Progress Bug description: The V2 API instance_actions extension (addFloatingIp) does not catch InstanceNotFound exceptions which causes a traceback in the nova api log To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1271146/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1263019] Re: tempest.api.volume.test_volume_transfers.VolumesTransfersTest.test_create_list_delete_volume_transfer failed
*** This bug is a duplicate of bug 1262432 *** https://bugs.launchpad.net/bugs/1262432 ** This bug has been marked a duplicate of bug 1262432 tempest volume transfer test can race against other tenants -- 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/1263019 Title: tempest.api.volume.test_volume_transfers.VolumesTransfersTest.test_create_list_delete_volume_transfer failed Status in Cinder: New Status in OpenStack Compute (Nova): New Bug description: the tempest test failed in gate: http://logs.openstack.org/38/40638/10/check/check-tempest-dsvm-full/8361472/testr_results.html.gz message: Invalid volume: Volume status must be available or error, but current status is: awaiting-transfer but there is a waiter: self.client.wait_for_volume_status(volume['id'], 'available') before delete the volume. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1263019/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1222727] Re: camel-style issue in limites v3 api
Used limits will be removed in icehouse as will most if not of all of limits (there are a couple of changesets already in the queue doing this). ** 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/1222727 Title: camel-style issue in limites v3 api Status in OpenStack Compute (Nova): Won't Fix Bug description: there is camel-style issue havn't been clean in limits v3 api. in file nova/api/openstack/compute/plugins/v3/used_limits.py and nova/api/openstack/compute/views/limits.py there is camel-style code used by limits v3 api. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1222727/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1220773] Re: Nova command 'nova list' ( also, image-list, nova secgroup-add-rule, etc) fails and the system hangs
From the logs it looks like you have some authentication issues with
your setup which probably explains the very long timeout.
** 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/1220773
Title:
Nova command 'nova list' ( also, image-list, nova secgroup-add-rule,
etc) fails and the system hangs
Status in OpenStack Compute (Nova):
Invalid
Bug description:
I installed the openstack Grizzly in a single node. Every thing went
alright. But, When I execute the nova list, the system hangs and
then I press Ctl-C, and the following message is shown on the display.
I think, the root is he long time to start http connection (around
255 sec).
nova list
INFO (connectionpool:191) Starting new HTTP connection (1): 1XX.56.XX.X
^CTraceback (most recent call last):
File /usr/bin/nova, line 9, in module
load_entry_point('python-novaclient==2.13.0', 'console_scripts', 'nova')()
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 765, in
main
OpenStackComputeShell().main(map(strutils.safe_decode, sys.argv[1:]))
File /usr/lib/python2.7/dist-packages/novaclient/shell.py, line 701, in
main
args.func(self.cs, args)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py, line 937,
in do_list
servers = cs.servers.list(search_opts=search_opts)
File /usr/lib/python2.7/dist-packages/novaclient/v1_1/servers.py, line
375, in list
return self._list(/servers%s%s % (detail, query_string), servers)
File /usr/lib/python2.7/dist-packages/novaclient/base.py, line 62, in
_list
_resp, body = self.api.client.get(url)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 230, in
get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 217, in
_cs_request
**kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 199, in
_time_request
resp, body = self.request(url, method, **kwargs)
File /usr/lib/python2.7/dist-packages/novaclient/client.py, line 170, in
request
**kwargs)
File /usr/lib/python2.7/dist-packages/requests/api.py, line 44, in request
return session.request(method=method, url=url, **kwargs)
File /usr/lib/python2.7/dist-packages/requests/sessions.py, line 354, in
request
resp = self.send(prep, **send_kwargs)
File /usr/lib/python2.7/dist-packages/requests/sessions.py, line 460, in
send
r = adapter.send(request, **kwargs)
File /usr/lib/python2.7/dist-packages/requests/adapters.py, line 211, in
send
timeout=timeout
File /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py, line
415, in urlopen
body=body, headers=headers)
File /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py, line
275, in _make_request
httplib_response = conn.getresponse(buffering=True)
File /usr/lib/python2.7/httplib.py, line 1030, in getresponse
response.begin()
File /usr/lib/python2.7/httplib.py, line 407, in begin
version, status, reason = self._read_status()
File /usr/lib/python2.7/httplib.py, line 365, in _read_status
line = self.fp.readline()
File /usr/lib/python2.7/socket.py, line 447, in readline
data = self._sock.recv(self._rbufsize)
KeyboardInterrupt
Here is the last three log entries from the /var/log/nova/nova-
api.log. The http connection time is ~255, which is very large. I have
not yet created any VM, as I could not execute nova image-list,
secgroup-add-rule, etc.
2013-09-04 06:14:24.173 31946 INFO nova.osapi_compute.wsgi.server [-]
(31946) accepted ('1XX.56.XX.X', 41687)
2013-09-04 06:15:13.868 31946 INFO nova.osapi_compute.wsgi.server [-]
1XX.56.XX.X GET /v2/e4e613863a214020935c7aabe44ba7ce/os-tenant-
networks HTTP/1.1 status: 401 len: 465 time: 255.9475789
2013-09-04 06:16:17.996 31946 INFO nova.osapi_compute.wsgi.server [-]
1XX.56.XX.X GET /v2/e4e613863a214020935c7aabe44ba7ce/os-security-
groups HTTP/1.1 status: 401 len: 465 time: 256.0612741
Here I should note down that there are three instances of nova-api
process running in my computer. The openstack is a single-node
installation.
Please help.
Thank you very much,
Abhi
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1220773/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1188944] Re: Single fixed_ip allocated to an instance can be deleted and not assigned again on request
The return code is 202 and is returned before its known if the operation has succeeded or not. Defintion for 202 is The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing actually takes place. there is no facility for status returns from asynchronous operations such as this. ** 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/1188944 Title: Single fixed_ip allocated to an instance can be deleted and not assigned again on request Status in OpenStack Compute (Nova): Invalid Bug description: Hi I am using devstack (current master branch, may be of havana release) and launched an instance from cirros image as following:- +--+--+++-++ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-++ | eb251761-50f0-4a00-9062-a572ff7af834 | CIRROS-1 | ACTIVE | None | Running | private=10.0.0.2 | Now I deleted the fixed ip using below CLI:- $$ nova remove-fixed-ip CIRROS-1 10.0.0.2 And it removed fixed ip successfully:- +--+--+++-++ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-++ | eb251761-50f0-4a00-9062-a572ff7af834 | CIRROS-1 | ACTIVE | None | Running || Now I again want to add fixed_ip and tried many times using below CLIs:- $$nova add-fixed-ip CIRROS-1 10.0.0.4 $$nova add-fixed-ip CIRROS-1 10.0.0.2 But above CLIs neither give error nor allocate fixed_ip to instance. I tried it with both user i.e. demo and admin, and also try to ping that IPs but not working. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1188944/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1182883] Re: List servers matching a regex fails with Quantum
** Changed in: nova Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1182883 Title: List servers matching a regex fails with Quantum Status in OpenStack Neutron (virtual network service): Invalid Status in OpenStack Compute (Nova): Invalid Status in Tempest: Confirmed Bug description: The test tempest.api.compute.servers.test_list_server_filters:ListServerFiltersTestXML.test_list_servers_filtered_by_ip_regex tries to search a server with only a fragment of its IP (GET http://XX/v2/$Tenant/servers?ip=10.0.) which calls the following Quantum request : http://XX/v2.0/ports.json?fixed_ips=ip_address%3D10.0. But it seems this regex search is not supporter by Quantum. Thus the tempest test fauls. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1182883/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1196255] Re: Cannot filter 'soft-deletd' instances via nova api
** 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/1196255 Title: Cannot filter 'soft-deletd' instances via nova api Status in OpenStack Compute (Nova): Won't Fix Bug description: In nova-api, both DELETED and SOFT_DELETED are mapped to 'DELETED'. Thus we cannot filer 'soft-deleted' instances via nova-api, like: nova list --status SOFT_DELETED To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196255/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1205841] Re: API deallocate Floating IP address
Looks like this has been fixed in the doco
** 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/1205841
Title:
API deallocate Floating IP address
Status in OpenStack Compute (Nova):
Invalid
Bug description:
Try to deallocate a floating IP from a tenantID throgh http API, the
address should be v2/{tenant_id}/os-floating-ips/{ip_id}, rather than
v2/{tenant_id}/os-floating-ips which is found at:
http://api.openstack.org/api-ref.html#ext-floating-ips
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1205841/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1117555] Re: SSH timeout in tempest.test.boto.test_ec2_instance_run
I think the problem seen in http://logs.openstack.org/22765/4/check /gate-tempest-devstack-vm-full/6460/ should be fixed by https://review.openstack.org/#/c/23067/3 which ups the timeout to 60 secs. There's two timeout's we see here: One in RemoteClient's __init__ making the initial connection which has a long timeout and appears to be caused by the public ip not being reachable (perhaps the firewall settings aren't getting through properly) and the timeout with the console output, which I *think* should now be fixed. I'm moving the status of the bug back to open because 23067 doesn't fix the first issue. ** Changed in: tempest Status: Fix Released = Triaged -- 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/1117555 Title: SSH timeout in tempest.test.boto.test_ec2_instance_run Status in OpenStack Compute (Nova): New Status in Tempest: Triaged Bug description: quantum devstack gate failure: http://logs.openstack.org/21179/1/gate/gate-tempest-devstack-vm-quantum/5156 : FAILURE 2013-02-06 16:26:40.052 | == 2013-02-06 16:26:40.053 | ERROR: tempest.tests.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1 2013-02-06 16:26:40.054 | -- 2013-02-06 16:26:40.054 | _StringException: Traceback (most recent call last): 2013-02-06 16:26:40.054 | File /opt/stack/new/tempest/tempest/tests/boto/test_ec2_instance_run.py, line 205, in test_integration_1 2013-02-06 16:26:40.054 | pkey=self.keypair.material) 2013-02-06 16:26:40.054 | File /opt/stack/new/tempest/tempest/common/utils/linux/remote_client.py, line 31, in __init__ 2013-02-06 16:26:40.054 | if not self.ssh_client.test_connection_auth(): 2013-02-06 16:26:40.055 | File /opt/stack/new/tempest/tempest/common/ssh.py, line 142, in test_connection_auth 2013-02-06 16:26:40.055 | connection = self._get_ssh_connection() 2013-02-06 16:26:40.055 | File /opt/stack/new/tempest/tempest/common/ssh.py, line 75, in _get_ssh_connection 2013-02-06 16:26:40.055 | password=self.password) 2013-02-06 16:26:40.055 | SSHTimeout: Connection to the 172.24.4.228 via SSH timed out. 2013-02-06 16:26:40.055 | User: cirros, Password: None 2013-02-06 16:26:40.055 | 2013-02-06 16:26:40.055 | begin captured logging 2013-02-06 16:26:40.056 | tempest.config: INFO: Using tempest config file /opt/stack/new/tempest/etc/tempest.conf 2013-02-06 16:26:40.056 | requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1 2013-02-06 16:26:40.056 | requests.packages.urllib3.connectionpool: DEBUG: POST /v2.0/tokens HTTP/1.1 200 None 2013-02-06 16:26:40.056 | requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1 2013-02-06 16:26:40.056 | requests.packages.urllib3.connectionpool: DEBUG: GET /v2.0/users/40d750dffc934dc293df7f5ce621ad33/credentials/OS-EC2 HTTP/1.1 200 None 2013-02-06 16:26:40.056 | requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1 2013-02-06 16:26:40.056 | requests.packages.urllib3.connectionpool: DEBUG: POST /v2.0/tokens HTTP/1.1 200 None 2013-02-06 16:26:40.057 | requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1 2013-02-06 16:26:40.057 | requests.packages.urllib3.connectionpool: DEBUG: GET /v2.0/users/40d750dffc934dc293df7f5ce621ad33/credentials/OS-EC2 HTTP/1.1 200 None 2013-02-06 16:26:40.057 | requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1 2013-02-06 16:26:40.057 | requests.packages.urllib3.connectionpool: DEBUG: POST /v2.0/tokens HTTP/1.1 200 None 2013-02-06 16:26:40.057 | requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1 2013-02-06 16:26:40.057 | requests.packages.urllib3.connectionpool: DEBUG: GET /v2.0/users/40d750dffc934dc293df7f5ce621ad33/credentials/OS-EC2 HTTP/1.1 200 None To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1117555/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
