[Yahoo-eng-team] [Bug 1477451] [NEW] Assumption that db drivers can ignore hints is false
Public bug reported: For hints, the documentation says that if the driver implementation doesn't filter by hints, they are handled at the controller level. But this assumption is false when using 'list users' and 'list groups' API. This was found while writing a Cassandra backend driver for Keystone. Similar could be done by commenting out lines from keystone/identity/backends/sql.py driver file which filters by hints. I am suspecting that the problem is at these two lines: https://github.com/openstack/keystone/blob/7a28fdb6385ec31e3d46fe63b22028e599ea66b3/keystone/identity/core.py#L429 I see two alternatives: either fix this, or change the documentation saying that hints filtering at higher (controller) level might not be enforced. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1477451 Title: Assumption that db drivers can ignore hints is false Status in Keystone: New Bug description: For hints, the documentation says that if the driver implementation doesn't filter by hints, they are handled at the controller level. But this assumption is false when using 'list users' and 'list groups' API. This was found while writing a Cassandra backend driver for Keystone. Similar could be done by commenting out lines from keystone/identity/backends/sql.py driver file which filters by hints. I am suspecting that the problem is at these two lines: https://github.com/openstack/keystone/blob/7a28fdb6385ec31e3d46fe63b22028e599ea66b3/keystone/identity/core.py#L429 I see two alternatives: either fix this, or change the documentation saying that hints filtering at higher (controller) level might not be enforced. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1477451/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1462242] [NEW] developer docs still have mention of bin/keystone-all
Public bug reported: Looks like there is no keystone-all file any more, but still, developer docs (installing.rst and developing.rst) talk about keystone-all file. The docs should be updated. Not sure if I should include documentation team as well, as these are developer docs. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1462242 Title: developer docs still have mention of bin/keystone-all Status in OpenStack Identity (Keystone): New Bug description: Looks like there is no keystone-all file any more, but still, developer docs (installing.rst and developing.rst) talk about keystone-all file. The docs should be updated. Not sure if I should include documentation team as well, as these are developer docs. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1462242/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1095271] Re: Cannot get/update/delete individual meta-data key for volume
Fixed already by this change: I512dad591d7d491eca54a230d3cc290d9a349e6f ?? Marking it as invalid.. ** Changed in: cinder 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/1095271 Title: Cannot get/update/delete individual meta-data key for volume Status in Cinder: Invalid Status in OpenStack Compute (Nova): Invalid Status in Python client library for Cinder: Fix Committed Bug description: This bug report is in reference to this comment https://bugs.launchpad.net/cinder/+bug/1046382/comments/2 Volumes can support arbitrary meta-data which can be set on create, but the current api, cinderclient does not expose any means to get/update/delete any individual metadata key. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1095271/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1367310] [NEW] Not supplying container format fails but still creates image in 'queued' state
Public bug reported: r@ra:~$ glance image-create --name="demoimg" --disk-format=qcow2 --property kernel_id=65c3fe11-dc90-40d0-93ca-6855bc2a83fd --property ramdisk_id=bec768bc-9eac-41b2-90f4-fd861b7b8a05 < base.qcow2 Request returned failure status 400. 400 Bad Request 400 Bad Request Invalid container format 'None' for image. (HTTP 400) But while running 'glance image-list', it still says there is an entry for this image, but in 'queued' state ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1367310 Title: Not supplying container format fails but still creates image in 'queued' state Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: r@ra:~$ glance image-create --name="demoimg" --disk-format=qcow2 --property kernel_id=65c3fe11-dc90-40d0-93ca-6855bc2a83fd --property ramdisk_id=bec768bc-9eac-41b2-90f4-fd861b7b8a05 < base.qcow2 Request returned failure status 400. 400 Bad Request 400 Bad Request Invalid container format 'None' for image. (HTTP 400) But while running 'glance image-list', it still says there is an entry for this image, but in 'queued' state To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1367310/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1365887] [NEW] Metadata filtering is broken
Public bug reported: When I make this change http://paste.openstack.org/show/106339/ to unit tests, the test fails. key3=a key-value pair is matched, but it shouldn't be. Also, there is no test case for different values of filter, except empty filter. The problem is , the def _match_any() is not checking if pattern_list is actually a list, or just a string. The solution will be to add a condition "pattern_list = [pattern_list] if isinstance(pattern_list, str)" Unit tests also must be added ** Affects: nova Importance: Undecided Assignee: Rushi Agrawal (rushiagr) Status: New ** Tags: low-hanging-fruit ** Description changed: - When I make this change to unit tests, the test fails. key3=a key-value - pair is matched, but it shouldn't be. + When I make this change + + http://paste.openstack.org/show/106339/ + + to unit tests, the test fails. key3=a key-value pair is matched, but it + shouldn't be. Also, there is no test case for different values of filter, except empty filter. The problem is , the def _match_any() is not checking if pattern_list is actually a list, or just a string. The solution will be to add a condition "pattern_list = [pattern_list] if isinstance(pattern_list, str)" Unit tests also must be added -- 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/1365887 Title: Metadata filtering is broken Status in OpenStack Compute (Nova): New Bug description: When I make this change http://paste.openstack.org/show/106339/ to unit tests, the test fails. key3=a key-value pair is matched, but it shouldn't be. Also, there is no test case for different values of filter, except empty filter. The problem is , the def _match_any() is not checking if pattern_list is actually a list, or just a string. The solution will be to add a condition "pattern_list = [pattern_list] if isinstance(pattern_list, str)" Unit tests also must be added To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1365887/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1364758] [NEW] Metadata filtering logic too tightly coupled with other code
Public bug reported: The def _get_all_instance_metadata() at https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2885 contains the logic for filtering a list of instances. The problem is, it also contains nova-specific code, e.g. policy checking. This method is being used by describe_tags of the EC2 API too. In an effort to add more resources (e.g. voumes, volume snapshots) to the EC2 API, the filtering logic needs to be abstracted out into a common function for all resources (e.g. get_all_resource_metadata). Another issue is, the functioning of this filtering logic is only minimally tested in nova's core code. Strangely the filtering logic is extensively tested in the EC2 API tests, which is the wrong place to test them. As a part of fixing this bug, unit tests to test this new common function should be added too. ** Affects: nova Importance: Undecided Assignee: Rushi Agrawal (rushiagr) Status: New ** Tags: ec2 low-hanging-fruit 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/1364758 Title: Metadata filtering logic too tightly coupled with other code Status in OpenStack Compute (Nova): New Bug description: The def _get_all_instance_metadata() at https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2885 contains the logic for filtering a list of instances. The problem is, it also contains nova-specific code, e.g. policy checking. This method is being used by describe_tags of the EC2 API too. In an effort to add more resources (e.g. voumes, volume snapshots) to the EC2 API, the filtering logic needs to be abstracted out into a common function for all resources (e.g. get_all_resource_metadata). Another issue is, the functioning of this filtering logic is only minimally tested in nova's core code. Strangely the filtering logic is extensively tested in the EC2 API tests, which is the wrong place to test them. As a part of fixing this bug, unit tests to test this new common function should be added too. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1364758/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1348244] Re: debug log messages need to be unicode
Marking as invalid in Cinder.
** Changed in: cinder
Milestone: juno-3 => None
** Changed in: cinder
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/1348244
Title:
debug log messages need to be unicode
Status in Cinder:
Invalid
Status in OpenStack Compute (Nova):
In Progress
Status in Oslo - a Library of Common OpenStack Code:
In Progress
Bug description:
Debug logs should be:
LOG.debug("message") should be LOG.debug(u"message")
Before the translation of debug log messages was removed, the
translation was returning unicode. Now that they are no longer
translated they need to be explicitly marked as unicode.
This was confirmed by discussion with dhellman. See
2014-07-23T13:48:23 in this log http://eavesdrop.openstack.org/irclogs
/%23openstack-oslo/%23openstack-oslo.2014-07-23.log
The problem was discovered when an exception was used as replacement
text in a debug log message:
LOG.debug("Failed to mount image %(ex)s)", {'ex': e})
In particular it was discovered as part of enabling lazy translation,
where the exception message is replaced with an object that does not
support str(). Note that this would also fail without lazy enabled,
if a translation for the exception message was provided that was
unicode.
Example trace:
Traceback (most recent call last):
File "nova/tests/virt/disk/test_api.py", line 78, in
test_can_resize_need_fs_type_specified
self.assertFalse(api.is_image_partitionless(imgfile, use_cow=True))
File "nova/virt/disk/api.py", line 208, in is_image_partitionless
fs.setup()
File "nova/virt/disk/vfs/localfs.py", line 80, in setup
LOG.debug("Failed to mount image %(ex)s)", {'ex': e})
File "/usr/lib/python2.7/logging/__init__.py", line 1412, in debug
self.logger.debug(msg, *args, **kwargs)
File "/usr/lib/python2.7/logging/__init__.py", line 1128, in debug
self._log(DEBUG, msg, args, **kwargs)
File "/usr/lib/python2.7/logging/__init__.py", line 1258, in _log
self.handle(record)
File "/usr/lib/python2.7/logging/__init__.py", line 1268, in handle
self.callHandlers(record)
File "/usr/lib/python2.7/logging/__init__.py", line 1308, in callHandlers
hdlr.handle(record)
File "nova/test.py", line 212, in handle
self.format(record)
File "/usr/lib/python2.7/logging/__init__.py", line 723, in format
return fmt.format(record)
File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
record.message = record.getMessage()
File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
msg = msg % self.args
File
"/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo/i18n/_message.py",
line 167, in __str__
raise UnicodeError(msg)
UnicodeError: Message objects do not support str() because they may contain
non-ascii characters. Please use unicode() or translate() instead.
==
FAIL: nova.tests.virt.disk.test_api.APITestCase.test_resize2fs_e2fsck_fails
tags: worker-3
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1296627] [NEW] Instance snapshots shown in 'boot from image' list
Public bug reported: When we store a snapshot of an instance, and then try to create an instance, that instance snapshot is shown in two list, namely 'boot from snapshot' and 'boot from image' list. This is confusing to the user. We should report it only in snapshot list. I can see that the instance snapshots are having an attribute 'instance_uuid', which the glance images don't have. We can filter out the snapshot from volumes using this method. Any other suggestions? ** 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/1296627 Title: Instance snapshots shown in 'boot from image' list Status in OpenStack Dashboard (Horizon): New Bug description: When we store a snapshot of an instance, and then try to create an instance, that instance snapshot is shown in two list, namely 'boot from snapshot' and 'boot from image' list. This is confusing to the user. We should report it only in snapshot list. I can see that the instance snapshots are having an attribute 'instance_uuid', which the glance images don't have. We can filter out the snapshot from volumes using this method. Any other suggestions? To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1296627/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1282987] [NEW] Page numbers and back button while listing resources in a paginated fashion
Public bug reported: Let's say I have created 45 instances, and the 'items per page' value is 20 (which is also the default value). The user will see first 20 instances listed in horizon, with a little 'more' button to see the next 20 rows. BUT there is no way on the UI to go to the last page (except for clicking the 'back' button in the browser). ALSO, there are no page numbers, so the user don't know how many more pages are ahead (and behind!). Additional enhancement: Show a 'displaying 21-40 of 45 items' just before where the page numbers are specified. Steps to reproduce: create 5 instances, and change the 'items per page' to '2' in the 'settings' section. ** 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/1282987 Title: Page numbers and back button while listing resources in a paginated fashion Status in OpenStack Dashboard (Horizon): New Bug description: Let's say I have created 45 instances, and the 'items per page' value is 20 (which is also the default value). The user will see first 20 instances listed in horizon, with a little 'more' button to see the next 20 rows. BUT there is no way on the UI to go to the last page (except for clicking the 'back' button in the browser). ALSO, there are no page numbers, so the user don't know how many more pages are ahead (and behind!). Additional enhancement: Show a 'displaying 21-40 of 45 items' just before where the page numbers are specified. Steps to reproduce: create 5 instances, and change the 'items per page' to '2' in the 'settings' section. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1282987/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1280948] [NEW] [EC2] Volume create time rounded off
Public bug reported: While creating volume, the return value says that volume creation time is dd-mm-yyThh:mm:ss.s, but while listing volumes at a later point of time, it changes to dd-mm-yyThh:mm:ss.0 Doesn't look like a big issue though, but nevertheless shouldn't happen. I'd say the simplest solution should be to return dd-mm- yyThh:mm:ss.0 at the create-time itself. ** Affects: nova Importance: Low Status: New ** Tags: ec2 -- 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/1280948 Title: [EC2] Volume create time rounded off Status in OpenStack Compute (Nova): New Bug description: While creating volume, the return value says that volume creation time is dd-mm-yyThh:mm:ss.s, but while listing volumes at a later point of time, it changes to dd-mm-yyThh:mm:ss.0 Doesn't look like a big issue though, but nevertheless shouldn't happen. I'd say the simplest solution should be to return dd-mm- yyThh:mm:ss.0 at the create-time itself. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1280948/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1280572] [NEW] [EC2] Attaching volume returns volume is 'detached' in response
Public bug reported: While attaching the volume, the API response is that the volume state is detached, while it should be 'attaching' as per EC2's API docs. http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference- query-AttachVolume.html ** Affects: nova Importance: Undecided Assignee: Rushi Agrawal (rushiagr) Status: Confirmed ** Tags: ec2 volumes ** Changed in: nova Status: New => Confirmed -- 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/1280572 Title: [EC2] Attaching volume returns volume is 'detached' in response Status in OpenStack Compute (Nova): Confirmed Bug description: While attaching the volume, the API response is that the volume state is detached, while it should be 'attaching' as per EC2's API docs. http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference- query-AttachVolume.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1280572/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1273983] [NEW] Pagination not implemented for DescribeTags
Public bug reported: Amazon's API tells that it has MaxResults and NextToken tags for pagination. There is no such thing in our API http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeTags.html ** Affects: nova Importance: Undecided Status: New ** Tags: ec2 -- 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/1273983 Title: Pagination not implemented for DescribeTags Status in OpenStack Compute (Nova): New Bug description: Amazon's API tells that it has MaxResults and NextToken tags for pagination. There is no such thing in our API http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeTags.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1273983/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1259711] Re: Volume type or nova flavor extra_spec containing '/' can't be deleted
Skipped reading the first line of bug description, that there is already
a bug registered against Nova.
** 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/1259711
Title:
Volume type or nova flavor extra_spec containing '/' can't be deleted
Status in Cinder:
Confirmed
Bug description:
Written based on Nova bug 1256119.
It is possible to set an extra spec for a volume type containing a '/'
that then cannot be deleted.
$ cinder type-create test
+--+--+
| ID | Name |
+--+--+
| ff8b49fb-3883-428e-a942-61fa34633c23 | test |
+--+--+
$ cinder type-key test set 'a/b=c'
$ cinder extra-specs-list
+--+--++
| ID | Name | extra_specs |
+--+--++
| ff8b49fb-3883-428e-a942-61fa34633c23 | test | {u'a/b': u'c'} |
+--+--++
$ cinder --debug type-key test unset 'a/b'
...snip...
REQ: curl -i
http://192.168.122.100:8776/v2/b3d6b9a5b8f04df08bf33714fe99d52a/types/ff8b49fb-3883-428e-a942-61fa34633c23/extra_specs/a/b
-X DELETE -H "X-Auth-Project-Id: demo" -H "User-Agent: python-
cinderclient" -H "Accept: application/json" -H "X-Auth-Token:
MI...ITF"
DEBUG:cinderclient.client:
REQ: curl -i
http://192.168.122.100:8776/v2/b3d6b9a5b8f04df08bf33714fe99d52a/types/ff8b49fb-3883-428e-a942-61fa34633c23/extra_specs/a/b
-X DELETE -H "X-Auth-Project-Id: demo" -H "User-Agent: python-cinderclient" -H
"Accept: application/json" -H "X-Auth-Token: MI...ITF"
RESP: [404] CaseInsensitiveDict({'date': 'Tue, 10 Dec 2013 22:07:01 GMT',
'content-length': '52', 'content-type': 'text/plain; charset=UTF-8'})
RESP BODY: 404 Not Found
The resource could not be found.
DEBUG:cinderclient.client:RESP: [404] CaseInsensitiveDict({'date': 'Tue, 10
Dec 2013 22:07:01 GMT', 'content-length': '52', 'content-type': 'text/plain;
charset=UTF-8'})
RESP BODY: 404 Not Found
The resource could not be found.
ERROR: Not found (HTTP 404)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1259711/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1259711] Re: Volume type or image flavor extra_spec containing '/' can't be deleted
** Summary changed:
- Volume type extra_spec containing '/' can't be deleted
+ Volume type or image flavor extra_spec containing '/' can't be deleted
** Also 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/1259711
Title:
Volume type or image flavor extra_spec containing '/' can't be deleted
Status in Cinder:
Confirmed
Status in OpenStack Compute (Nova):
New
Bug description:
Written based on Nova bug 1256119.
It is possible to set an extra spec for a volume type containing a '/'
that then cannot be deleted.
$ cinder type-create test
+--+--+
| ID | Name |
+--+--+
| ff8b49fb-3883-428e-a942-61fa34633c23 | test |
+--+--+
$ cinder type-key test set 'a/b=c'
$ cinder extra-specs-list
+--+--++
| ID | Name | extra_specs |
+--+--++
| ff8b49fb-3883-428e-a942-61fa34633c23 | test | {u'a/b': u'c'} |
+--+--++
$ cinder --debug type-key test unset 'a/b'
...snip...
REQ: curl -i
http://192.168.122.100:8776/v2/b3d6b9a5b8f04df08bf33714fe99d52a/types/ff8b49fb-3883-428e-a942-61fa34633c23/extra_specs/a/b
-X DELETE -H "X-Auth-Project-Id: demo" -H "User-Agent: python-
cinderclient" -H "Accept: application/json" -H "X-Auth-Token:
MI...ITF"
DEBUG:cinderclient.client:
REQ: curl -i
http://192.168.122.100:8776/v2/b3d6b9a5b8f04df08bf33714fe99d52a/types/ff8b49fb-3883-428e-a942-61fa34633c23/extra_specs/a/b
-X DELETE -H "X-Auth-Project-Id: demo" -H "User-Agent: python-cinderclient" -H
"Accept: application/json" -H "X-Auth-Token: MI...ITF"
RESP: [404] CaseInsensitiveDict({'date': 'Tue, 10 Dec 2013 22:07:01 GMT',
'content-length': '52', 'content-type': 'text/plain; charset=UTF-8'})
RESP BODY: 404 Not Found
The resource could not be found.
DEBUG:cinderclient.client:RESP: [404] CaseInsensitiveDict({'date': 'Tue, 10
Dec 2013 22:07:01 GMT', 'content-length': '52', 'content-type': 'text/plain;
charset=UTF-8'})
RESP BODY: 404 Not Found
The resource could not be found.
ERROR: Not found (HTTP 404)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1259711/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1190149] Re: Token auth fails when token is larger than 8k
** Also affects: cinder
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/1190149
Title:
Token auth fails when token is larger than 8k
Status in Cinder:
New
Status in OpenStack Identity (Keystone):
Fix Released
Status in OpenStack Compute (Nova):
Fix Released
Bug description:
The following tests fail when there are 8 or more endpoints registered with
keystone
tempest.api.compute.test_auth_token.AuthTokenTestJSON.test_v3_token
tempest.api.compute.test_auth_token.AuthTokenTestXML.test_v3_token
Steps to reproduce:
- run devstack with the following services (the heat h-* apis push the
endpoint count over the threshold
ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,n-net
- run the failing tempest tests, eg
testr run test_v3_token
- results in the following errors:
ERROR: tempest.api.compute.test_auth_token.AuthTokenTestJSON.test_v3_token
tags: worker-0
--
Traceback (most recent call last):
File "tempest/api/compute/test_auth_token.py", line 48, in test_v3_token
self.servers_v3.list_servers()
File "tempest/services/compute/json/servers_client.py", line 138, in
list_servers
resp, body = self.get(url)
File "tempest/common/rest_client.py", line 269, in get
return self.request('GET', url, headers)
File "tempest/common/rest_client.py", line 394, in request
resp, resp_body)
File "tempest/common/rest_client.py", line 443, in _error_checker
resp_body = self._parse_resp(resp_body)
File "tempest/common/rest_client.py", line 327, in _parse_resp
return json.loads(body)
File "/usr/lib64/python2.7/json/__init__.py", line 326, in loads
return _default_decoder.decode(s)
File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python2.7/json/decoder.py", line 384, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
==
ERROR: tempest.api.compute.test_auth_token.AuthTokenTestXML.test_v3_token
tags: worker-0
--
Traceback (most recent call last):
File "tempest/api/compute/test_auth_token.py", line 48, in test_v3_token
self.servers_v3.list_servers()
File "tempest/services/compute/xml/servers_client.py", line 181, in
list_servers
resp, body = self.get(url, self.headers)
File "tempest/common/rest_client.py", line 269, in get
return self.request('GET', url, headers)
File "tempest/common/rest_client.py", line 394, in request
resp, resp_body)
File "tempest/common/rest_client.py", line 443, in _error_checker
resp_body = self._parse_resp(resp_body)
File "tempest/common/rest_client.py", line 519, in _parse_resp
return xml_to_json(etree.fromstring(body))
File "lxml.etree.pyx", line 2993, in lxml.etree.fromstring
(src/lxml/lxml.etree.c:63285)
File "parser.pxi", line 1617, in lxml.etree._parseMemoryDocument
(src/lxml/lxml.etree.c:93571)
File "parser.pxi", line 1495, in lxml.etree._parseDoc
(src/lxml/lxml.etree.c:92370)
File "parser.pxi", line 1011, in lxml.etree._BaseParser._parseDoc
(src/lxml/lxml.etree.c:89010)
File "parser.pxi", line 577, in
lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:84711)
File "parser.pxi", line 676, in lxml.etree._handleParseResult
(src/lxml/lxml.etree.c:85816)
File "parser.pxi", line 627, in lxml.etree._raiseParseError
(src/lxml/lxml.etree.c:85308)
XMLSyntaxError: None
Ran 2 tests in 2.497s (+0.278s)
FAILED (id=214, failures=2)
- run keystone endpoint-delete on endpoints until there is 7 endpoints
- failing tests should now pass
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1190149/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-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 1262176] [NEW] EC2: 'io1' type volume should also return IOPS associated with it
Public bug reported: This patch https://review.openstack.org/#/c/61041 exposes volume type in the EC2 API. Amazon's API documentation says that if the volume type is 'io1', that is, if the volume has guaranteed IOPS set for it, a 'DescribeVolumes' call should return the IOPS for such volumes. We need to add that. ** Affects: nova Importance: Undecided Status: New ** Tags: ec2 ** Tags added: ec2 -- 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/1262176 Title: EC2: 'io1' type volume should also return IOPS associated with it Status in OpenStack Compute (Nova): New Bug description: This patch https://review.openstack.org/#/c/61041 exposes volume type in the EC2 API. Amazon's API documentation says that if the volume type is 'io1', that is, if the volume has guaranteed IOPS set for it, a 'DescribeVolumes' call should return the IOPS for such volumes. We need to add that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1262176/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1259860] [NEW] Apparmor doesn't allow volume to attach in 13.10 Ubuntu
Public bug reported: Host machine: Ubuntu desktop 13.10 Setup: devstack When I try to attach a volume to an instance via the CLI, the volume doesn't get attached. It's status still shows 'available'. While the logs tell that 'device /dev/vdx is busy'. Here are the logs from screen http://paste.openstack.org/show/54808/ I looked into /var/log/libvirt/libvirtd.log and found this: http://paste.openstack.org/show/54809/ As per this guy's question at ask.openstack.org, https://ask.openstack.org/en/question/7128/deviceisbusy-the-supplied-device-vdx-is-busy/ I uninstalled apparmor, and restarted and tried again. EVERYTHING went smooth! Looks like some issue with apparmor conflicting with libvirt. ** 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/1259860 Title: Apparmor doesn't allow volume to attach in 13.10 Ubuntu Status in OpenStack Compute (Nova): New Bug description: Host machine: Ubuntu desktop 13.10 Setup: devstack When I try to attach a volume to an instance via the CLI, the volume doesn't get attached. It's status still shows 'available'. While the logs tell that 'device /dev/vdx is busy'. Here are the logs from screen http://paste.openstack.org/show/54808/ I looked into /var/log/libvirt/libvirtd.log and found this: http://paste.openstack.org/show/54809/ As per this guy's question at ask.openstack.org, https://ask.openstack.org/en/question/7128/deviceisbusy-the-supplied-device-vdx-is-busy/ I uninstalled apparmor, and restarted and tried again. EVERYTHING went smooth! Looks like some issue with apparmor conflicting with libvirt. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1259860/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1259438] [NEW] EC2 API doesn't return Cinder volume 'type'
Public bug reported: When one create a volume with volume type 'standard', the EC2 API doesn't reflect this. The API response still shows volume.type as None. ** Affects: nova Importance: Undecided Assignee: Rushi Agrawal (rushiagr) Status: New ** Tags: ec2 low-hanging-fruit volumes ** Changed in: nova Assignee: (unassigned) => Rushi Agrawal (rushiagr) ** Tags added: ec2 low-hanging-fruit volumes -- 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/1259438 Title: EC2 API doesn't return Cinder volume 'type' Status in OpenStack Compute (Nova): New Bug description: When one create a volume with volume type 'standard', the EC2 API doesn't reflect this. The API response still shows volume.type as None. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1259438/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-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 1133148] Re: Keystone return different-length keys while creating request body manually and when creating request by json.dumps
Sorry, my bad. Wrong formatting of auth_dict (tenantId should not be a
key for the value of passwordCredentials
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1133148
Title:
Keystone return different-length keys while creating request body
manually and when creating request by json.dumps
Status in OpenStack Identity (Keystone):
Invalid
Bug description:
The gettoken() function is given at the last. While calling the
function, I just changed params = authstring to params = authstring2
for the two executions given below
root@ubuntu:~# python -i gettoken.py
>>> gettoken()
{"auth": {"passwordCredentials": {"username": "demo", "password": "nova",
"tenantId": "44a4a190db80429985528e24ca811a28"}}}
u'MIIKkgYJKoZIhvcNAQcCoIIKgzCCCn8CAQExCTAHBgUrDgMCGjCCCWsGCSqGSIb3DQEHAaCCCVwEgglYeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMi0yNlQwNjo0OToyNC40MTY3NzIiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTI3VDA2OjQ5OjI0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjQ0YTRhMTkwZGI4MDQyOTk4NTUyOGUyNGNhODExYTI4In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuNjMuMTY1LjIyOjg3NzQvdjIvNDRhNGExOTBkYjgwNDI5OTg1NTI4ZTI0Y2E4MTFhMjgiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuNjMuMTY1LjIyOjg3NzQvdjIvNDRhNGExOTBkYjgwNDI5OTg1NTI4ZTI0Y2E4MTFhMjgiLCAiaWQiOiAiNWE0MmZjODUwZTFiNDVhY2FjMjViN2YxOWEyMjUzZWIiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6ODc3NC92Mi80NGE0YTE5MGRiODA0Mjk5ODU1MjhlMjRjYTgxMWEyOCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6MzMzMyIsICJpZCI6ICI2OGQ0NWMxYzViZGM0MWRmOWVmMGVhOTk0MTI2ZjMwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjYzLjE2NS4yMjozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuNjMuMTY1LjIyOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuNjMuMTY1LjIyOjkyOTIiLCAiaWQiOiAiNTI0N2U3Y2I4ZTkzNDYyZmEwMTdjYjA1Mzk0NTdjMGQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6ODc3Ni92MS80NGE0YTE5MGRiODA0Mjk5ODU1MjhlMjRjYTgxMWEyOCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6ODc3Ni92MS80NGE0YTE5MGRiODA0Mjk5ODU1MjhlMjRjYTgxMWEyOCIsICJpZCI6ICIzMWM3MWU4ZTQ5MmY0MDQ4OWI0NDVkYzkwZWRjM2NhZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjYzLjE2NS4yMjo4Nzc2L3YxLzQ0YTRhMTkwZGI4MDQyOTk4NTUyOGUyNGNhODExYTI4In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI3ZjljYTMzZjZjZTk0NDEwYjY4YjNiZjlmYzA5NjA0NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjYzLjE2NS4yMjo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMC42My4xNjUuMjI6NTAwMC92Mi4wIiwgImlkIjogIjI0ODdmYzg1ZTc2MTQzOGU4MDJiOThiY2EwMDFkYmE5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuNjMuMTY1LjIyOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNzg3YzRlZDRlNmQ0NDhhZTkyYmE1MGM4MTI5YjVhMTYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiZWVmYWYwNDcxNDhjNDA0OGJhYWY3OTRmYzBmYTUxN2MiLCAiMTEzZWY4YzY5YjZiNGMxYzliMDUzZWZkY2U0ZThhMzUiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBjOvtn8VK77k-JFVBxvv-7mYeDw+Zx3BO8pMZ3SoZ-93t7RqO9I5gJ8oyE8pRRzzncJ2+NikRbehjbUcpwS9Fx4hooZz-QBrQHYkJBNaVLPX2WrD6-GpRiVNZQXaK1ai6Jf4zREuFcMR7cJHWrdj4icZqMHd0N+52lJgjZkHorEQ=='
>>>
root@ubuntu:~# python -i gettoken.py
>>> gettoken()
{"auth": {"passwordCredentials": {"username": "demo", "password": "nova",
"tenantId": "44a4a190db80429985528e24ca811a28"}}}
u'MIICbAYJKoZIhvcNAQcCoIICXTCCAlkCAQExCTAHBgUrDgMCGjCCAUUGCSqGSIb3DQEHAaCCATYEggEyeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMi0yNlQwNjo0OTo1Mi41Njk0MDQiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTI3VDA2OjQ5OjUyWiIsICJpZCI6ICJwbGFjZWhvbGRlciJ9LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVz
[Yahoo-eng-team] [Bug 715102] Re: creation of a simple file based volume driver in nova/volume/driver.py
** 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/715102 Title: creation of a simple file based volume driver in nova/volume/driver.py Status in OpenStack Compute (Nova): Invalid Bug description: I think we need the possibility to also save volumes on mounted NFS exports (or some other stuff locally mounted). I tried to create a simple file based volume driver, creating new images with qemu-img and removing them with rm. Is this sufficient? At the moment I think only check_for_setup_error() is missing, I'll add this soon (checking for the existence of qemu-img and checking if the given mountpoint is mounted and is writable by nova). Please give me some feedback and more ideas... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/715102/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
