Bug 844429 - please load 'applicationMode' config value upon login (currently, it is being loaded upon browser refresh/restart)
please load 'applicationMode' config value upon login (currently, it is being...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
x86_64 Linux
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Greg Sheremeta
sefi litmanovich
ux
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-30 11:16 EDT by Haim
Modified: 2015-09-22 09 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
When making configuration changes using the rhevm-config tool it is necessary to restart the ovirt-engine service before they will take effect. Additionally changes to values that are cached on the client side require a restart of the client browser to clear cached values before they will take effect.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-12 12:08:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Haim 2012-07-30 11:16:31 EDT
Description of problem:

I have the following case where I changed the following value in vdc_options:


engine=# UPDATE vdc_options set option_value = '1' where option_name = 'ApplicationMode' ;

I restarted ovirt-engine service using the following command:

[root@hateya-rhevm ~]# /etc/init.d/ovirt-engine restart 
Stopping engine-service:                                    [  OK  ]
Starting engine-service:                                    [  OK  ]


note: I know that restart was taken place since I couldn't able to browse to my manager till service went up (for 30 seconds or so).

once ovirt-engine service was started, I saw that the changes of the above command didn't take place, so i executed the following command:

[root@hateya-rhevm ~]# /etc/init.d/ovirt-engine stop 
Stopping engine-service:                                    [  OK  ]
[root@hateya-rhevm ~]# /etc/init.d/ovirt-engine start 
Starting engine-service:                                    [  OK  ]
[root@hateya-rhevm ~]# /etc/init.d/ovirt-engine status
The engine process 21922 is running.

once service went up, I was able to see that the above changes took affect (couldn't see gluster-volumes).

I sense that there's a problem with the restart function.
Comment 2 Alon Bar-Lev 2012-08-15 10:32:10 EDT
I see java pid change every restart. Service restart is implemented as stop/start. No clue how could this happen.

Can you please reproduce?
Comment 3 Haim 2012-08-15 10:44:42 EDT
(In reply to comment #2)
> I see java pid change every restart. Service restart is implemented as
> stop/start. No clue how could this happen.
> 
> Can you please reproduce?

it's reproducible (happened to others as well), very easy to reproduce, please change some value in vdc_otions and run the restart.
Comment 4 Alon Bar-Lev 2012-08-15 11:03:02 EDT
As it seems, the value comes from cache at browser side. Please try to disprove.

Thanks.
Comment 5 Itamar Heim 2012-08-16 04:43:38 EDT
actually, i think the WPF had the same cache as well, so don't think this is a regression.
Comment 6 Stephen Gordon 2012-09-12 14:39:02 EDT
(In reply to comment #5)
> actually, i think the WPF had the same cache as well, so don't think this is
> a regression.

I don't suppose we have a list of exactly which config values are cached browser side? Posting a release note that has generic statement that you must restart all client web browsers to effectively propagate rhevm-config changes seems undesirable. I'd prefer to be specific.
Comment 7 Itamar Heim 2012-09-20 18:48:59 EDT
would need to review code, and it could change.
but good news they are limited to this subset which is the only part we expose outside of engine to begin with (which could still change, but easier to track i guess)
./backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/queries/ConfigurationValues.java

timeleasedpool aren't relevant any more btw
Comment 8 Simon Grinberg 2012-10-09 12:30:22 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > actually, i think the WPF had the same cache as well, so don't think this is
> > a regression.
> 
> I don't suppose we have a list of exactly which config values are cached
> browser side? Posting a release note that has generic statement that you
> must restart all client web browsers to effectively propagate rhevm-config
> changes seems undesirable. I'd prefer to be specific.

Steve, those values are not just to be changed by anyone at will, rhevm-config is for experts who know what they are doing and what is the expected outcome. So if someone changes a value using this tool, he suppose to know the effect. Example - change of GUI appearance. Other values like drop down list and etc are refreshed as I recall. 

The good news are that most of the values will not effect the GUI. 
Updating suggested text.
Comment 9 Stephen Gordon 2012-10-09 16:44:58 EDT
(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > actually, i think the WPF had the same cache as well, so don't think this is
> > > a regression.
> > 
> > I don't suppose we have a list of exactly which config values are cached
> > browser side? Posting a release note that has generic statement that you
> > must restart all client web browsers to effectively propagate rhevm-config
> > changes seems undesirable. I'd prefer to be specific.
> 
> Steve, those values are not just to be changed by anyone at will,
> rhevm-config is for experts who know what they are doing and what is the
> expected outcome. So if someone changes a value using this tool, he suppose
> to know the effect. Example - change of GUI appearance. Other values like
> drop down list and etc are refreshed as I recall. 

My point is that you guys are saying that I need to note that if you change the values of keys that are cached by the browser then all client's browsers must be restarted for it to take effect. That statement is meaningless without a list of which keys are cached by the browser, otherwise how is an admin to know whether or not the key he is tweaking falls into that category? 

It seems the underlying assumption here is that "experts" will guess which keys are or are not cached when we ourselves can't provide an accurate list? Why provide a release note at all if this is the case?

Please confirm which, if any, of the configuration keys we list as supported fall into this category:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Virtualization/3.1-Beta/html/Administration_Guide/Red_Hat_Enterprise_Virtualization_Manager_configuration_options_explanations_limitations_and_best_practices.html
Comment 10 Simon Grinberg 2012-10-10 12:24:27 EDT
> 
> Please confirm which, if any, of the configuration keys we list as supported
> fall into this category:
> 
> https://access.redhat.com/knowledge/docs/en-US/
> Red_Hat_Enterprise_Virtualization/3.1-Beta/html/Administration_Guide/
> Red_Hat_Enterprise_Virtualization_Manager_configuration_options_explanations_
> limitations_and_best_practices.html

Alon?
Comment 11 Alon Bar-Lev 2012-10-10 12:33:32 EDT
(In reply to comment #10)
> > 
> > Please confirm which, if any, of the configuration keys we list as supported
> > fall into this category:
> > 
> > https://access.redhat.com/knowledge/docs/en-US/
> > Red_Hat_Enterprise_Virtualization/3.1-Beta/html/Administration_Guide/
> > Red_Hat_Enterprise_Virtualization_Manager_configuration_options_explanations_
> > limitations_and_best_practices.html
> 
> Alon?

Not sure if I am the right contact for this. I cannot say which parameters are cached at browser side.

I totally agree that UI should monitor server restart and reload whatever needed.

This can be done using a random seed generated when web application starts, if the seed is different at browser side it means server restart, and should expire all objects.
Comment 12 Einav Cohen 2013-08-16 16:54:50 EDT
(In reply to Alon Bar-Lev from comment #11)
> ...
> 
> This can be done using a random seed generated when web application starts,
> if the seed is different at browser side it means server restart, and should
> expire all objects.

I believe that "when web application starts" is not good enough [IIUC, upon browser restart/refresh (which is "when web application starts"), the updated configuration values are being loaded appropriately; this is also implied in (the duplicated) bug 989396].

on bug 989396, Itamar has suggested to clear config cache on re-login - it seems like a reasonable solution to me -> changing subject accordingly.
Comment 13 Einav Cohen 2013-08-16 16:56:22 EDT
*** Bug 989396 has been marked as a duplicate of this bug. ***
Comment 14 Alon Bar-Lev 2013-08-16 17:02:18 EDT
I do not think that clearing cache on each login is reasonable solution, especially in fat client application.

If you need to reload configurations, you can have some signature of all responses to be able to know that configuration has been changed and reload/auto logout.

This should be application logic, without dependency of browser features, to minimize issues with different browsers.
Comment 15 Itamar Heim 2013-08-17 04:30:57 EDT
isn't it reasonable to expect a logout action will clean the cache?
are you suggesting to add info to any engine call to know cache should be invalidated?
Comment 16 Alon Bar-Lev 2013-08-17 04:52:33 EDT
(In reply to Itamar Heim from comment #15)
> isn't it reasonable to expect a logout action will clean the cache?
> are you suggesting to add info to any engine call to know cache should be
> invalidated?

Maybe I do not understand what 'cache' is? Is it browser cache or application specific cache?
Comment 17 Itamar Heim 2013-08-17 09:18:06 EDT
(In reply to Alon Bar-Lev from comment #16)
> (In reply to Itamar Heim from comment #15)
> > isn't it reasonable to expect a logout action will clean the cache?
> > are you suggesting to add info to any engine call to know cache should be
> > invalidated?
> 
> Maybe I do not understand what 'cache' is? Is it browser cache or
> application specific cache?

application specific cache. since the application configuration doesn't change. the client caches the results of GetConfig queries
Comment 18 Alon Bar-Lev 2013-08-17 15:22:08 EDT
(In reply to Itamar Heim from comment #17)
> (In reply to Alon Bar-Lev from comment #16)
> > (In reply to Itamar Heim from comment #15)
> > > isn't it reasonable to expect a logout action will clean the cache?
> > > are you suggesting to add info to any engine call to know cache should be
> > > invalidated?
> > 
> > Maybe I do not understand what 'cache' is? Is it browser cache or
> > application specific cache?
> 
> application specific cache. since the application configuration doesn't
> change. the client caches the results of GetConfig queries

So ignore my comment.
Comment 21 Einav Cohen 2013-09-12 12:08:14 EDT
after talking to the BZ assignee: I was wrongfully under the impression that *all* of the configuration values are reloaded only upon browser restart/refresh, but I was wrong; actually, all of the configuration values are already reloaded upon login, except the applicationMode (originally reported here), which is being retrieved upon application load, which makes sense, as it potentially affects the entire application (including potentially the login page, etc.), therefore it doesn't make sense to re-load it upon login, as there is a chance that the login page should (is) already be affected by it. 
moreover: changing the applicationMode is not something that the admin is expected to do very frequently; therefore, requiring browser restart/refresh upon applicationMode change is totally acceptable. 
closing.

Note You need to log in before you can comment on or make changes to this bug.