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

[Crístian Viana]

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.

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. 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.