Adding the option to reload configurations without restarting JBoss. Will allow admin to reload from the rhevm-config command line. Feature design in http://www.ovirt.org/wiki/Features/ReloadableConfiguration.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The Reloadable Configurations API will be considered a tech preview in version 3.1 and might not be supported in future versions.
how/where does user provides credentials to access engine via REST API to perform the reload operation? (or is another communication channel assumed?)
(In reply to comment #1) > Technical note added. If any revisions are required, please edit the > "Technical Notes" field > accordingly. All revisions will be proofread by the Engineering Content > Services team. > > New Contents: > The Reloadable Configurations API will be considered a tech preview in if tech preview, the tech preview keyword should be used. also, tech preview doesn't mean the feature doesn't need qe_ack+ and some sanity testing. > version 3.1 and might not be supported in future versions. however the technical note conflicts with the definition of tech preview[1] (you can't put something into tech preview if it is not going to be supported in a future version) "A feature can qualify as Technology Preview or TP status if it meets the following conditions: 1. Red Hat will fully support it in subsequent minor or major release. 2. It's described functionality is testable. 3. Red Hat will provide high severity security erratas for the feature." (although it sounds like there is a process to remove a TP feature under the section "How to drop TP feature") [1] https://home.corp.redhat.com/node/32279
Muli - we should make sure that this option is marked as tech preview in the config tool so it's clear to users.
(In reply to comment #2) > how/where does user provides credentials to access engine via REST API to > perform the reload operation? > (or is another communication channel assumed?) we prompt the user for user/pass
I change the technical note to emphasis that we do not commit to backwards compatibilty in the API for this feature. If it is not clear you are welcomed to revise it.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -The Reloadable Configurations API will be considered a tech preview in version 3.1 and might not be supported in future versions.+The Reloadable Configurations API will be considered a tech preview in version 3.1, the API may change in the future versions in an incompatible way.
Please indicate what was implemented and how to test this.
The following was implemented: 1. There is a new action in the engine-config tool: --reload. When using this action, all reloadable configurations are loaded from vdc_options to the engine, with no need to restart. 2. A new flag --only-reloadable, to be used in the --list action, to receive a list of only the reloadable configurations.
Moving to rhevm-future - won't make 3.1
Reloading is enabled through the API - already in the code base: http://gerrit.ovirt.org/#/c/4503/ Remaining gap: Adding the functionality to the engine-config CLI as explained in Comment 12.
moved back to new - to reset the work on this issue
Martin Mucha has submitted patches that to my understanding fix some gaps in the REST implementation, and has verified that it works. Adding the support to engine-config doesn't sound too difficult; maybe we want to get this done for 3.6? Wouldn't this be an easy win?
(In reply to Lior Vernia from comment #25) > Martin Mucha has submitted patches that to my understanding fix some gaps in > the REST implementation, and has verified that it works. Adding the support > to engine-config doesn't sound too difficult; maybe we want to get this done > for 3.6? Wouldn't this be an easy win? Sorry for the late response. I'm not sure about the current status of this feature. What gaps were addressed in these patches? What's missing from the feature after merging these patches?
I wanted options of mine feature to be reloadable without restart. I found that there's command, forcing engine to reload data. But it contained a bug. So I fixed it (now the ReloadConfigurationCommand works), and did minor refactoring. Prior to this change ReloadConfigurationCommand only cause engine to reload data to in-memory cache. But that does not change anything. Only when <something> queries that option again, it will see the new value. Which is insufficient. So as a part of ReloadConfigurationCommand, changed options are now identified, stored in memory, and it's fired event(CDI event) informing all listeners about changed options. It's up to them if they do something with this information. My MAC Pool is probably the sole listener so far and it reinitializes it's internal structures to comply with new settings.
So it seems like if you do the following, you can reload the configuration entries that are reloadable: 1. As a developer * you need to have the config entry annotated as @Reloadable. * Optionally, you can use the user the events mentioned in Comment #27 2. As a user, you need to issue this API request to reload the configuration. Seems like that allows to close this RFE. Some other RFEs will need to be opened for specific keys, to make them reloadable, but the infra is there. Moti - am I accurate? If so, I'll move the RFE to modified, targeting to 3.6.0.
(In reply to Oved Ourfali from comment #28) > So it seems like if you do the following, you can reload the configuration > entries that are reloadable: > 1. As a developer > * you need to have the config entry annotated as @Reloadable. > * Optionally, you can use the user the events mentioned in Comment #27 Observing updated-config-values events patch wasn't merged, since the approach to notify any subscriber for all of the events doesn't seem optimal to me. In addition, up until now, there wasn't a need for that functionality - hence the decision of which design will serve better config-value-change clients was postponed as well. If there is such need, to allow the system to observe a specific event(s), we need to revive that discussion. > 2. As a user, you need to issue this API request to reload the configuration. > > Seems like that allows to close this RFE. Some other RFEs will need to be > opened for specific keys, to make them reloadable, but the infra is there. > > Moti - am I accurate? The reloadable configuration values can be divided into 2 types: static and dynamic. The static types are read from the cache each time a certain flow is required to use them. So no change to existing flow from the change in config value perspective. The dynanic types requires further applicative change, for example, when using a config value to define the thread pool size, and if wishes to dynamically resize it, there is a need to shutdown the existing one and starting a new one with the new value, or the time between monitor threads requires deleting quartz job and creating them again. The concept here is a code which is invoked once in the application, based on a certain configuration, cannot be updated itself by changing the config value and refreshing the cache alone. Some code should be executed for that change to take effect (when/if possible). So currently we support only the 'static' types. Some work should be done to provide the infrastructure for 2, and then it become the developer responsibility to implement its own 'config-value-change' triggered event (as mentioned in the response of the first bullet). > If so, I'll move the RFE to modified, targeting to 3.6.0.
Moving to MODIFIED. What's supported is: As a user, you need to issue this API request to reload the configuration. It will only work for entries annotated with @Reloadable.
*** Bug 1204844 has been marked as a duplicate of this bug. ***
*** Bug 1057967 has been marked as a duplicate of this bug. ***
Closing based on fact most config items aren't reloadable, and there is no customer requirement for this request.
(In reply to Scott Herold from comment #42) > Closing based on fact most config items aren't reloadable, and there is no > customer requirement for this request. I'm sorry, I just don't think so. There are many options which are working already, plenty of others which can easily be enabled to work correctly. If some of the parameters marked as reloadable today doesn't work then disable them, but I don't think we should generally dismiss this functionality. Necessity to restart ovirt-engine is one of the most frequent complaints I hear when dealing with these parameters. There are quite a few ideas and suggestion in earlier comments, it sounds entirely feasible to do so in not-so-distant future