Re: [Qemu-devel] Should we auto-generate IDs?

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Aug 27, 2015 at 11:58:22AM -0400, Programmingkid wrote:
> 
> On Aug 27, 2015, at 11:40 AM, Jeff Cody wrote:
> 
> > On Thu, Aug 27, 2015 at 11:20:20AM -0400, Programmingkid wrote:
> >> 
> >> On Aug 27, 2015, at 10:42 AM, Daniel P. Berrange wrote:
> >> 
> >>> On Thu, Aug 27, 2015 at 10:34:05AM -0400, Programmingkid wrote:
> >>>> 
> >>>> On Aug 27, 2015, at 10:02 AM, Eric Blake wrote:
> >>>> 
> >>>>> On 08/27/2015 07:56 AM, Programmingkid wrote:
> >>>>> 
> >>>>>>> If we did have auto-generated names, we would need to come up with a
> >>>>>>> scheme that is not going to clash with any existing naming that users
> >>>>>>> of QEMU may already be doing, otherwise we risk causing a regression.
> >>>>>>> Something as simple as what you suggest has non-trivial chance of
> >>>>>>> clashing.
> >>>>>> 
> >>>>>> Actually there is a way to prevent clashing. When QEMU auto-generates a
> >>>>>> name, it could scan all the ID's to see if there is a clash. If the ID is already
> >>>>>> taken, just increment the ID until it is detected to be unique. The previous
> >>>>>> threads on this subject has patches that did just that. This means that a
> >>>>>> ID scheme that is just a single number would work without clashes. 
> >>>>> 
> >>>>> No, because you cannot predict what FUTURE names the user will request.
> >>>>> The name generated by qemu must be IMPOSSIBLE to request manually, and
> >>>>> not just one that happens not to clash at the current moment.
> >>>> 
> >>>> If I add a device with an ID that is taken, QEMU can just say sorry that ID is already
> >>>> taken. I could just increment the ID myself until I find one that is unique. It is a
> >>>> simple algorithm. Maybe you are talking about some program that has hard coded
> >>>> ID's it depends on. If that is the case, perhaps this management program could be
> >>>> made to be a little flexible. Or use a 160-bit SHA-1 generated ID that is virtually
> >>>> guaranteed to always be unique.
> >>> 
> >>> If breaking existing apps was OK, we would just mandate that users always
> >>> provide an ID which trivially avoids the problem of not having an ID to
> >>> use when deleting the object. We want to /avoid/ breaking existing apps
> >>> though, so saying an app should change the way it works in order to cope
> >>> with QEMU's ID generation is not appropriate. Hence any use of auto-generated
> >>> IDs, must use a separate namespace to avoid such clashes.
> >> 
> >> This is making the assumption that an auto-generated ID system would break any existing
> >> application. We don't know this. In fact, I predict a future patch would allow existing
> >> applications to continue running without modification. The patch would be a win-win
> >> for both users and any management application.
> >> 
> > 
> > Daniel's assumption is spot on.  The idea of "QEMU can just say sorry
> > that ID is already taken" will break existing applications.
> > 
> > But we are all striving to make your prediction true, with this very
> > conversation.
> 
> Ok, it sounds like some are concerned that Libvirt would not be able to work with this
> feature. Let me ask you this: does Libvirt interact with QEMU before the user has a
> chance to do so? If the answer is yes, then that means Libvirt will have finished 
> creating all its devices with their ID's long before the user has a chance to enter
> his own devices.

Just to be clear - libvirt will *never* use an auto-generated device
IDs feature. It is way more complicated to let QEMU assign device IDs
and then auto-detect them from some 'info device-list' output, than
to just specify IDs upfront at device/object creation time which
it already does[1]. There is simply no benefit to auto-generating device
IDs for a mgmt app like libvirt, and plenty of downside.  Auto-generated
IDs will only be of interest to humans talking to the monitor directly
without a mgmt app involved.

Regards,
Daniel

[1] we don't provide IDs for qcow2 image backing file chain, but that's
    part of a bigger story that's being dealt with in this area.
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|