[Engine-devel] Floating Disk feature description

[Einav Cohen]

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

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