[libvirt] [PATCH v2 3/3] conf: Allow users to define UUID for devices

[Martin Kletzander]

On Tue, Oct 03, 2017 at 12:58:59PM +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
>UUID 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'/>
>      <uuid>1efaf08b-9317-4b0f-b227-912e4bd9f483</uuid>
>      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>    </disk>
>
>Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>---
>
>This is just a very basic implementation. If I get a green light on this, I can
>implement the feature further, i.e. allow device lookup on the UUID. For
>instance:
>
>virsh domiftune fedora $UUID $bandwidth
>

I'll be frank with you, I hate the fact that this can only be UUID and
there are reasons.  Even though other will^Wmight not share my view.

I don't want to ACK this patch even though it probably works OK.  At the
same time I'm not NACKing it since I might get overruled.

OK, it's my bad I didn't reply on the previous version, but I don't like
this so much I'll reply to it even in this new version.

So let me sum it up:

 1) UUIDs are more generally useful concept

    Allowing arbitrary (but sane, e.g. [a-zA-Z0-9\-_.]) also inherently
    allows UUID is mgmt apps want to use them.  This field should never
    be used by a hypervisor, only by drivers and if necessary.

 2) We cannot extend current APIs to support it, it can clash with
    libvirt's alias in the future.

    I don't see why not.  Searching by IDs (or user aliases, whatever
    you call it) does not have to be supported at all.  Mgmt apps can
    use is only as a part of domain definition.  If we want to add such
    functionality, then it can be turned on by a flag or flags, e.g.:

     - VIR_BLAH_BY_ID
     - VIR_BLAH_PREFER_ID
     - VIR_BLAH_WHATEVER

    But there is no requirement for us to provide this.  It should not
    be blocking the inclusion of this feature.

 3) We have to add a lot of code that handles duplicates, etc.

    No.  No, we don't.  Duplicates can not only be handled by mgmt app
    itself, it could also be beneficial.  Imagine I have bunch of
    devices that share some source or are similar in a way and I just
    name them the same.  Even if we want to provide a way of specifying
    devices for APIs by this user supplied string, we can just unplug
    the first one we'll find.

By not requiring that it's an ID, users can take benefit of ti too.  And
making sure it's an UUID seems like a waste of computing power.

Sometimes I feel like we are trying to do too much, even stuff that
nobody will effectively use and then we have to support it.  The same
with solving corner cases in which we could just error out instead of
wasting manpower on them.

My (way more than) 2 cents.

Have a nice day,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171003/f79b567b/attachment-0001.sig>