[Kimchi-devel] [PATCH] UI enhancement: Request /config/capabilities as soon as possible

[Aline Manera]

On 08/08/2014 05:59 PM, Crístian Viana wrote:
> On 08-08-2014 17:00, Aline Manera wrote:
>>
>> According to the code, the /config/capabilities request will be the 
>> first request made while entering the templates tab.
>> So if it takes time to complete the templates will not be listed and 
>> kimchi.capabilities not used.
> That kind of request is an asynchronous call. The first function 
> parameter will only be executed when the request finishes 
> successfully. The execution flow doesn't stop there.
>
>> The host tab uses values that can be changed any time without 
>> requiring to restart Kimchi.
>> Because that we can not do the same there.
>> For example, host tab checks for sosreport tool and if user installs 
>> it later it does not trigger a kimchi restart so we always need to 
>> care this info,
>

> Does a QEMU package update actually trigger Kimchi to restart?? And 
> why is it required? I'd say the VMs should be restarted when QEMU is 
> updated, not Kimchi.
>

Kimchi uses libvirt, right? Which means Kimchi has a connection to 
libvirt and this one to qemu.
When updating qemu or libvirt the user must restart kimchi to it 
establish a new connection pointing to the new code.
Does that make sense?

What about the sosreport? Should user restart kimchi to be able to use 
it in Kimchi?

> What I mean is that this new capabilities cache should be able to work 
> fine for both Host and Templates tabs (and wherever it's used), if the 
> host server doesn't change. If it does, the sysadmin will probably 
> restart the entire host. We are reading the same bucket of information 
> from the host and caching it, but some parts are not using it and 
> they're querying the host for the same thing again. All those values 
> are just as sensitive to system updates. If we're caching host 
> features information, we should cache it consistently and not for half 
> of the application.
>
> Also, this cache happens on the client side (JavaScript), not on the 
> server side.

This is not true.
The qemu capabilities is also cached on backend. Check 
src/kimchi/model/config.py

> So even if the sysadmin doesn't restart the server after an update 
> (which should be the recommended action anyway), end users who login 
> after the system update will read the newer capabilities values 
> seamlessly because their browsers will create a new request.