I have a resource, say a script file one disk. If this file is removed, I want RHQ to remove the resource for inventory as well. I know RHQ availability would be 'DOWN' in this case, but I want the resource to be removed without administrator intervention.

The only approach I see is:

* Plugin container calls AvailabilityContext.disable() when it knows it is gone.

* Some RHQ CLI job runs and uninventories those resources that are disabled.

I was thinking that maybe InventoryContext could have a method that removes this resource, e.g.

Can you use the drift feature for this? Set an alert to see drift on the file you want to look for - if the file goes away, that would be considered drift I think. I don't know if you can be told if the file changed versus was totally removed though. But an alert CLI script could be used to uninventory the resource represented by the file that drifted? I am not well-versed in the whole drift capability, so this may be wishful thinking - but I would look into it just to see if its possible to do what you want.

I'm not interested in files per se but I thought it would make the explanation better.

I am discovering and creating resources based on data from a database table and I want to remove those resources if the table data is removed. These resources run system commands to check the system similarly to a Nagios check service command.

Since the database table is the authority on what needs to be checked or not, I would prefer some way to remove those resources directly from the plugin itself.

We don't automatically uninventory resources on the server if they can no longer be seen by the agents because there generally is no telling about the reason the resource "disappeared" - it might have been intentional, it might highlight a security breach - we just don't know.

Now for your usecase, I do think your request makes sense (I think we saw a couple of other usecases that made sense in the past, too).

The simplest way to implement this would be to mark a resource type as "ephemeral" and let the server automatically uninventory resources that disappear from the periodic discovery results sent up by agent. The question is how to mark the resource type as such. I don't like the idea of doing that directly in the plugin descriptor, because an administrator might think otherwise - they might be interested in keeping track of resources going away for whatever reason. So I think this decision should be made by the admin and therefore this becomes entirely a serverside feature, with no code/descriptor changes necessary on the agent/plugin side. The question then becomes how granular should this be? Any resource with given resource type? Child resources with particular resource type under certain parent ? Hand-picked resources? (Btw, could we somehow use dynagroup expressions for specifying these?)

Do you think this approach would make sense in your case, Elias, and how granular do you think it should be?

Unfortunately, I don't think there is a way to script this at the moment - you could hang a script on the AVAIL_GOES_DOWN or AVAIL_DURATION_DOWN on a resource, but there is no way of finding out if a resource is present in the discovery queue or not using our remote API.

In another words, I can see a couple of feature requests here (with the usual disclaimer that we can't guarantee when this would go in, unless you wanted to step up and implement this functionality yourself, with which we would be more than glad to help)

I'm looking for the easiest solution that works. For better or worse, I was thinking of just calling the InventoryManager.uninventoryResource() from the agent side and seeing what happens... (probably not what I want.) If it doesn't then I will return DISABLED.

Here's what I would do: (if I had the time and inclination)

1) I would try to create a new availability type. But I'm not really familiar with the UI and how to do this. It does make sense to create not only a DOWN type but a MISSING or ABSENT value.

2) I would make some sense to add some sort of script automation via the UI. Why not support upload and running CLI scripts through the UI, including perioidic execution? This would be good for a number of use cases. Provide a series of pre-made scripts that users might want. Then checkboxes and frequency values for those jobs.

3) I think making general UI support for, say, 'remove all ABSENT child resources' automatically for a parent resource may be a good idea but it would be hard to get this right.

Adding an AvailabilityType is very intensive and that is unlikely to happen for this requested feature.

As Lukas mentioned, typically an avail check just knows that the resource can not be contacted. It has no idea if a resource is actually physically gone. And even if it is, it may come back. We can't make any assumptions.

This would need to be handled either by a very "aware" plugin that 1) knew how to distinguish "down" from "missing" and 2) performed an agent-side request to uninventory the resource. Or, in some other user-initiated way. Perhaps an alert on GOES DOWN that performs an uninventory via script.

I know adding a new AvailabilityType is a bit of stretch, but you have expanded the number of values quite recently, so it seemed reasonable at the time.

I settled on creating a resource trait 'enabled' which I can query via the RHQ command line tool and then issue removal of those resources.

I would still prefer having a way to schedule repeated execution or JavaScript (or Python) within RHQ itself, but this job is run from a crontab and not really super-critical to require some sort of UI support.

Still I believe adding a method to InventoryContext allowing resources to be uninventory would be a good feature, but I don't know the implications.