On 09/04/2012 06:15 PM, Simon Grinberg wrote: > 12. CLI: Can't update bootable attribute in any way, but I don't even know which method is the correct one due to the error messages: > > Direct attempt: > [RHEVM shell (connected)]# update disk bc2454d0-2539-41c3-85c2-91cfbdfbede3 --bootable True > > error: Start tag expected, '<' not found, line 1, column 1
the reason for that is response returned in 'content-type': '*/*' - yaml
note: update of disk from /api/disks/xxx yet supported by backend, see [1] [1] http://lists.ovirt.org/pipermail/engine-devel/2012-September/002427.html
[RHEVM shell (connected)]# list disks id : 2d54fc03-20c0-4196-8a91-4e24ff91b3d0 name : foo [RHEVM shell (connected)]# update disk 2d54fc03-20c0-4196-8a91-4e24ff91b3d0 --bootable True error: disk "2d54fc03-20c0-4196-8a91-4e24ff91b3d0" is immutable. what can i understand from this error?
(In reply to comment #4) > [RHEVM shell (connected)]# list disks > > id : 2d54fc03-20c0-4196-8a91-4e24ff91b3d0 > name : foo > > [RHEVM shell (connected)]# update disk 2d54fc03-20c0-4196-8a91-4e24ff91b3d0 > --bootable True > > > error: disk "2d54fc03-20c0-4196-8a91-4e24ff91b3d0" is immutable. > > what can i understand from this error? the meaning of 'immutable' - can't be changed, and this is correct as disk/s /api/disks/xxx cannot be changed, it can only be changed when in context of vm, you could see it by: [oVirt shell (connected)]# help update The following object types are available: * cdrom (contexts: [['vm']]) * cluster (contexts: [[]]) * datacenter (contexts: [[]]) * disk (contexts: [['vm']]) ... - as you can see ^ disk is updatable only when in context of vm.
(In reply to comment #5) > (In reply to comment #4) > > [RHEVM shell (connected)]# list disks > > > > id : 2d54fc03-20c0-4196-8a91-4e24ff91b3d0 > > name : foo > > > > [RHEVM shell (connected)]# update disk 2d54fc03-20c0-4196-8a91-4e24ff91b3d0 > > --bootable True > > > > > > error: disk "2d54fc03-20c0-4196-8a91-4e24ff91b3d0" is immutable. > > > > what can i understand from this error? > > the meaning of 'immutable' - can't be changed, and this is correct as > disk/s /api/disks/xxx cannot be changed, it can only be changed when in > context > of vm, you could see it by: > > [oVirt shell (connected)]# help update > > The following object types are available: > > * cdrom (contexts: [['vm']]) > * cluster (contexts: [[]]) > * datacenter (contexts: [[]]) > * disk (contexts: [['vm']]) > ... > > - as you can see ^ disk is updatable only when in context of vm. It is not true to assume that all CLI users are programmers . I would rephrase this word ( immutable ) and use more common term .
[RHEVM shell (connected)]# update disk eba21b14-a124-44f6-96cd-3132beeab958 --bootable true error: disk "eba21b14-a124-44f6-96cd-3132beeab958" is immutable. Simon , please decide if this error message is acceptable .
(In reply to comment #8) > [RHEVM shell (connected)]# update disk eba21b14-a124-44f6-96cd-3132beeab958 > --bootable true > > > error: disk "eba21b14-a124-44f6-96cd-3132beeab958" is immutable. > > > Simon , please decide if this error message is acceptable . First 10 results in Google return: 'An immutable object is an object whose state cannot be modified' Like you, I prefer more common English, but we can wait until an external user complains on the term used. I'm closing this as current release.
Verified on SI28.1 (3.1.4) [RHEVM shell (connected)]# info backend version: 3.1 sdk version : 3.1.0.16 cli version : 3.1.1.2 python version : 2.6.6.final.0 1) Only option provided by the auto completion (update disk <id>) is --vm-identifier 2) Using the correct way (as mentioned in comment #7 works: [RHEVM shell (connected)]# update disk 5c0b8923-acd9-433e-b8b4-14726fdba8da --vm-identifier Migrations_VM-2 --bootable false id : 5c0b8923-acd9-433e-b8b4-14726fdba8da name : Migrations_VM-2_Disk1 active : True actual_size : 8589934592 alias : Migrations_VM-2_Disk1 bootable : False format : cow image_id : b8d7d1b4-00a2-4eec-a4ea-a7153221f22f interface : virtio propagate_errors : False provisioned_size : 10737418240 quota-id : 00000000-0000-0000-0000-000000000000 shareable : False size : 10737418240 sparse : True status-state : ok storage_domains-storage_domain-id: 13e08082-0d81-46b8-a0ee-999773210702 vm-id : e447e1b4-381d-4aa4-bf9a-93e9f64cd241 wipe_after_delete : False
(In reply to comment #10) > Verified on SI28.1 (3.1.4) > [RHEVM shell (connected)]# info > > backend version: 3.1 > sdk version : 3.1.0.16 > cli version : 3.1.1.2 > python version : 2.6.6.final.0 > > > 1) Only option provided by the auto completion (update disk <id>) is > --vm-identifier auto-completion is context-aware since disk exist in two places, [1] & [2] it's creates logical split in tree, i.e your flow option resolution happens in two steps: 1. you let system know that you refer to the disk in context of vm [1] 2. you see update-able option for this case, btw it works the same in all other flow where entity residence is ambiguous. [1] /api/vms/xxx/disks/yyy [2] /api/disks/yyy > 2) Using the correct way (as mentioned in comment #7 works: > > [RHEVM shell (connected)]# update disk 5c0b8923-acd9-433e-b8b4-14726fdba8da > --vm-identifier Migrations_VM-2 --bootable false > > id : 5c0b8923-acd9-433e-b8b4-14726fdba8da > name : Migrations_VM-2_Disk1 > active : True > actual_size : 8589934592 > alias : Migrations_VM-2_Disk1 > bootable : False > format : cow > image_id : b8d7d1b4-00a2-4eec-a4ea-a7153221f22f > interface : virtio > propagate_errors : False > provisioned_size : 10737418240 > quota-id : 00000000-0000-0000-0000-000000000000 > shareable : False > size : 10737418240 > sparse : True > status-state : ok > storage_domains-storage_domain-id: 13e08082-0d81-46b8-a0ee-999773210702 > vm-id : e447e1b4-381d-4aa4-bf9a-93e9f64cd241 > wipe_after_delete : False