Hi all. On suggestion of heiko - I am posting here about a possible patch to InventoryManager - but not sure if it is a good idea.
Adrian Brock and I have been using RHQ - lots of deployments/undeployments etc..:
If you deploy UserDS-ds.xml then delete it (undeploy it). Then try to redeploy it, the inventory status stays at "DELETED" rather than going back to "COMMITTED". Running a full, manual, detailed discovery on the platform will fix the problem. So that might have to be our be our workaround until we can get a fix?
I think Ive tracked the problem down to the InventoryManager, it is basically missing setting the inventory status when it already has the resource, but it is not in the state COMMITTED.
public Resource mergeResourceFromDiscovery(Resource resource, Resource parent) throws PluginContainerException { // If the Resource is already in inventory, make sure its version is up-to-date, then simply return the // existing Resource. Resource existingResource = findMatchingChildResource(resource, parent); if (existingResource != null) { updateResourceVersion(existingResource, resource.getVersion());
+ // proposed fix - make sure merged resources go back to committed + existingResource.setInventoryStatus(InventoryStatus.COMMITTED);
return existingResource; }
// Auto-generate id and auto-commit if embedded within JBossAS. if (!this.configuration.isInsideAgent()) { resource.setId(this.temporaryKeyIndex.decrementAndGet()); resource.setInventoryStatus(InventoryStatus.COMMITTED);
This matches what used to be done in the old ResourceFactoryManagerBean.createInventoryResource() until that code was orphaned.
Does this make sense at all?
If you deploy UserDS-ds.xml then delete it (undeploy it). Then try to redeploy it, the inventory status stays at "DELETED" rather than going back to "COMMITTED".
Running a full, manual, detailed discovery on the platform will fix the problem. So that might have to be our be our workaround until we can get a fix?
Yeah, that does sound like a workaround. You can do that in one of several ways:
1) use the "inventory" agent prompt command 2) from the GUI (or CLI) invoke the "manual discovery" operation on the platform resource 3) resource the plugin container or the agent itself
I think Ive tracked the problem down to the InventoryManager, it is basically missing setting the inventory status when it already has the resource, but it is not in the state COMMITTED.
public Resource mergeResourceFromDiscovery(Resource resource,
...
// proposed fix - make sure merged resources go back to committed
existingResource.setInventoryStatus(InventoryStatus.COMMITTED);
...
Does this make sense at all?
This seems to make sense. However, I question blindly setting the status to COMMITTED. I'm thinking it might also be possible that the existing resource could be appropriately be in the NEW state - and in that case, setting it to COMMITTED here might be wrong.
That's just a theory - I can't say for sure if, at this point in the code, the resource could be in any other state other than COMMITTED. We may need to put some kind of conditional around this, say something like:
if (existingResource.getInventoryStatus() == InventoryStatus.DELETED) { existingResource.setInventoryStatus(InventoryStatus.COMMITTED) }
I'm assuming you stepped through this in a debugger - what state was the existingResource in at that point in this mergeResourceFromDiscovery method?
Hi John,
On 19 October 2010 13:51, John Mazzitelli mazz@redhat.com wrote:
This seems to make sense. However, I question blindly setting the status to COMMITTED. I'm thinking it might also be possible that the existing resource could be appropriately be in the NEW state - and in that case, setting it to COMMITTED here might be wrong.
Looking at the parent status might be more accurate?
That's just a theory - I can't say for sure if, at this point in the code, the resource could be in any other state other than COMMITTED. We may need to put some kind of conditional around this, say something like:
if (existingResource.getInventoryStatus() == InventoryStatus.DELETED) { existingResource.setInventoryStatus(InventoryStatus.COMMITTED) }
I'm assuming you stepped through this in a debugger - what state was the existingResource in at that point in this mergeResourceFromDiscovery method?
It was DELETED. Which is what causes the problem. You remove a service then try to put it back, but it stays DELETED.
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-devel
I captured this thread in bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=644409
On 10/19/2010 10:02 AM, Adrian Brock wrote:
Hi John,
On 19 October 2010 13:51, John Mazzitelli <mazz@redhat.com mailto:mazz@redhat.com> wrote:
This seems to make sense. However, I question blindly setting the status to COMMITTED. I'm thinking it might also be possible that the existing resource could be appropriately be in the NEW state - and in that case, setting it to COMMITTED here might be wrong.
Looking at the parent status might be more accurate?
That's just a theory - I can't say for sure if, at this point in the code, the resource could be in any other state other than COMMITTED. We may need to put some kind of conditional around this, say something like: if (existingResource.getInventoryStatus() == InventoryStatus.DELETED) { existingResource.setInventoryStatus(InventoryStatus.COMMITTED) } I'm assuming you stepped through this in a debugger - what state was the existingResource in at that point in this mergeResourceFromDiscovery method?
It was DELETED. Which is what causes the problem. You remove a service then try to put it back, but it stays DELETED.
rhq-devel@lists.fedorahosted.org