Bug 536619 - (RHQ-950) Configuration: provide metadata that specifies which type of Resource Configuration storage a Resource type supports: MEMORY, PERSISTENT, or BOTH (i.e. where loads and updates are done from/to)
Configuration: provide metadata that specifies which type of Resource Configu...
Product: RHQ Project
Classification: Other
Component: Configuration (Show other bugs)
All All
low Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2008-10-06 18:39 EDT by Ian Springer
Modified: 2014-05-15 17:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-05-15 17:40:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2008-10-06 18:39:00 EDT
The GUI could then use this metadata as follows:

* for a Resource type that has storeType="MEMORY": all loads and updates are done from memory. 
* for a Resource type that has storeType="PERSISTENT": all loads and updates are done from disk or other persistent data storage
* for a Resource type that has storeType="BOTH": all loads are done from disk, but for updates the user can select whether:
   a) the update should only be persisted to disk, or
   b) the update should also be persisted to memory (i.e. put into effect in the running server instance)

As a concrete example, in the current code, if the user updates a JMS Queue's resource config, the changes are persisted to the associated xml file, but if that Queue is deployed via a nested config file (e.g. within a SAR) or the deployment scanner is disabled, that Queue continues using the old config until its xml file is either manually redeployed or the app server is restarted. Even if the deployment scanner is enabled and it is deployed at the top level, the in-memory Queue would not get updated until next time the deployment scanner runs (60 seconds by default in EAP). The feature proposed by this JIRA would give the user the ability to choose to immediately enact the change to the running Queue by selecting an "update configuration in memory, as well as to disk" checkbox when updating the config.
Comment 1 Ian Springer 2008-10-06 23:04:26 EDT
(6:53:29 PM) ccrouch: I agree there is some mileage in letting people choose between updating the current running image or waiting for the change to get picked up at restart
(6:53:55 PM) ccrouch: but then we're going to have to maintain two config copies
(6:54:02 PM) ccrouch: one of the currently running version
(6:54:11 PM) ccrouch: and one of the version which is about to be running
(6:54:28 PM) ccrouch: if they choose to have it take effect later
(6:54:49 PM) ccrouch: its quite an advanced use case, compared to where we are now :-)

No, you wouldn't have to maintain two config copies. For configs with a storeType of "BOTH", if the user does not choose the "update configuration in memory, as well as to disk" option when updating the config, the configuration update will only be persisted to disk and only this version of the config will be saved to JON's config history. Just as it is today, the in-memory version will not be saved to the JON history. The only time the in-memory version will be saved to JON's history is when the storeType is "MEMORY".

Comment 2 Greg Hinkle 2008-10-13 16:45:19 EDT
I'm not so sure about this one. If there are potentially multiple definitions of what the current config is (on disk vs. in memory) then we can't show the user accurate information. I'm in favor of leaving it up to the plugin to define current.
Comment 3 Red Hat Bugzilla 2009-11-10 16:20:17 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-950

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