10:13 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Yaniv Kaul" <ykaul(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Daniel Erez" <derez(a)redhat.com>, "Miki
Kenneth" <mkenneth(a)redhat.com>
Sent: Thursday, February 2, 2012 4:45:30 PM
Subject: Re: [Engine-devel] Floating Disk feature description
> ----- Original Message -----
> From: "Yaniv Kaul" <ykaul(a)redhat.com>
> Sent: Thursday, February 2, 2012 1:43:58 PM
>
> On 02/02/2012 01:35 PM, Daniel Erez wrote:
> >
> > ----- Original Message -----
> >> From: "Yaniv Kaul"<ykaul(a)redhat.com>
> >> To: "Daniel Erez"<derez(a)redhat.com>
> >> Cc: engine-devel(a)ovirt.org
> >> Sent: Thursday, February 2, 2012 10:27:06 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
> >>>
> >>> Best Regards,
> >>> Daniel
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> 0. Is it a floating disk or a floating image? would be nice to
> >> use
> >> the
> >> same terminology for all projects, where possible
> >> (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image)
> > Disk and Image are the same ("Disk" is the RHEV-M term for
VDSM's
> > "Image"). Both of them means: the collection of "volumes"
(or,
> > "DiskImages", in RHEV-M terminology) that comprise the full disk.
> > We have no problem using either terminology, however might be
> > confusing either way.
> > [BTW, a floating disk can't conatin snapshots - so it doesn't
> > really matter if you are talking about disk, image, diskImage or
> > volume - they are all the same]
>
> If they are the same, then please use the term 'image'.
As I said - no technical problem doing that, however in the engine we
use the term "Disk" and the current name of the relevant VMs sub-tab
is "Disks" and the name of the new main tab would be "Disks" (or
"Virtual Disks"), etc. - so it will be strange to call the feature
"floating image" when "floating" is going to be column in a GUI grid
titled "Disks".
I assume that you can also find explanations of why using the term
"Disk" is confusing and "Image" is better; I am just genuinely not
sure what is less confusing.
This is inconsistency I agree, but I think that from
the User perspective we should stick with either Disk or Drive. In any OS of a
Server/Desktop the term rather Disk or Drives.
> And it looks like the feature is 'floating single-volume image' . I
> wonder if the limitation is really an issue or not. Can't think of
> a
> real use case it would be, but here's an imaginary one: before
> attaching
> it to a VM (or after and before running), I'd take a snapshot, then
> run
> the VM, do whatever, and revert before/after detaching, so the
> floating
> would go back to its original state.
>
> >
> >> 1. I don't see why a disk name should be unique. I don't think
> >> it's
> >> enforceable under any normal circumstances: If user A decided to
> >> call
> >> his disk 'system', user B who is completely unaware of A cannot
> >> call
> >> his
> >> disk 'system' ? It should be unique at some level, but not
> >> system-wide.
> > The enforcement for uniqueness has been suggested for avoiding a
> > list of
> > duplicate named disks in the Disks main tab and for identifying a
> > specific disk.
>
> Understood, but it's not good enough. Need to solve this, as it's
> not
> practical to ask me not to share a property with you - which both
> us
> do
> not really share.
>
> > Probelm is that any disk theoretically can be floating, so you
> > cannot differentiate between the disks using the VM name to which
> > it is attached, for example (moreover, some of the disks in the
> > system are shared, so which VM name will you use?...)
>
> The fact VM names are unique is also an annoying, problematic
> issue,
> but
> I imagine there are less VMs than disks, and most are going to be
> FQDN
> based anyway. 'system' and 'data' are quite common names for disks,
> whereas VM names might be more original. Anyway, both don't scale.
>
> > Maybe we can use some other attribute for identification?
>
> The real identification can be done via the serial number, no harm
> in
> displaying that cryptic ID in the UI. Makes us look professional.
> Of
> course, it makes more sense to use the volume UUID. May come handy
> in
> locating it physically on disk, if it exists.
>
>
> >
> >> 2. I'm not sure I understand why exporting a floating disk is
> >> 'not
> >> supported'. In the current design? implementation? ever?
> > Currently, Export is done in a VM/Template level. Support in
> > export/import (floating) disks is a new functionality which
> > requires additional thinking/design/etc.
>
> Right, so lets add 'currently not supported'.
> Y.
>
> >
> >> Y.
> >>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>