[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/17/2010 11:45 AM, Luiz Capitulino wrote:
> On Thu, 17 Jun 2010 18:34:00 +0200
> Juan Quintela<quintela@redhat.com>  wrote:
>
>    
>> Luiz Capitulino<lcapitulino@redhat.com>  wrote:
>>      
>>> On Wed, 16 Jun 2010 21:10:04 +0200
>>> Juan Quintela<quintela@redhat.com>  wrote:
>>>
>>>        
>>>> Luiz Capitulino<lcapitulino@redhat.com>  wrote:
>>>>          
>>>>> On Tue, 15 Jun 2010 17:24:59 +0200
>>>>> Juan Quintela<quintela@redhat.com>  wrote:
>>>>>            
>>>>          
>>>>>>>   I still don't see the need for MIGRATION_STARTED, it could be useful in
>>>>>>> the target but I'd like to understand the use case in more detail.
>>>>>>>                
>>>>>> At this point, if you are doing migration with tcp, and you are putting
>>>>>> the wrong port on source (no path or any other error), you get no info
>>>>>> at all of what is happening.
>>>>>>              
>>>>>   Shouldn't the migrate command just the return the expected error?
>>>>>            
>>>> No.  Think you are "having troubles".  You try to find what happens.
>>>> launch things by hand.  And there is no way to know if anybody has
>>>> conected to the destination machine.  Some notification that migration
>>>> has started is _very_ useful.  expecially when there are
>>>> networks/firewalls/... in the middle.
>>>>          
>>>   [...]
>>>
>>>        
>>>> That is it.  But you continue telling that going to the old house and
>>>> doing a info migrate is a good interface.
>>>>          
>>>   I'm sorry? When did I ever claimed such a thing?
>>>        
>> polling is enough.  polling has to be done in source machine.
>>      
>   Enough for the meantime, until we have something better to offer. The problem
> here is that adding not so good stuff to a protocol is that we will have to
> maintain it for a quite long time, possibly forever.
>
>   That's why I'm being so opposed to a large set of events, a reduced set is a lot
> more attractive.
>
>    
>>>   First point: all you describe is MIGRATION_CONNECTED, at the end of the day
>>> it would do exactly what you want for MIGRATION_STARTED.
>>>
>>>   The second, and most important point, is that we're trying not to make
>>> things worse. Adding a number of events to circumvent a bad designed
>>> command and having the wrong expectations (ie. help developer debugging)
>>> is a clear recipe for disaster.
>>>
>>>   Anyway, I think it doesn't matter anymore, as QMP is not going to be declared
>>> stable for 0.13. In this case we'll have enough time to design the proper
>>> interface.
>>>
>>>        
>>>> To add insult to injury, the problem is that libvirt people are not
>>>> collaborative, and expect things that can't be done, are uncooperative,
>>>>          
>>>   Again, I've never claimed that and I think you're taking this thread to
>>> the wrong direction.
>>>        
>> Ok, I stop then.
>>      
>   I'm not asking you to stop arguing, just to avoid taking the non-technical
> route in a bad way.
>
>   Now, we have the following situation: MIGRATION_CONNECTED and MIGRATION_DONE
> would have possibly been a good fit for 0.13 if QMP was going to be stable.
>
>   However, that's not going to happen so the question is: is it interesting
> to have those events for an unstable QMP? Do we expect any client to need it? Or
> can we wait until 0.14?
>    

We need MIGRATION_CONNECTED post 0.13.  We won't need MIGRATION_DONE so 
there's probably no point in introducing it.

Regards,

Anthony Liguori