On Aug 27, 2015, at 12:02 PM, Daniel P. Berrange wrote: > 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.
I've haven't used Libvirt but I do believe in the saying "never say never". The rest of what you said does sound accurate.
