3:10 p.m.
----- Original Message -----
From: "Daniel Erez" <derez(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "Miki Kenneth" <mkenneth(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Thursday, February 2, 2012 12:25:52 PM
Subject: Re: [Engine-devel] Floating Disk feature description
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Daniel Erez" <derez(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, February 2, 2012 9:08:56 AM
> Subject: Re: [Engine-devel] Floating Disk feature description
>
> On 02/01/2012 07:04 PM, Daniel Erez wrote:
> > Hi,
> >
> > Floating Disk feature description Wiki page:
> > http://www.ovirt.org/wiki/Features/DetailedFloatingDisk
>
> some questions/notes:
> 1. why do you need a floating/not floating state? isn't a disk
> floating
> if it was detached from all VMs?
> or is that only a helper property to optimize lookups?
>
Yes, the floating state is an indication whether the disk is attached
to any VM.
It's not a persistent property on the disk, but rather a DB view
calculated value.
> 2. you mention fields of disks (Floating/Shared/Managed)
>
> 2.1 do we have a definition of "Managed" disk somewhere?
> I assume unmanaged would be a direct LUN, but i think we need a
> better
> terminology here.
Indeed, we're looking for a better teminology. Suggestions are
welcomed...
>
> 2.2 same goes for "floating" actually... do we really want to tell
> the
> user the disk is "floating"?
> I guess suggestion welcome for a better name.
"unattached" has been mentioned once as an alternative.
>
> 2.3 finally, for shared, maybe more interesting is number of VMs
> the
> disk is connected to, rather than just a boolean (though i assume
> this
> increases complexity for calculation, or redundancy of data, and
> not
> a
> big issue)
Actually, as part of the "Shared raw disk" feature, we do want to
display the number of VMs
(and probably a list too) the disk is connected to - in the 'Disks'
sub-tab (under VMs main tab).
Hence, it might be rather simple to show that number also in the
Disks main tab
(the list of VMs will be displayed under VMs sub-tab).
>
> 3. List of Storage Domains in which the selected Disk resides.
> this is only relevant for template disks?
Yes, it's only for cloned templates.
> maybe consider splitting the main grid if looking at tempalte disks
> or
> vm disks, and show for vm disks the storage domain in main grid?
> maybe start with vm disks only and not consider template disks so
> much?
Miki?
Good point - we can do either by a column and sortby or by
two-interchangeable tabs.
There are two many properties we would like to sort by, that's way I suggested the
column way.
>
> 4. "Templates (visible for disks that reside in templates) List of
> Templates to which the selected Disk is attached. "
>
> same comment as above of maybe consider only vm disks for now.
> and also a question - how can a template disk belong to more than a
> single template?
Yes, for now, a template disk cannot belong to more than a single
template.
However, won't we like to have a shared disk for a template in the
future?
>
> which again hints for a template disk you would want another view,
> with
> the template name in the main grid
>
> 5. Tree: 'Resources' vs. 'free disks'
> while i understand why separating them - naming is very confusing.
> maybe a single node in tree and a way to filter the search from the
> right side grid in some manner for known lookups (relevant to other
> main
> tabs as well?)
For now, we've agreed that sorting abilities in columns is needed for
easing the orientation.
>
> 6. permissions not available for disks?
> at all?
> what do you mean power user would be able to attach them by their
> type?
> does it mean they can associate any shared disk in the system? I
> hope
> i'm misunderstanding, as doesn't make sense to me.
>
> or is this caveat specific to the user portal and not the admin?
> not allowing creating a floating disk from user portal is not a
> problem
> in my view for this phase.
>
> I assume anyone can add a disk on a storage domain they have quota
> to.
> who can edit a disk? remove a disk? attach disk to VM (which gives
> them
> ability to edit the disk)
> (attach disk to VM obviously requires permission on both disk and
> VM)
Since we won't support permissions on disks entities (at first
stage),
as a compromise for the power user portal, we've agreed to simply
hide
floating non shared disks from the user.
>
> 7. related features
> - data ware house may be affected by disks being unattached, or
> shared
> between multiple disks.
>
>
>
>
>
>
>