univentory button missing for services (EAR)

[h_ti]

We are testing Jopr 2.2.1 and we miss a functionality to uninventory an EAR, since it is no longer deployed. The problem occurs with every new version of our EAR, since the Version-Number is part of our EAR-filename.

In the article http://josephmarques.wordpress.com/2008/05/07/physical-enterprise-vs-logical-inventory/ the difference between UNINVENTORY and DELETE is described. Deletion is at the moment also not possible, since the physical deletion occurs during our deployment process directly in the filesystem. If the file is already deleted, it is no more possible to delete the EAR via the inventory. We get a failure message.

So we looked to resources/services. There is a checkbox in front of our EAR service, but there is no button to invoke the uninventory.

We also could accept a solution to use wildcards filename and objectname in the inventory (connection). This fields are not editibale at the moment.

Thanks in advance,
Heiner

[pilhuhn]

In general this is intentional (until we come up with some better mechanism). Normally services would automatically show up at the next discovery scan, so users are confused why their uninventoried resource shows up again.

A workaround for your case could be to not remove the .ear by hand, but through the Jopr UI: go to the parents Inventory tab and then in the list of child resources select the ear and click on the delete button.

[joe.marques]

The issue is that if a service is uninventoried, it'll reappear shortly thereafter on the scan automatic discovery scan. Numerous customers did this and were confused by the results. The root problem is that users either:

1) wanted a way to delete those resources, not just uninventory them
2) wanted a way to permanently disregard / ignore those resources ( see http://jira.rhq-project.org/browse/RHQ-1516 )

For #1, it all depends on the plugins. Each plugin needs to explicitly support resource deletion for that specific type. If a resource type *is* deletable, then you can go to the Inventory tab of parent resource, find it in the "child resources" section, and *delete* it from there. This will remove it from the file system as well as from the inventory.

For #2, this is currently only supported for servers, and only from the auto-discovery portlet / page. If you haven't imported your server yet, you can "ignore" it from the auto-discovery portlet - it won't show up in your inventory, and it won't show up in the portlet on subsequent discovery scans. If you server was already imported into inventory you'll first need to uninventory it, it'll get rediscovered on the next periodic discovery scan, it'll show up in your auto-discovery portlet, and you can ignore it from there.

So, to prevent confusion for the majority of customers that tried to uninventory resources (again, when 99% of the time they really wanted to either delete them or ignore them) we suppressed that button in the UI (see http://jira.rhq-project.org/browse/RHQ-372 ).

However, for the 1% of the cases where it actually makes sense to uninventory the service -- for instance, when the resource has been physically removed from the disk from some process external to the management software -- we actually left the functionality in the product. If you go to the services tab in inventory and add "&debug=true" you'll get the button back and should be able to uninventory your "dead" resources. If they are in fact dead (i.e., have no representation on disk anymore), it will not be rediscovered and will thus not automatically show up in your inventory again.

[j_ri]

If the file is already deleted, it is no more possible to delete the EAR via the inventory. We get a failure message.

Why does the deletion of a file (EAR) that is already deleted result in an error message?
JOPR should behave as if the deletion process worked fine....the file is not there any more after I pressed "delete", so it has been successful;-)

[joe.marques]

Ah, if that's what's happening, then that's a bug. I'll search our JIRA repository and if I can't find a corresponding ticket, I'll create a new one. This should be an easy fix.

In the meantime, since it's already deleted off the file system, the "&debug=true" trick from the services tab of the inventory should work for you as a workaround.

[h_ti]

Thanks for your help and very good explanations.
We added "&debug=true" to the URL and could now undiscover the application.
"Delete" is certainly the better solution, but it should not fail if the file dosn't exist anymore. If that's accepted as a bug i am happy.

But what do think about a solution to use wildcards in filename and objectname in the inventory (connection) to avoid reconfiguration for every new version of the application. This fields are not editibale at the moment.

Heiner

[pilhuhn]

Honestly, I don't know if it is a bug that delete is failing.
We do have a different inventory state from what we expect - so this is an error.
But then as we can't get rid of the orphan ...

https://jira.jboss.org/jira/browse/JOPR-295