[Engine-devel] Floating Disk feature description

Miki Kenneth mkenneth at redhat.com
Thu Feb 2 12:10:54 UTC 2012



----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Miki Kenneth" <mkenneth at redhat.com>, engine-devel at 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 at redhat.com>
> > To: "Daniel Erez" <derez at redhat.com>
> > Cc: engine-devel at 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.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 



More information about the Engine-devel mailing list