[Yahoo-eng-team] [Bug 1620692] [NEW] Debug logging in scheduler kills performance
Public bug reported: When using the filter_scheduler with 400 hosts (not a very large number) and debug logging turned on, scheduling times start taking a very long time. With debug logging on, select_destinations() can swing anywhere between 3 and 18 seconds. With debug logging off, select_destinations() takes 0-4 seconds (http://paste.openstack.org/show/566153/). The main problem is https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L162-L178 because in a 400 host environment, it's trying to log debug 1600 times on every instance boot. ** 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/1620692 Title: Debug logging in scheduler kills performance Status in OpenStack Compute (nova): New Bug description: When using the filter_scheduler with 400 hosts (not a very large number) and debug logging turned on, scheduling times start taking a very long time. With debug logging on, select_destinations() can swing anywhere between 3 and 18 seconds. With debug logging off, select_destinations() takes 0-4 seconds (http://paste.openstack.org/show/566153/). The main problem is https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L162-L178 because in a 400 host environment, it's trying to log debug 1600 times on every instance boot. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1620692/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1581203] [NEW] Default policy allows unrestricted CRUD on os-server-tags
Public bug reported: The default policy for os-server-tags listed here (https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L448-L453) allow all users to do any CRUD operations on all server tags. This should be limited down to only admin_or_owner. ** Affects: nova Importance: Medium Assignee: Ryan Rossiter (rlrossit) Status: In Progress ** Tags: api policy tags -- 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/1581203 Title: Default policy allows unrestricted CRUD on os-server-tags Status in OpenStack Compute (nova): In Progress Bug description: The default policy for os-server-tags listed here (https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L448-L453) allow all users to do any CRUD operations on all server tags. This should be limited down to only admin_or_owner. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1581203/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1564182] Re: CPU Metrics not working
*** This bug is a duplicate of bug 1514997 *** https://bugs.launchpad.net/bugs/1514997 ** This bug has been marked a duplicate of bug 1514997 Metrics filter receives wrong metric value -- 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/1564182 Title: CPU Metrics not working Status in OpenStack Compute (nova): In Progress Bug description: The metrics collection on compute nodes is currently not working. When the compute node creates the object to save, it is divided to be a value inside [0,1]. However, at the same time, when the scheduler needs to pull out the numbers, it divides it once again as it pulls the objects: https://github.com/openstack/nova/blob/stable/liberty/nova/compute/resource_tracker.py#L437 https://github.com/openstack/nova/blob/stable/liberty/nova/compute/monitors/base.py#L60-L63 https://github.com/openstack/nova/blob/stable/liberty/nova/objects/monitor_metric.py#L68-L71 This essentially means that it always returns a value of zero as a metric, because it divides a small number again by 100. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1564182/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1555826] [NEW] Functional API client has incorrect URL for volumes
Public bug reported: All of the volume operations in the functional api client helper methods has 'volumes' for the URL instead of 'os-volumes' (https://github.com/openstack/nova/blob/master/nova/tests/functional/api/client.py#L307). [Link to API guide: http://developer.openstack.org/api-ref- compute-v2.1.html#os-volumes]. This will cause any tests that want to use that helper method to get a 404 instead of their desired function. ** Affects: nova Importance: Medium Assignee: Ryan Rossiter (rlrossit) Status: Triaged ** Tags: api functional testing -- 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/1555826 Title: Functional API client has incorrect URL for volumes Status in OpenStack Compute (nova): Triaged Bug description: All of the volume operations in the functional api client helper methods has 'volumes' for the URL instead of 'os-volumes' (https://github.com/openstack/nova/blob/master/nova/tests/functional/api/client.py#L307). [Link to API guide: http://developer.openstack.org/api-ref- compute-v2.1.html#os-volumes]. This will cause any tests that want to use that helper method to get a 404 instead of their desired function. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1555826/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1554631] [NEW] Cinder exceptions returned from nova rest api as 500 errors
Public bug reported:
When the nova volume API makes calls into the Cinder API using
cinderclient, if cinder raises an exception like Forbidden or OverLimit,
the nova volume api does not catch these exceptions. So they go up to
the nova rest api, resulting in a 500 to be returned.
Here's an example from a tempest test:
Traceback (most recent call last):
File "/home/ubuntu/tempest/tempest/api/compute/volumes/test_volumes_get.py",
line 51, in test_volume_create_get_delete
metadata=metadata)['volume']
File "/home/ubuntu/tempest/tempest/lib/services/compute/volumes_client.py",
line 55, in create_volume
resp, body = self.post('os-volumes', post_body)
File "/home/ubuntu/tempest/tempest/lib/common/rest_client.py", line 259, in
post
return self.request('POST', url, extra_headers, headers, body)
File "/home/ubuntu/tempest/tempest/lib/common/rest_client.py", line 642, in
request
resp, resp_body)
File "/home/ubuntu/tempest/tempest/lib/common/rest_client.py", line 761, in
_error_checker
message=message)
tempest.lib.exceptions.ServerFault: Got server fault
Details: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
The volume API needs to wrap these exceptions and return the nova
equivalent to the rest API so the appropriate return code can be
returned.
** Affects: nova
Importance: Undecided
Assignee: Ryan Rossiter (rlrossit)
Status: New
** Changed in: nova
Assignee: (unassigned) => Ryan Rossiter (rlrossit)
--
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/1554631
Title:
Cinder exceptions returned from nova rest api as 500 errors
Status in OpenStack Compute (nova):
New
Bug description:
When the nova volume API makes calls into the Cinder API using
cinderclient, if cinder raises an exception like Forbidden or
OverLimit, the nova volume api does not catch these exceptions. So
they go up to the nova rest api, resulting in a 500 to be returned.
Here's an example from a tempest test:
Traceback (most recent call last):
File
"/home/ubuntu/tempest/tempest/api/compute/volumes/test_volumes_get.py", line
51, in test_volume_create_get_delete
metadata=metadata)['volume']
File "/home/ubuntu/tempest/tempest/lib/services/compute/volumes_client.py",
line 55, in create_volume
resp, body = self.post('os-volumes', post_body)
File "/home/ubuntu/tempest/tempest/lib/common/rest_client.py", line 259, in
post
return self.request('POST', url, extra_headers, headers, body)
File "/home/ubuntu/tempest/tempest/lib/common/rest_client.py", line 642, in
request
resp, resp_body)
File "/home/ubuntu/tempest/tempest/lib/common/rest_client.py", line 761, in
_error_checker
message=message)
tempest.lib.exceptions.ServerFault: Got server fault
Details: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
The volume API needs to wrap these exceptions and return the nova
equivalent to the rest API so the appropriate return code can be
returned.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1554631/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1554617] [NEW] Tests for aggregates use getattr() improperly
Public bug reported: Because objects do not raise AttributeError if an attribute is not set, the default functionality of getattr() cannot be used with objects. Instead, an 'in' check needs to be used on the object, and if that passes, I can use getattr(). If that fails, I need to give the default. ** Affects: nova Importance: Undecided Assignee: Ryan Rossiter (rlrossit) 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/1554617 Title: Tests for aggregates use getattr() improperly Status in OpenStack Compute (nova): In Progress Bug description: Because objects do not raise AttributeError if an attribute is not set, the default functionality of getattr() cannot be used with objects. Instead, an 'in' check needs to be used on the object, and if that passes, I can use getattr(). If that fails, I need to give the default. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1554617/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1537882] [NEW] test_obj_make_compatible() does not call __init__ properly on ServiceStatusPayload objects
Public bug reported:
Because I can tell the future, the test_obj_make_compatible() method
will start failing the next time we bump the version of
ServiceStatusPayload.
It looks like in
https://github.com/openstack/nova/blob/master/nova/tests/unit/objects/test_objects.py#L1252-L1268
we run compatibility checks on all previous versions to see if we're
compatible with them. It does not test current->current conversion
though, so in the case of ServiceStatusPayload, which is currently at
1.0, that for loop is never run.
I caught this in my change
(https://review.openstack.org/#/c/259112/2/nova/tests/unit/objects/test_objects.py)
because ovo's compatibility checker includes checking from 1.0 to 1.0
(https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fixture.py#L302-L310),
and I'm trying to change nova's tests to use the o.vo fixture. In my
tests, ServiceStatusPayload is causing:
Traceback (most recent call last):
File "nova/tests/unit/objects/test_objects.py", line 1259, in
test_obj_make_compatible
checker.test_compatibility_routines(use_manifest=True)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/fixture.py",
line 325, in test_compatibility_routines
self._test_object_compatibility(obj_class, manifest=manifest)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/fixture.py",
line 309, in _test_object_compatibility
obj_class().obj_to_primitive(**kwargs)
TypeError: __init__() takes exactly 2 arguments (1 given)
So we need to somehow inject args to __init__() when we need to...
** Affects: nova
Importance: Undecided
Assignee: Ryan Rossiter (rlrossit)
Status: New
** Tags: testing
** Summary changed:
- test_obj_make_compatible() does not call __init__ properly on
NotificationPayloadBase objects
+ test_obj_make_compatible() does not call __init__ properly on
ServiceStatusPayload objects
** Changed in: nova
Assignee: (unassigned) => Ryan Rossiter (rlrossit)
** Tags added: testing
--
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/1537882
Title:
test_obj_make_compatible() does not call __init__ properly on
ServiceStatusPayload objects
Status in OpenStack Compute (nova):
New
Bug description:
Because I can tell the future, the test_obj_make_compatible() method
will start failing the next time we bump the version of
ServiceStatusPayload.
It looks like in
https://github.com/openstack/nova/blob/master/nova/tests/unit/objects/test_objects.py#L1252-L1268
we run compatibility checks on all previous versions to see if we're
compatible with them. It does not test current->current conversion
though, so in the case of ServiceStatusPayload, which is currently at
1.0, that for loop is never run.
I caught this in my change
(https://review.openstack.org/#/c/259112/2/nova/tests/unit/objects/test_objects.py)
because ovo's compatibility checker includes checking from 1.0 to 1.0
(https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/fixture.py#L302-L310),
and I'm trying to change nova's tests to use the o.vo fixture. In my
tests, ServiceStatusPayload is causing:
Traceback (most recent call last):
File "nova/tests/unit/objects/test_objects.py", line 1259, in
test_obj_make_compatible
checker.test_compatibility_routines(use_manifest=True)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/fixture.py",
line 325, in test_compatibility_routines
self._test_object_compatibility(obj_class, manifest=manifest)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/fixture.py",
line 309, in _test_object_compatibility
obj_class().obj_to_primitive(**kwargs)
TypeError: __init__() takes exactly 2 arguments (1 given)
So we need to somehow inject args to __init__() when we need to...
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1537882/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1535327] [NEW] neutron.common.rpc has no unit test coverage
Public bug reported: The neutron.common.rpc module has no unit test coverage. The following change was made to neutron/common/rpc.py: 68 def cleanup(): 69 global TRANSPORT, NOTIFIER 70 assert TRANSPORT is not None 71 assert NOTIFIER is not None 72 #TRANSPORT.cleanup() 73 #TRANSPORT = NOTIFIER = None No unit tests failed as a result of L72-73 being commented out, meaning no unit tests are covering some of the main functionality of this module. At a minimum, the public functions and classes should be unit tested. ** Affects: neutron Importance: Undecided Status: New ** Tags: unittest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535327 Title: neutron.common.rpc has no unit test coverage Status in neutron: New Bug description: The neutron.common.rpc module has no unit test coverage. The following change was made to neutron/common/rpc.py: 68 def cleanup(): 69 global TRANSPORT, NOTIFIER 70 assert TRANSPORT is not None 71 assert NOTIFIER is not None 72 #TRANSPORT.cleanup() 73 #TRANSPORT = NOTIFIER = None No unit tests failed as a result of L72-73 being commented out, meaning no unit tests are covering some of the main functionality of this module. At a minimum, the public functions and classes should be unit tested. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535327/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1533741] [NEW] nova.rpc module is only indirectly unit tested
Public bug reported: It seems that there are no unit tests for the nova.rpc module. Because nova.rpc is used by many other modules, changes to it do cause UT failures. But it is possible to remove essential parts without failing any unit tests. An example of this is removing TRANSPORT.cleanup() from the cleanup function. Tests should be added for all of the public functions, along with tests for RequestContextSerializer for both a given base, and a null base. ** Affects: nova Importance: Undecided Assignee: Ryan Rossiter (rlrossit) Status: New ** Changed in: nova Assignee: (unassigned) => Ryan Rossiter (rlrossit) -- 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/1533741 Title: nova.rpc module is only indirectly unit tested Status in OpenStack Compute (nova): New Bug description: It seems that there are no unit tests for the nova.rpc module. Because nova.rpc is used by many other modules, changes to it do cause UT failures. But it is possible to remove essential parts without failing any unit tests. An example of this is removing TRANSPORT.cleanup() from the cleanup function. Tests should be added for all of the public functions, along with tests for RequestContextSerializer for both a given base, and a null base. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1533741/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1532078] [NEW] Aggregate availability_zone access throws NotImplementedError when metadata is null
Public bug reported:
The Aggregate object has an availability_zone property that, when
accessed, gets the availability zone as a key/value stored in the
metadata field. The problem is, the metadata field is nullable, so if an
Aggregate object is created with no metadata, calling the
availability_zone property will explode because it is trying to get the
'availability_zone' key on the metadata field.
Here is a simple test that fails to show the problem (put in
nova/tests/unit/objects/test_aggregate.py):
def test_get_availability_zone_with_null_metadata(self):
agg = aggregate.Aggregate()
self.assertIsNone(agg.availability_zone)
Here's the result of the test:
nova.tests.unit.objects.test_aggregate.TestAggregateObject.test_get_availability_zone_with_null_metadata
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/objects/test_aggregate.py", line 192, in
test_get_availability_zone_with_null_metadata
self.assertIsNone(agg.availability_zone)
File "nova/objects/aggregate.py", line 151, in availability_zone
return self.metadata.get('availability_zone', None)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
line 67, in getter
self.obj_load_attr(name)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
line 578, in obj_load_attr
_("Cannot load '%s' in the base class") % attrname)
NotImplementedError: Cannot load 'metadata' in the base class
** Affects: nova
Importance: Undecided
Assignee: Ryan Rossiter (rlrossit)
Status: New
** Changed in: nova
Assignee: (unassigned) => Ryan Rossiter (rlrossit)
--
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/1532078
Title:
Aggregate availability_zone access throws NotImplementedError when
metadata is null
Status in OpenStack Compute (nova):
New
Bug description:
The Aggregate object has an availability_zone property that, when
accessed, gets the availability zone as a key/value stored in the
metadata field. The problem is, the metadata field is nullable, so if
an Aggregate object is created with no metadata, calling the
availability_zone property will explode because it is trying to get
the 'availability_zone' key on the metadata field.
Here is a simple test that fails to show the problem (put in
nova/tests/unit/objects/test_aggregate.py):
def test_get_availability_zone_with_null_metadata(self):
agg = aggregate.Aggregate()
self.assertIsNone(agg.availability_zone)
Here's the result of the test:
nova.tests.unit.objects.test_aggregate.TestAggregateObject.test_get_availability_zone_with_null_metadata
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/objects/test_aggregate.py", line 192, in
test_get_availability_zone_with_null_metadata
self.assertIsNone(agg.availability_zone)
File "nova/objects/aggregate.py", line 151, in availability_zone
return self.metadata.get('availability_zone', None)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
line 67, in getter
self.obj_load_attr(name)
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py",
line 578, in obj_load_attr
_("Cannot load '%s' in the base class") % attrname)
NotImplementedError: Cannot load 'metadata' in the base class
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1532078/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1516137] [NEW] There should be a nova.objects.fields.ContainerFormatEnum for the ImageMeta.container_format field
Public bug reported: In the same way that https://bugs.launchpad.net/nova/+bug/1489531 was for changing the disk format, we should also have an enum for container format so we can control that a little better. ** Affects: nova Importance: Undecided Assignee: Ryan Rossiter (rlrossit) Status: New ** Changed in: nova Assignee: (unassigned) => Ryan Rossiter (rlrossit) -- 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/1516137 Title: There should be a nova.objects.fields.ContainerFormatEnum for the ImageMeta.container_format field Status in OpenStack Compute (nova): New Bug description: In the same way that https://bugs.launchpad.net/nova/+bug/1489531 was for changing the disk format, we should also have an enum for container format so we can control that a little better. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1516137/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1471978] [NEW] test_relationships() uses subobject version instead of relationship version
Public bug reported: Part of test_relationships() is spent building the subobject tree of each nova object (http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/objects/test_objects.py#n1274). In _build_tree(), a tree is built with all objects in the nova registry, and then it finds the version of each subobject that this object should be holding (only down 1 level). This version that it should be holding needs to be determined by obj_relationships (or child_versions until https://bugs.launchpad.net/nova/+bug/1470154 is fixed). In _build_tree(), the versions it should be holding is determined by sub_obj_class.VERSION instead of what is in obj_relationships. This causes the static tree used in test_relationships to be testing against the most recent version of the subobjects instead of testing against the subobject version held in obj_relationships. ** 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/1471978 Title: test_relationships() uses subobject version instead of relationship version Status in OpenStack Compute (Nova): New Bug description: Part of test_relationships() is spent building the subobject tree of each nova object (http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/objects/test_objects.py#n1274). In _build_tree(), a tree is built with all objects in the nova registry, and then it finds the version of each subobject that this object should be holding (only down 1 level). This version that it should be holding needs to be determined by obj_relationships (or child_versions until https://bugs.launchpad.net/nova/+bug/1470154 is fixed). In _build_tree(), the versions it should be holding is determined by sub_obj_class.VERSION instead of what is in obj_relationships. This causes the static tree used in test_relationships to be testing against the most recent version of the subobjects instead of testing against the subobject version held in obj_relationships. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1471978/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1339885] [NEW] exceptions.check_message does not work
Public bug reported: When using exceptions.check_message to check it a connection was refused by an API, check_message will check to see if the exception's message contains Connection and refused. When a connection is refused, the message does not contain exactly Connection and refused, but rather Connection and refused). In this situation check_message does nothing and the exception is re-raised. To reproduce: Stop the Nova API Navigate to http://ip/admin/info/ Other notes: 1. Even if the error message contains Connection and refused exactly, the same error screen is shown, because the exception is re-raised in both situations, and is not being handled properly higher up. 2. The exception being raised when a connection is refused is ConnectionError, a Python built-in exception. 3. The only other situation where check_message is used is within Horizon is in https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/volumes/tables.py when a volume is deleted. When this occurs, the re-raised exception is properly handled, and a red error message is shown correctly. 4. The current use of check_message is not compatible with localization. The keywords checked for are not translated, so if the exception message is translated, the words will never match. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1339885 Title: exceptions.check_message does not work Status in OpenStack Dashboard (Horizon): New Bug description: When using exceptions.check_message to check it a connection was refused by an API, check_message will check to see if the exception's message contains Connection and refused. When a connection is refused, the message does not contain exactly Connection and refused, but rather Connection and refused). In this situation check_message does nothing and the exception is re-raised. To reproduce: Stop the Nova API Navigate to http://ip/admin/info/ Other notes: 1. Even if the error message contains Connection and refused exactly, the same error screen is shown, because the exception is re-raised in both situations, and is not being handled properly higher up. 2. The exception being raised when a connection is refused is ConnectionError, a Python built-in exception. 3. The only other situation where check_message is used is within Horizon is in https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/volumes/tables.py when a volume is deleted. When this occurs, the re-raised exception is properly handled, and a red error message is shown correctly. 4. The current use of check_message is not compatible with localization. The keywords checked for are not translated, so if the exception message is translated, the words will never match. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1339885/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1334734] [NEW] User creation error not descriptive
Public bug reported: When the creation of a user fails by some exceptions within Keystone, the error message given by Horizon is Error: Unable to create user. The error message within Keystone CLI shows detailed description of error. To replicate: 1. Raise an exception within keystone/keystone/identity/controllers.py by adding this line: def create_user(...): ... self.assert_admin(context) # Add this line raise exception.ValidationTimeStampError() ... 2. Restart keystone service 3a. Within CLI: keystone user-create --name=example --pass=examplepass --email=exam...@example.com Output: Timestamp not in expected format. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) 3b. Within Horizon: Create user with same information as CLI (add to any project and role) Output: Error: Unable to create user ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1334734 Title: User creation error not descriptive Status in OpenStack Dashboard (Horizon): New Bug description: When the creation of a user fails by some exceptions within Keystone, the error message given by Horizon is Error: Unable to create user. The error message within Keystone CLI shows detailed description of error. To replicate: 1. Raise an exception within keystone/keystone/identity/controllers.py by adding this line: def create_user(...): ... self.assert_admin(context) # Add this line raise exception.ValidationTimeStampError() ... 2. Restart keystone service 3a. Within CLI: keystone user-create --name=example --pass=examplepass --email=exam...@example.com Output: Timestamp not in expected format. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) 3b. Within Horizon: Create user with same information as CLI (add to any project and role) Output: Error: Unable to create user To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1334734/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
