[Engine-devel] Floating Disk feature description

[Einav Cohen]

> ----- Original Message -----
> From: "Miki Kenneth" <mkenneth at redhat.com>
> Sent: Thursday, February 2, 2012 2:10:54 PM
> ...
> > > > 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.

I actually believe that Itamar's suggestion of "start with vm disks only and not consider template disks so much" is better and simpler; Template Disks aren't the reason for implementing the Disks main tab anyway: there shouldn't be to many template disks in the system and they are not floating/shared, they cannot be attached/detached, etc.

Having two grids in a main tab isn't consistent with the current graphical "language" of the GUI.

We can still have a single grid with a column for indication for "VM Disk vs. Template Disk", however having there also a column of "storage domain" or "template name" is problematic ("storage domain" column is problematic for Template Disks, since they can reside on multiple storage domains; "template name" is problematic, since it is relevant only for templates' disks).

> > 
> > > 
> > > 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

Again, as I stated above - maybe worth ignoring Templates' Disks altogether in the Disks main tab context.

> > > 
> > > 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.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>