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.
I see java pid change every restart. Service restart is implemented as stop/start. No clue how could this happen. Can you please reproduce?
(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.
As it seems, the value comes from cache at browser side. Please try to disprove. Thanks.
actually, i think the WPF had the same cache as well, so don't think this is a regression.
(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.
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
(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.
(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
> > 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?
(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.
(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.
*** Bug 989396 has been marked as a duplicate of this bug. ***
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.
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?
(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?
(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
(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.
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.