Bug 536297 - (RHQ-662) support seamless upgrade process for resource key changes
support seamless upgrade process for resource key changes
Status: CLOSED DUPLICATE of bug 592038
Product: RHQ Project
Classification: Other
Component: Plugin Container (Show other bugs)
All All
low Severity medium (vote)
: ---
: ---
Assigned To: Lukas Krejci
: FutureFeature
Depends On:
Blocks: RHQ-690
  Show dependency treegraph
Reported: 2008-07-10 15:01 EDT by Joseph Marques
Modified: 2010-11-16 03:38 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-16 03:38:22 EST
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 Joseph Marques 2008-07-10 15:01:00 EDT
use case: after some plugin has been released and used in the field for some time, we realize that the resource key doesn't uniquely identify resources as well as we thought it would...to the extent X different resources are discovered as a single resource instance, suppressing X-1 of them.

so, if we enhance the plugin to use a better resource key, then we have the issue that any pre-existing resources using the old key will be orphaned.  since resource key is the mechanism by which we match up existing, server-side persisted resources with agent-side discovered resources during the inventory sync/merge process.  so, it would be nice if there existed a mechanism to improve resource key uniqueness for customers that need additional uniqueness per agent, but which kept the existing resources already in inventory working.  

a quick strategy, not to difficult to implement would be:

* add optional getPreviousKey to the api
** if previousKey != null && previousKey != newlyDiscoveredKey && previousKey == persistedKey, then update persisted key to use newly discovered key
Comment 1 Charles Crouch 2008-07-17 15:33:21 EDT
We'll need this when we implement the new resource key for apache instances which a customer is looking for.
Comment 2 Ian Springer 2008-07-17 16:11:19 EDT
I'm not sure the getPreviousKey() API strategy will work. In the Apache case, if the current version of the Apache plugin, which uses the server root dir as the key, only finds 1 out of 10 of running instances that all share the same server root dir, then the new version of the Apache plugin, which uses the httpd.conf file path as the key, finds all 10 of the running instances, then getPreviousKey() would return the server root dir for all 10 instances, and there would be no way for the PC to match the correct instance up to the Resource that was discovered by the old version of the plugin.
Comment 3 Joseph Marques 2008-07-17 16:23:06 EDT
hmm...because we'll find ten, and we only want 1 of them to map to the exist instance and the other 9 as new instances?  what would actually happen in this case?  would each instance discovery try to map to the existing one, and then the last guy would win?  if that's the case, even though it's odd, maybe it's ok. 

perhaps, though, we need a more sophisticated strategy if we want to support this?
Comment 4 Ian Springer 2008-07-17 16:28:20 EDT
Yeah, I think the last one would win. The problem is, the last one might not correspond to the same instance that was originally discovered, and in that case, you'd have a bunch of historical data on the Resource that corresponds to some other Apache instance.
Comment 5 Charles Crouch 2008-07-17 16:44:00 EDT
I don't think we need to support this case, at least I'm not aware of any circumstances when a plugin has munged N servers to 1 server and then the user has been happily going along just monitoring the one. Instead most people complain immediately that autodiscovery is broken. I don't think its feasible to let the user choose which of the new instances mapped to the old instance.

In the specific instance of the customer with the Apache Server, I don't believe any instances are currently being monitored since not all of them could be added to the inventory.
Comment 6 Charles Crouch 2008-07-17 17:28:45 EDT
(3:54:32 PM) ips: to make the API most flexible, we might want to make it getPreviousResourceKeys()
(3:54:44 PM) ips: and return Set<String>
(3:55:05 PM) ccrouch: to deal with multiple changes?
(3:55:10 PM) ips: yeah
(3:55:18 PM) ccrouch: v1 -> v2 -> v3 ?
(3:55:36 PM) ccrouch: or really v1 -> v3 and v2 -> v3
(3:56:42 PM) ips: yeah, the latter i think
(3:57:19 PM) ips: if (getPrevKeys().contains(existingResource
(3:57:47 PM) ips: .getKey()) then existingResource.setKey(newKey)
Comment 7 Charles Crouch 2008-07-24 15:10:39 EDT
Dropping to minor since the driving jira, RHQ-690, is no longer a high priority
Comment 8 Greg Hinkle 2008-07-29 22:16:50 EDT
Future release
Comment 9 Charles Crouch 2008-08-18 12:52:30 EDT
Another related issue that could be addressed once this issue is resolved:
Comment 10 Ian Springer 2009-06-02 10:40:35 EDT
And another related issue that can be addressed once this issue is resolved: 
Comment 11 Red Hat Bugzilla 2009-11-10 16:14:15 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-662
Comment 12 Joseph Marques 2010-10-05 11:59:50 EDT
lukas, found this old bug.  how do you think your resource upgrade solution compares to the discussion in this thread?  can we close this issue out now?
Comment 13 Lukas Krejci 2010-11-16 03:38:22 EST
The solution is in the end slightly different from what was suggested here.

The "upgrade" process, i.e. the change of the resource keys, happens during the plugin container initialization, before any discoveries. On the PC startup, the inventory is synced with the server and each resource is examined if it is a candidate for upgrade. If the discovery component of a resource type implements a "ResourceUpgradeFacet", it is asked to "upgrade" that particular resource - i.e. provide the new resource key. The upgrade method has access not only to the old resource key, but also to plugin and resource config of the existing resource so that it can use as much information as possible.

Once the upgrade process has finished, the PC continues with the "normal" start-up as it used to. Once the discovery kicks in, the "old" resource already has a new resource key and thus is correctly matched with the new-style discovery results.

By splitting the upgrade from discovery, the logic is greatly simplified in both the discovery logic (that can just change) as well as the upgrade logic, which can just focus on correctly matching an old resource with a new-style resource key. There is no need to define the previous keys set for each resource.

In the case of Apache, the "old" resource has a resource key comprised of the server-root directory but contains the path to the httpd.conf in the plugin config. By examining that info, we can correctly generate the new style resource key for that instance (i.e. find the correct one out of the ten instances in the discussion above). When the new-style discovery kicks in, all matches.

*** This bug has been marked as a duplicate of bug 592038 ***

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