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

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.

_______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel