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

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.