9:20 a.m.
----- Original Message -----
From: "Miki Kenneth" <mkenneth(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel