12:15 p.m.
/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(a)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
1:29 p.m.
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(a)linux.vnet.ibm.com>
3 p.m.
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(a)linux.vnet.ibm.com>
3:15 p.m.
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(a)linux.vnet.ibm.com>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3:59 p.m.
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.
4:32 p.m.
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.
6:45 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
1:09 p.m.
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?
1:55 p.m.
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.
3554
days inactive
3557
days old
8 comments
2 participants
participants (2)
-
Aline Manera -
Crístian Viana