[Ovirt-devel] [PATCH 4/6] hardware_pool: search by path

[Perry N. Myers]

David Lutterkort wrote:
> On Wed, 2008-08-27 at 15:03 -0400, Perry N. Myers wrote:
>> David Lutterkort wrote:
>>> On Tue, 2008-08-26 at 10:11 -0400, Scott Seago wrote:
>>>> I'm assuming the path-based pool lookup is just an alternate method of 
>>>> getting this from your API, as the id-based ones will all still work. I 
>>>> just realized that full path-based lookup will only work for users that 
>>>> have read permissions on the whole hierarchy. A user with lower-level 
>>>> permissions only (i.e. only read permissions for pools under 
>>>> '/default/engineering/qa' and write permissions for subpools below that) 
>>>> won't even see the top level pool.
>>> I think that permissioning scheme is fundamentally flawed; at the very
>>> least, any user that has permission on some pool should at least be
>>> allowed to know about the existence of pools above "their" pools - they
>>> may not be able to view any info about them, but at the very least, they
>>> should know that they are there.
>> Not necessarily.  Consider the cloud computing model...  The admins might 
>> know about the fact that there are hardware pools, but should a user of a 
>> VM even know that there is such a thing as a hardware pool?  To them the 
>> hardware pools should be completely hidden in the UI, including the tree view.
> 
> Those are two separate things: whether the UI should show those pools or
> not is separate from whether they are allowed to know that they exist. 

Agreed, but I'm stating that in some environments we will want both of 
those things.  i.e. the UI should hide the pools from the user and the 
user should not even be aware of their existence

> If the UI does not show the HW pools, what does a user see if they have
> permissions on two completely separate VM pools ? Do they appear as
> separate root pools to them ? What if both pools are called 'mypool' ?

I would think that they would appear as multiple roots.  And if the names 
are the same is that a problem?  Sure it makes it confusing for the person 
to identify which pool is which, but they can always rename them to 
mypool1 and mypool2.

> How would a user in that world tell an admin that they need to do
> something in the user's VmPool ? Does the admin need to manually keep
> track of where the 'mypool' VmPool is for user X and for user Y (which
> might be completely different)

The admin knows where the pools are, since they see the full tree.  So the 
user might see:

mypool1
mypool2

The admin would see

default
   hwpool1
     mypool1
   hwpool2
     mypool2

As for the user telling the admin to do something, we should probably have 
links on a pool page that provide a way to contact the parent pool's admin 
person(s).

> How should user X address their VmPool through the API ? If they can't
> use an absolute path to the pool, do they need to divine the internal ID
> of the pool ?

Yes, unless we want to enforce that pool names must be unique (which I 
don't think we want to do).  So we should provide a way in the API to 
reference a pool by hierarchy name and a way to refer to it by some sort 
of UUID.

> Smart pools might be able to help, but we really need a unique
> user-visible name for each pool; whether and when the UI will show that
> name is a completely separate issue.

Yeah, I'm not sure how smart pools factor into this...  We need to discuss 
more.

Perry