Bug 536297 (RHQ-662)
| Summary: | support seamless upgrade process for resource key changes | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Joseph Marques <jmarques> |
| Component: | Plugin Container | Assignee: | Lukas Krejci <lkrejci> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 1.0.1 | CC: | cwelton |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://jira.rhq-project.org/browse/RHQ-662 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-16 08:38:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 536328 | ||
|
Description
Joseph Marques
2008-07-10 19:01:00 UTC
We'll need this when we implement the new resource key for apache instances which a customer is looking for. 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. 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? 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. 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. (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) Dropping to minor since the driving jira, RHQ-690, is no longer a high priority Future release Another related issue that could be addressed once this issue is resolved: https://jira.jboss.org/jira/browse/JBMANCON-378 And another related issue that can be addressed once this issue is resolved: https://jira.jboss.org/jira/browse/JOPR-78 This bug was previously known as http://jira.rhq-project.org/browse/RHQ-662 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? 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 *** |