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

[Aline Manera]

On 08/08/2014 06:32 PM, Aline Manera wrote:
>
> 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.

Got your point.
I was treating backend and frontend as the same in my mind.
Check v3.

>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>