[Engine-devel] Floating Disk feature description

[Miki Kenneth]

----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>, "Miki Kenneth" <mkenneth at 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 at 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 at redhat.com>
> > >> To: "Daniel Erez"<derez at redhat.com>
> > >> Cc: engine-devel at 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 at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
>