[PATCH] UI enhancement: Request /config/capabilities as soon as possible
/config/capabilities was requested twice for the templates tab: one request to identify if qemu has spice support and other one to identify if the qemu has ISO streaming support. Those requests were made right before using the information, causing a delay on UI until get the server response. For example, for distant servers, while creating a new template the "Remote ISO" option was disabled at the first time and after some time it was enabled. The same behavior was identified while editing a template, as the graphics options blinked to add the spice on it. To fix it, request /config/capabilities when loading the templates tab to have this information prior to edit or create a new template. Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com> --- ui/js/src/kimchi.template_add_main.js | 27 ++++++++++++--------------- ui/js/src/kimchi.template_edit_main.js | 12 ++++-------- ui/js/src/kimchi.template_main.js | 6 ++++++ 3 files changed, 22 insertions(+), 23 deletions(-) diff --git a/ui/js/src/kimchi.template_add_main.js b/ui/js/src/kimchi.template_add_main.js index a24a306..a7421d7 100644 --- a/ui/js/src/kimchi.template_add_main.js +++ b/ui/js/src/kimchi.template_add_main.js @@ -222,22 +222,19 @@ kimchi.template_add_main = function() { //1-2 remote iso $('#iso-remote').css('opacity', 0.3).css('cursor', 'not-allowed'); - kimchi.getCapabilities(function(result) { - if (result.qemu_stream == true) { - $('#iso-remote').css('opacity', 1).css('cursor', 'pointer'); - - $('#iso-remote').click(function() { - kimchi.switchPage('iso-type-box', 'iso-remote-box'); - initRemoteIsoField(); - initIsoUrlField(); - kimchi.listDistros(function(isos) { - showRemoteIsoField(isos); - }, function() { - }); + if (kimchi.capabilities.qemu_stream == true) { + $('#iso-remote').css('opacity', 1).css('cursor', 'pointer'); + + $('#iso-remote').click(function() { + kimchi.switchPage('iso-type-box', 'iso-remote-box'); + initRemoteIsoField(); + initIsoUrlField(); + kimchi.listDistros(function(isos) { + showRemoteIsoField(isos); + }, function() { }); - } - }, function() { - }); + }); + } $('#iso-remote-box-back').click(function() { kimchi.switchPage('iso-remote-box', 'iso-type-box', 'right'); diff --git a/ui/js/src/kimchi.template_edit_main.js b/ui/js/src/kimchi.template_edit_main.js index d42108c..281154a 100644 --- a/ui/js/src/kimchi.template_edit_main.js +++ b/ui/js/src/kimchi.template_edit_main.js @@ -39,14 +39,10 @@ kimchi.template_edit_main = function() { } var options = [{label: 'VNC', value: 'vnc'}]; - kimchi.getCapabilities(function(result) { - if (result.qemu_spice == true) { - options.push({label: 'Spice', value: 'spice'}) - } - }, function() { - }, function() { - kimchi.select('template-edit-graphics-list', options); - }); + if (kimchi.capabilities.qemu_spice == true) { + options.push({label: 'Spice', value: 'spice'}) + } + kimchi.select('template-edit-graphics-list', options); var scsipools = {}; kimchi.listStoragePools(function(result) { diff --git a/ui/js/src/kimchi.template_main.js b/ui/js/src/kimchi.template_main.js index 3c8421d..8a783c3 100644 --- a/ui/js/src/kimchi.template_main.js +++ b/ui/js/src/kimchi.template_main.js @@ -83,6 +83,12 @@ kimchi.hideTitle = function() { }; kimchi.template_main = function() { + kimchi.getCapabilities(function(result) { + kimchi.capabilities = result; + }, function() { + kimchi.capabilities = {}; + }); + if(kimchi.tabMode['templates'] === 'admin') { $('.tools').attr('style','display'); $("#template-add").on("click", function(event) { -- 1.9.3
I like the idea to run "kimchi.getCapabilities" only once and use its results later. Those values are very unlikely to change unless there is some server upgrade. But as far as I understand, there is no syncing strategy to make sure the new variable "kimchi.capabilities" will only be read when the function "kimchi.getCapabilities" has been executed successfully. This may lead to an execution error (i.e. "kimchi.capabilities" may still be undefined) or inconsistent values (e.g the host may have QEMU stream capability but if the function "kimchi.getCapabilities" hasn't finished executing yet, "kimchi.capabilities.qemu_stream" might still have its default value - not the actual one). Also, if the approach is to run "kimchi.getCapabilities" once and then cache its results, we might as well use those cached values elsewhere in Kimchi. The tab "Host" will still execute that function. On 08-08-2014 14:15, Aline Manera wrote:
/config/capabilities was requested twice for the templates tab: one request to identify if qemu has spice support and other one to identify if the qemu has ISO streaming support.
Those requests were made right before using the information, causing a delay on UI until get the server response.
For example, for distant servers, while creating a new template the "Remote ISO" option was disabled at the first time and after some time it was enabled. The same behavior was identified while editing a template, as the graphics options blinked to add the spice on it.
To fix it, request /config/capabilities when loading the templates tab to have this information prior to edit or create a new template.
Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
On 08/08/2014 03:29 PM, Crístian Viana wrote:
I like the idea to run "kimchi.getCapabilities" only once and use its results later. Those values are very unlikely to change unless there is some server upgrade.
But as far as I understand, there is no syncing strategy to make sure the new variable "kimchi.capabilities" will only be read when the function "kimchi.getCapabilities" has been executed successfully. This may lead to an execution error (i.e. "kimchi.capabilities" may still be undefined) or inconsistent values (e.g the host may have QEMU stream capability but if the function "kimchi.getCapabilities" hasn't finished executing yet, "kimchi.capabilities.qemu_stream" might still have its default value - not the actual one).
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.
Also, if the approach is to run "kimchi.getCapabilities" once and then cache its results, we might as well use those cached values elsewhere in Kimchi. The tab "Host" will still execute that function.
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,
On 08-08-2014 14:15, Aline Manera wrote:
/config/capabilities was requested twice for the templates tab: one request to identify if qemu has spice support and other one to identify if the qemu has ISO streaming support.
Those requests were made right before using the information, causing a delay on UI until get the server response.
For example, for distant servers, while creating a new template the "Remote ISO" option was disabled at the first time and after some time it was enabled. The same behavior was identified while editing a template, as the graphics options blinked to add the spice on it.
To fix it, request /config/capabilities when loading the templates tab to have this information prior to edit or create a new template.
Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
On 08/08/2014 05:00 PM, Aline Manera wrote:
On 08/08/2014 03:29 PM, Crístian Viana wrote:
I like the idea to run "kimchi.getCapabilities" only once and use its results later. Those values are very unlikely to change unless there is some server upgrade.
But as far as I understand, there is no syncing strategy to make sure the new variable "kimchi.capabilities" will only be read when the function "kimchi.getCapabilities" has been executed successfully. This may lead to an execution error (i.e. "kimchi.capabilities" may still be undefined) or inconsistent values (e.g the host may have QEMU stream capability but if the function "kimchi.getCapabilities" hasn't finished executing yet, "kimchi.capabilities.qemu_stream" might still have its default value - not the actual one).
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.
Ops... it is not true! =$ I need to move doListTemplates() in the .done() block for kimchi.getCapabilities() + kimchi.getCapabilities(function(result) { + kimchi.capabilities = result; + }, function() { + kimchi.capabilities = {}; + }, function() { + doListTemplates(); + }); + I will send a v2 with that
Also, if the approach is to run "kimchi.getCapabilities" once and then cache its results, we might as well use those cached values elsewhere in Kimchi. The tab "Host" will still execute that function.
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,
On 08-08-2014 14:15, Aline Manera wrote:
/config/capabilities was requested twice for the templates tab: one request to identify if qemu has spice support and other one to identify if the qemu has ISO streaming support.
Those requests were made right before using the information, causing a delay on UI until get the server response.
For example, for distant servers, while creating a new template the "Remote ISO" option was disabled at the first time and after some time it was enabled. The same behavior was identified while editing a template, as the graphics options blinked to add the spice on it.
To fix it, request /config/capabilities when loading the templates tab to have this information prior to edit or create a new template.
Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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.
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 08-08-2014 18:32, Aline Manera wrote:
This is not true. The qemu capabilities is also cached on backend. Check src/kimchi/model/config.py Then why are we caching those values again on the frontend? If the backend already caches the capabilities information, every call to "kimchi.getCapabilities" (after the first one) should return instantly with the cached values. There's no need to cache the same thing on the backend and then on the frontend.
According to the patch's subject and description: /"Request /config/capabilities as soon as possible//" / Doesn't the backend already do that by caching the values? /"/config/capabilities was requested twice for the templates tab: one// //request to identify if qemu has spice support and other one to identify// //if the qemu has ISO streaming support./" Shouldn't the second request return instantly with the results cached on the backend by the first request?
On 08/11/2014 03:09 PM, Crístian Viana wrote:
On 08-08-2014 18:32, Aline Manera wrote:
This is not true. The qemu capabilities is also cached on backend. Check src/kimchi/model/config.py Then why are we caching those values again on the frontend? If the backend already caches the capabilities information, every call to "kimchi.getCapabilities" (after the first one) should return instantly with the cached values. There's no need to cache the same thing on the backend and then on the frontend.
According to the patch's subject and description:
/"Request /config/capabilities as soon as possible//" / Doesn't the backend already do that by caching the values?
/"/config/capabilities was requested twice for the templates tab: one// //request to identify if qemu has spice support and other one to identify// //if the qemu has ISO streaming support./"
Shouldn't the second request return instantly with the results cached on the backend by the first request?
All requests are time consuming. Even if there is no logic involved in it on backend. Specially for long distant server/client. Please, check v3.
participants (2)
-
Aline Manera -
Crístian Viana