[libvirt] [PATCH alt] conf: Allow user define their own alias

[Daniel P. Berrange]

On Fri, Sep 29, 2017 at 03:56:53PM +0200, Michal Privoznik wrote:
> On 09/29/2017 01:52 PM, Daniel P. Berrange wrote:
> > On Fri, Sep 29, 2017 at 12:09:52PM +0100, Daniel P. Berrange wrote:
> >> On Fri, Sep 29, 2017 at 01:04:34PM +0200, Michal Privoznik wrote:
> >>> On 09/29/2017 10:49 AM, Daniel P. Berrange wrote:
> >>>> On Fri, Sep 29, 2017 at 09:06:01AM +0200, Michal Privoznik wrote:
> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1434451
> >>>>>
> >>>>> It comes handy for management application to be able to have a
> >>>>> per-device label so that it can uniquely identify devices it
> >>>>> cares about. The advantage of this approach is that we don't have
> >>>>> to generate aliases at define time (non trivial amount of work
> >>>>> and problems). The only thing we do is parse the user supplied
> >>>>> tag and format it back. For instance:
> >>>>>
> >>>>>     <disk type='block' device='disk'>
> >>>>>       <driver name='qemu' type='raw'/>
> >>>>>       <source dev='/dev/HostVG/QEMUGuest1'/>
> >>>>>       <target dev='hda' bus='ide'/>
> >>>>>       <alias user='myDisk0'/>
> >>>>
> >>>> I really do not like this - having two arbitrary string alias names is
> >>>> just crazy. 
> >>>
> >>> Why is that? We have plenty of elements that do not match to anything at
> >>> hypervisor level. Firstly, there's metadata. Secondly, aliases in lxc
> >>> driver don't match anything either. And one can argue that the link in
> >>> qemu can be broken too. I mean, it's just for now that the aliases we
> >>> report happen to be device IDs we put onto the qemu's cmd line. Not to
> >>> mention devices that we put there and not report in the domain XML => no
> >>> IDs visible there.
> >>
> >>>> If we want to add a second attribute to uniquely identify
> >>>> devices, then it should be a UUID IMHO, so it at least has some tangible
> >>>> benefit instead of just duplicating the existing id format
> >>>
> >>> I'm failing to see why UUID is better than any arbitrary string. You
> >>> mean we would generate the UUIDs if not supplied by user?
> >>
> >> Some hypervisors could map UUIDs to individual devices, so it is a more
> >> generally useful concept.
> > 
> > Also if we have APIs that accept an 'alias' string, we cannot extend them
> > to support the user's own 'alias' unless we guarantee the user supplied
> > alias is different from the alias we give to QEMU.  
> 
> We can if we document that libvirt generated aliases take precedence
> over user ones. That way we can keep the backward compatibility.

No, that's fragile. If libvirt were ever to change its alias name for
something there is a risk it might clash with an app name, which previously
did not clash.

> > If we used UUID format,
> > however, we don't have any ambiguity between a string that's an alias and
> > a string that's a UUID.
> 
> So IIUC users would be able to specify UUID for devices they want and
> for the rest libvirt will generate new one? That'll make XMLs a lot
> bigger. If we will not generate UUIDs, but just store ones provided by
> user this also makes sense then. Although, dealing with UUIDs is very
> user unfriendly, but that ship sailed a long time ago :-P

I would not generate UUIDs - only have them if the app asked for them, or
if the hypervisor we're using has assigned them itself.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|