Re: KVM call agenda for Apr 27

[Anthony Liguori <anthony@codemonkey.ws>]

On 04/27/2010 04:41 AM, Kevin Wolf wrote:
> Am 27.04.2010 11:32, schrieb Dor Laor:
>    
>> On 04/27/2010 12:22 PM, Avi Kivity wrote:
>>      
>>> On 04/27/2010 12:08 PM, Dor Laor wrote:
>>>        
>>>> On 04/27/2010 11:56 AM, Avi Kivity wrote:
>>>>          
>>>>> On 04/27/2010 11:48 AM, Dor Laor wrote:
>>>>>            
>>>>>> IMHO the whole thing is way over engineered:
>>>>>> a) Having another channel into qemu is complicating management
>>>>>> software. Isn't the monitor should be the channel? Otherwise we'll
>>>>>> need to create another QMP (or nbd like Avi suggest) for these
>>>>>> actions. It's extra work for mgmt and they will have hard time to
>>>>>> understand events interleaving of the various channels
>>>>>>              
>>>>> block layer plugins allow intercepting all interesting block layer
>>>>> events, not just write-past-a-watermark, and allow actions based on
>>>>> those events. It's a more general solution.
>>>>>            
>>>> No problem there, as long as we do try to use the single existing QMP
>>>> with the plugins. Otherwise we'll create QMP2 for the block events in
>>>> a year from now.
>>>>          
>>> I don't see how we can interleave messages from the plugin into the qmp
>>> stream without causing confusion.
>>>        
>> Those are QMP async events.
>>
>> Since Kevin suggested adding even more events (was is cynical?)
>>      
> The part about adding a scripting engine was.
>
> The idea of adding a generic event (one event, not even more!) for a QMP
> query-* result change doesn't sound that bad on second thought, though.
> It's not specific for watermarks and looks less complicated than all the
> plugin, NBD and QMP2 stuff.
>
> It's almost the same as Anthony's polling suggestion (works with query-*
> results from user perspective), just without polling.
>    

Is this really necessary other than making people feel less bad about 
polling?

How I understand the use case, polling every five seconds would be 
completely reasonable in addressing the use-case.  It might not be as 
sexy as a generic event notification mechanism but not everything can't 
be JSON.

Regards,

Anthony Liguori

> Kevin
>