Re: [Engine-devel] Disk Permissions Feature
1. According to the wiki, these are the new Action Groups that will be added: CREATE_DISK - AddDisk, AddDiskToVm EDIT_DISK_PROPERTIES - UpdateDisk, UpdateVM, Activate/Deactivate ATTACH_DISK - AttachDiskToVm CONFIGURE_DISK_STORAGE - MoveOrCopyDisk DELETE_DISK - RemoveDisk, RemoveVm Currently we have: CONFIGURE_VM_STORAGE - AddDiskToVm, RemoveDisksFromVm, UpdateVmDisk So, since AddDiskToVm has moved to CREATE_DISK, it will now be: CONFIGURE_VM_STORAGE - RemoveDisksFromVm, UpdateVmDisk - Is there a difference between RemoveDisk and RemoveDisksFromVm? If so, what is the difference? - Is there a difference between UpdateDisk and UpdateVmDisk? If so, what is the difference? [If answer to both questions is no, CONFIGURE_VM_STORAGE action-group should be removed; this should be considered in the upgrade process] 2. [Michael/Daniel] (more related to the floating disks feature): In which Action Group will DetachDiskFromVm reside? 3. Updated Roles: VM Operator should be extended with permissions on Disk - note that all other pre-defined roles that have UpdateVM within them (and most of them do, AFAIK) should also be extended with the extra Disk-related ActionGroups (otherwise we can reach strange situations in which a Cluster Admin can do everything in his cluster except manipulate Disks in his VMs, for example). 4. Upgrade DB: Add Disk Operator role to users that have VM Operators to allow permissions on Disks: - I assume that you mean that Disk Operator *permissions* should be added on the relevant *Disks* to the VM Operator users. - I suggest to add these during upgrade not only for VM Operators but for all users that have a direct permission on a VM which is associated with any Role that contains the action UpdateVM. 5. GUI will need a new query: GetAllAttachableDisks. - This query should be an Admin + User query and will have two flavors: Admin and User (using the isFiltered property). - With isFiltered = false (will be used for the admin portal), it should return a list of all floating and/or sharable disks. - With isFiltered = true (will be used in the power user portal), it should return a list of all floating and/or sharable disks on which the user has permissions. Thanks, Einav - Original Message - From: Moti Asayag masa...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, March 14, 2012 2:20:18 AM Subject: [Engine-devel] Disk Permissions Feature Hi all, Disk Permissions feature description Wiki page: http://www.ovirt.org/wiki/Features/DiskPermissions Please share your comments. Thanks, Moti ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
- Original Message - From: Einav Cohen eco...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, March 19, 2012 10:25:24 AM Subject: Re: [Engine-devel] Disk Permissions Feature - Original Message - From: Oved Ourfalli ov...@redhat.com Sent: Sunday, March 18, 2012 11:52:33 AM On 03/15/2012 05:34 PM, Omer Frenkel wrote: 1. Create disk - requires permissions on the Storage Domain, (can't assume Quota is sufficient to permit user creating the disk on the Storage Domain, as Quota might be disabled) I'd also specify create disk for regular disks is at storage domain level?, while direct lun disks require system level permission of add disk. so, if quota is disabled, how important is it to prevent creation of disks (other than direct lun ones, which would require a permission similar to storage domain creation)? if this is added, it has to be implicitly added / not needed if user has quota (i.e., having a quota should be similar to having a permission as far as the check goes). We should look into it, how complicate is it to validate if user has either quota or permission, and allow creating a disk on a SD if either exists. this might be confusing to the user as he can disable the quota, then stuff would stop working. we can't require both quota and permissions from user on storage domains - that's cumbersome. question is if we can limit the need for permissions to disks only to places where they are needed (shared, direct, floating)? +1 on that. I also think it is only relevant on attaching a disk to a VM, as the other use-cases are simpler: 1. Attach disk to VM - would require having permissions on the disk (whether it is shared, direct lun or floating) 2. Add disk to VM - would only require quota (if enforced). 3. Create disk (i.e., floating/shared disk) - would only require quota (if enforced). and if not enforced? anyone can create as much disks as he like? we thought of requiring permissions if quota is disabled, but i think its confusing to the user as he plays with You are right. Need to think this through... Also, we need to get a better understanding on the use-cases for floating/shared disk... who is supposed to create them, and who to attach... The convention today is that in order to create something, you need permissions on the ancestor entity. Therefore, I think it should be as follows: 1. In order to create a Disk in a VM context, you need permission on the VM (just like in 3.0, IIRC). 2. In order to create a Floating Disk within a storage domain, you need permission on the storage domain 1 is okay as long as we limit the user from detaching this disk later on, as detaching it will make it floating. Or, we can allow detaching only in case the user has permissions on the storage domain, but that will be hard to understand in a user's perspective. 3. In order to create an External LUN Disk, you need permission on System/DC/Whatever we decide the ancestor entity of External LUN is. 4? Not sure regarding creation of External LUN Disk in a VM context (if that scenario exists) - will probably need a permission on both VM and External-LUN-ancestor, since this is a special case. All of the above is regardless quota, meaning, if quota is enforced, quota restrictions will apply as relevant *in addition* to the permission limitations. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk Permissions Feature
On 03/19/2012 12:47 PM, Einav Cohen wrote: 1. According to the wiki, these are the new Action Groups that will be added: CREATE_DISK - AddDisk, AddDiskToVm EDIT_DISK_PROPERTIES - UpdateDisk, UpdateVM, Activate/Deactivate ATTACH_DISK - AttachDiskToVm CONFIGURE_DISK_STORAGE - MoveOrCopyDisk DELETE_DISK - RemoveDisk, RemoveVm Currently we have: CONFIGURE_VM_STORAGE - AddDiskToVm, RemoveDisksFromVm, UpdateVmDisk So, since AddDiskToVm has moved to CREATE_DISK, it will now be: CONFIGURE_VM_STORAGE - RemoveDisksFromVm, UpdateVmDisk - Is there a difference between RemoveDisk and RemoveDisksFromVm? If so, what is the difference? - Is there a difference between UpdateDisk and UpdateVmDisk? If so, what is the difference? [If answer to both questions is no, CONFIGURE_VM_STORAGE action-group should be removed; this should be considered in the upgrade process] This point should be taken into consideration when design/implementation of new verbs (RemoveDisk / UpdateDisk ) is done. 2. [Michael/Daniel] (more related to the floating disks feature): In which Action Group will DetachDiskFromVm reside? 3. Updated Roles: VM Operator should be extended with permissions on Disk - note that all other pre-defined roles that have UpdateVM within them (and most of them do, AFAIK) should also be extended with the extra Disk-related ActionGroups (otherwise we can reach strange situations in which a Cluster Admin can do everything in his cluster except manipulate Disks in his VMs, for example). Updated wiki: http://www.ovirt.org/wiki/Features/DiskPermissions#Updated_Roles 4. Upgrade DB: Add Disk Operator role to users that have VM Operators to allow permissions on Disks: - I assume that you mean that Disk Operator *permissions* should be added on the relevant *Disks* to the VM Operator users. - I suggest to add these during upgrade not only for VM Operators but for all users that have a direct permission on a VM which is associated with any Role that contains the action UpdateVM. Updated wiki: http://www.ovirt.org/wiki/Features/DiskPermissions#Upgrade_DB 5. GUI will need a new query: GetAllAttachableDisks. - This query should be an Admin + User query and will have two flavors: Admin and User (using the isFiltered property). - With isFiltered = false (will be used for the admin portal), it should return a list of all floating and/or sharable disks. - With isFiltered = true (will be used in the power user portal), it should return a list of all floating and/or sharable disks on which the user has permissions. Thanks, Einav - Original Message - From: Moti Asayag masa...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, March 14, 2012 2:20:18 AM Subject: [Engine-devel] Disk Permissions Feature Hi all, Disk Permissions feature description Wiki page: http://www.ovirt.org/wiki/Features/DiskPermissions Please share your comments. Thanks, Moti ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
