----- Original Message -----
From: "Oved Ourfalli" <ovedo(a)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
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(a)ovirt.org
> > >
http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel