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

[Programmingkid]

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.