+++ This bug was initially created as a clone of Bug #535289 +++ We would like a feature in RHQ such that an admin can completely disable or ignore a resource type from being managed. For example, suppose I do not want to manage any Postgres databases. I should be able to go to the Administration page and "disable" the postgres plugin's resource type for Postgres database servers (which should also disable child types). Would also be nice to completely disable a plugin, which could be as simple as saying, "all resource types defined by this plugin are to be ignored". A possible solution is as follows: a) have an admin page that gives you a list of all resource types and you select the ones you want to "ignore" b) when an inventory report comes in, have it completely ignore/not process those resources of an "ignored" type (DiscoveryBossBean.mergeInventoryReport would be where this would be done). So the resource won't even make it into inventory if its of an ignored type c) have the two "updateInventoryStatus" and/or "setResourceStatus" in ResourceManagerBean to ignore the request and not do anything if the status to change to is COMMITTED and the resource's type is an "ignored" type (this would only be necessary for those resources that were already discovered before the types were ignored - in this case, the resources would remain in the NEW status - probably not a good thing to have resources always in the NEW status - maybe when you mark a type as "ignored" in a) we go through and purge all resources of that type. The whole idea, therefore, is to not have the resources in inventory at all (if they are one of the "ignored" resource types). If you can be assured only the resources in RHQ_RESOURCE are valid, unignored types, then everything else works fine as-is. The only question then becomes, how do you tell the agent that it should remove resources it discovered from its internal inventory? Perhaps the return value of mergeInventoryReport is a List<Resouce> of those resources that were not merged and should be purged from the agent inventory. I'm not sure I have a good handle on how this particular issue should work and I would like a discussion in this JIRA to flush this out. --- Additional comment from John Mazzitelli on 2008-02-22 11:30:32 EST --- See forum thread I started on this so we can discuss over there: http://forums.rhq-project.org/viewtopic.php?f=5&t=14 --- Additional comment from John Mazzitelli on 2008-02-27 11:58:50 EST --- don't know when this will be implemented. as a workaround, you can delete plugins from the rhq.ear/rhq-downloads/rhq-plugins prior to agents connecting to the server. This removes all resource types from the deleted plugins - so those resource types will not be manageable in your environment. --- Additional comment from John Mazzitelli on 2009-04-08 13:53:41 EDT --- RHQ-1930 introduces the concept of a discovery component blacklist (needed to avoid the agent crashing due to trying to call misbehaved plugin discovery components). But this also has the side effect of essentially not discoverying resources of a specific type. We can add to this concept by being able to, on the fly, tell the PC "ignore resource type X" --- Additional comment from John Mazzitelli on 2009-05-20 08:41:58 EDT --- If you want to remove a plugin from the system, I think these are the manual steps you need to do: 1) shutdown your agents 2) uninventory the platforms that have resources whose types came from the plugin you want to remove 3) shutdown your servers 4) remove the plugin .jar file all your servers' file systems (jbossas/server/default/deploy/rhq.ear/rhq-downloads/rhq-plugins) 5) Using a DB client tool (pgAdminIII, dbVisualizer, sqlplus, whatever), you need to remove the plugin row from the database table RHQ_PLUGIN ("delete from RHQ_PLUGIN where name = 'your plugin name as defined within its descriptor') 6) Using same DB tool, remove all resource types that were defined by that plugin - "delete from RHQ_RESOURCE_TYPE where plugin = 'your plugin name" 7) Restart your servers 8) Restart your agents with the --cleanconfig option Someone let me know if this didn't do everything, I just wrote that up by memory - no testing --- Additional comment from Red Hat Bugzilla on 2009-11-10 15:55:48 EST --- This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1 This bug is related to RHQ-2 This bug is related to RHQ-847 This bug is related to RHQ-1930 --- Additional comment from wes hayutin on 2010-02-16 11:58:18 EST --- Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug --- Additional comment from wes hayutin on 2010-02-16 12:03:11 EST --- making sure we're not missing any bugs in rhq_triage --- Additional comment from Charles Crouch on 2010-05-17 18:31:31 EDT --- RHQ-2 is the maximum extent of support in this area for JON2.4 --- Additional comment from Charles Crouch on 2012-03-26 16:39:12 EDT --- Trying out rally integration --- Additional comment from Charles Crouch on 2012-03-28 10:53:11 EDT --- Ignore updates: Trying out rally integration --- Additional comment from John Mazzitelli on 2013-01-29 08:46:17 EST --- recently added the agent config "rhq.agent.plugins.disabled-resource-types" that disables types on the agent. The agent won't discover new resources of that type (or of child types) and if you already have resources of that type, they will appear RED/DOWN. --- Additional comment from John Mazzitelli on 2013-03-05 13:28:08 EST --- If have a prototype with only server-side code that ignores resource types. If a inventory report from an agent has a resource of an ignored type, it won't get into inventory (you won't see it in the discovery queue). If a parent is in the queue and you import it, any children won't be imported. A few issues - if the resource is already in the queue and then you ignore it, you can never take it out of the queue (it won't get committed, it stays in the NEW state which means it stays in the queue). You can click the "IGNORE" button in the queue view, but that's a different ignore. The agent knows nothing about this. So it will still have NEW resources in its inventory. They will never get committed (so the components won't be started) however, they will still show in the inventory view of the agent (it will use some extra memory for sure - there just won't be started components because the server will never tell the agent the resources are committed). --- Additional comment from John Mazzitelli on 2013-03-19 16:00:23 EDT --- Might be nice to support this in the agent plugin descriptor: <xs:attribute name="ignored" use="optional" type="xs:boolean" default="false"> <xs:annotation> <xs:documentation> Indicates if this resource type should be ignored by default. If a resource type is ignored then resources of that type will not be discovered by the agent and resources of that type will not be manageable. This setting only defines the initial default setting for the resource type. Users will have the opportunity to enable (i.e. unignore) an ignored resource type if they wish to have resources of that type in their inventory. </xs:documentation> </xs:annotation> </xs:attribute> There are issues we'll have to deal with before we consider doing this. Setting this means that the agent will always, be default, ignore this type. Since the server is only the thing that maintains the ignore/unignore flag on a type, if the agent starts up with no connectivity to the server, it can only go by what's in the descriptor XML metadata. If a plugin has ignored=true, then the agent must go with that and thus ignore all resources of that type. Only until the server syncs with the agent will the agent know a resource type has been enabled (and thus the agent would only then know to start managing resources of that type). To get around this, we'd need to now sync resource types - something we do not do today. --- Additional comment from John Mazzitelli on 2013-03-28 20:44:08 EDT --- the latest code in branch bug/rhq-1 has this implemented. --- Additional comment from John Mazzitelli on 2013-04-09 17:43:41 EDT --- big commit to master: a75b8c371d6f8ce096adc0ddd9bf00d2d753b500