Description of problem: after I update a volume as read only I would like a way to know that the volume is read only. can we add a "read only/read-write" field into cinder show? Version-Release number of selected component (if applicable): [root@orange-vdsf ~(keystone_admin)]# rpm -qa |grep cinder python-cinderclient-1.0.7-2.el7.noarch openstack-cinder-2014.1-0.6.b3.el7.noarch python-cinder-2014.1-0.6.b3.el7.noarch How reproducible: 100^ Steps to Reproduce: 1. create a volume 2. update the volume as read-only 3. run cinder list/ cinder show Actual results: we have no way of knowing of the image is read-only or read-write Expected results: we should add a field to allow us to see if a volume is read-only Additional info: [root@orange-vdsf ~(keystone_admin)]# cinder create --display-name dafna 10 +---------------------+--------------------------------------+ | Property | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | created_at | 2014-04-03T13:16:03.137237 | | display_description | None | | display_name | dafna | | encrypted | False | | id | 51c841ec-24a5-49fe-8441-01593b39b2f7 | | metadata | {} | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | volume_type | None | +---------------------+--------------------------------------+ [root@orange-vdsf ~(keystone_admin)]# cinder list +--------------------------------------+-----------+--------------+------+-------------+----------+-------------+ | ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+--------------+------+-------------+----------+-------------+ | 51c841ec-24a5-49fe-8441-01593b39b2f7 | available | dafna | 10 | None | false | | | 54d28f61-2f0f-4be4-8e27-855a50a50c33 | available | emptyVol | 1 | None | false | | | 82a7a825-6106-4139-9bc8-4334ccc38e85 | available | volFromImage | 1 | None | true | | +--------------------------------------+-----------+--------------+------+-------------+----------+-------------+ [root@orange-vdsf ~(keystone_admin)]# cinder readonly-mode-update 51c841ec-24a5-49fe-8441-01593b39b2f7 true [root@orange-vdsf ~(keystone_admin)]# cinder list +--------------------------------------+-----------+--------------+------+-------------+----------+-------------+ | ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | +--------------------------------------+-----------+--------------+------+-------------+----------+-------------+ | 51c841ec-24a5-49fe-8441-01593b39b2f7 | available | dafna | 10 | None | false | | | 54d28f61-2f0f-4be4-8e27-855a50a50c33 | available | emptyVol | 1 | None | false | | | 82a7a825-6106-4139-9bc8-4334ccc38e85 | available | volFromImage | 1 | None | true | | +--------------------------------------+-----------+--------------+------+-------------+----------+-------------+ [root@orange-vdsf ~(keystone_admin)]# cinder show 51c841ec-24a5-49fe-8441-01593b39b2f7 +--------------------------------+--------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | created_at | 2014-04-03T13:16:03.000000 | | display_description | None | | display_name | dafna | | encrypted | False | | id | 51c841ec-24a5-49fe-8441-01593b39b2f7 | | metadata | {u'readonly': u'True'} | | os-vol-host-attr:host | orange-vdsf.qa.lab.tlv.redhat.com | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | f66db525566a4cd9b04a3ad58ebda638 | | size | 10 | | snapshot_id | None | | source_volid | None | | status | available | | volume_type | None | +--------------------------------+--------------------------------------+
This is an upstream RFE. Please file upstream and link the external tracker: https://bugs.launchpad.net/python-cinderclient/+filebug Also, "... I would like a way to know ..." doesn't sound very "urgent" to me.
The output pasted in the description shows that this already exists: [root@orange-vdsf ~(keystone_admin)]# cinder show 51c841ec-24a5-49fe-8441-01593b39b2f7 ... | metadata | {u'readonly': u'True'} | ...
yes, I did not notice that which kinda means that it's perhaps not obvious enough? I think that changing a volume status from read to read-only and other way round is important and should be very clearly indicated to the user. not sure how it should be done but adding it to metadata is not clear enough.
This is a strong usability bug - I do not think that the priority should be lowered or leaving this up for a launchpad bug. here are some scenarios that can happen: 1. If the only way that we mark a disk as read-only is in metadata, even creating a script that would give me all the read-only volumes is complicated (not to mention implementation on "list" command would probably not happen) 2. if I have multiple sysadmins and one changed a read-only disk to writable and there is no obvious way that we mark the disk, it can cause data loss or a data leak (example: If I am a banker and I need to issue a new report every month from a template that my sysadmin saves on a read-only volume. if someone changed the volume from a read-only to writable I may accidentally write on the original template report exposing information I should not (data leak) or destroy a report other people need to use (data loss)). 3. debugging when a user cannot write because they, or someone else changed the volume to read-only may take longer (even result in a call to GSS).
*** Bug 1087033 has been marked as a duplicate of this bug. ***
(In reply to Dafna Ron from comment #4) > This is a strong usability bug - I do not think that the priority should be > lowered or leaving this up for a launchpad bug. It is a usability bug indeed. Let me show you high priority (not urgent) bug: https://bugzilla.redhat.com/show_bug.cgi?id=1087181 Are you saying this has comparable priority? I don't even know what to say about "leaving this up for launchpad bug" because that's basically saying "I have no idea how we do stuff". RDO is a distribution of upstream code and thus we solve bugs upstream. If something breaks our distribution, we *track* it in BZ, but unless it's a packaging problem, solution is still upstream. This particular bug doesn't break anything, thus we solve it upstream like everything else. Since you insist tracking this downstream has some added value, we do track it here in BZ, but the solution must be an upstream one. Report your concerns there, not here. Also, there is already a patch proposed upstream, so you can engage in discussion and make sure the solution is sufficient.
The bug was rejected upstream.