resource type ignoring

John Mazzitelli mazz at redhat.com
Fri Mar 8 16:49:18 UTC 2013


[this is more for charles - but I want to put this on the devel list to have a transparent and public thread]

I would like to start a thread dealing with BZ 535289 (aka RHQ-1) - this was a use-case being discussed:

> https://bugzilla.redhat.com/show_bug.cgi?id=rhq-1 specifically:
> 
> Suppose I have machines with multiple agents, each potentially
> having ~40k child service resources of a particular type in a given agent
> inventory.
>
> Suppose I do not care about all of those resources, but I do care about some of them.
> How can we support monitoring certain resources while not all 40k.

This is where RHQ-1 comes in - the ability to "disable" resource types (or, said another way, ignore a bunch of resources of a given type).

There are three things here.

1) Be able to disable all new resources for a specific resource type. So, if I go to a (as yet non-existent) Administration page, I click some buttons to say "disable type 'foo'", then anytime the agent sends a inventory report with resources of that 'foo' type, we ignore them.  They never get into the discovery queue and never get a row in RHQ_RESOURCE table. If they are already in the discovery queue, you already have the option to "IGNORE" them, so that's already a feature and has been for a while. But what if their parent is in the queue? (the parent is not an ignored type). If we commit the parent, the agent will send up the child services of type "foo" and we simply ignore them - we don't commit those ignored resources and we throw them away.

This is the "all of them" approach - we ignore all resources of a given type.

2) Be able to ignore a select number of resources already in inventory. We could do this from the inventory pages - I select some resources, click a (as yet non-existent) "Ignore" button, and they get ignored - hidden from view - and the agent will somehow need to disable or ignore them as well. This sounds just like uninventory - but the problem is, the agent will simply rediscover them during the next discovery run. We need to somehow tell the agent "uninventory these resources and don't discover them again". How do we indicate this inside the agent? I don't know. We probably need to keep the resource in the agent's inventory with a status of IGNORED. But if we have 40,000 resources, and we want to IGNORE all of them (or at least most of them), the agent's memory utilization could be large for holding resources we don't care about. I don't know a way around this - we may have to just suck it up and use the memory.

3) Be able to not ignore a small amount of resources, but ignore all the rest. This is very similar to #2 above, but this goes to the fact that I might have an agent discover 40,000 resources, but I only care about, say 100 of them. How do we do this?

This #3 is the most difficult one. How do we ask the user to select 39,900 resources and press the ignore button? Not realistic. Not only that, but in the case where those 40k are child services, today we never get a chance to accept or reject them from the discovery queue - once the parent is committed, only then does the server even get to know what's underneath it (the agent will only discovery child services after the parent is committed).

I think this may involve a big change - in the discovery queue, we may have to support a new option when pressing the Import button - somehow we need to support an option "do not committed child services".  This would then commit the server but then somehow show the child services in the discovery queue, at which time you can pick which ones you want to commit to inventory (thus, you only pick 100, and you keep the other 39,900 in the queue in NEW state - I suppose you could opt to then IGNORE them? Many problems abound with this. The UI tree in the queue view doesn't support N layers deep - only the top platform and the immediate child servers are shown. Also, how do we show 40,000 (or something that large) rows in the tree?  Do we hit performance problems in the UI?

This is a huge change - from the discovery queue UI down to the server then to the agent, changes would need to be made to support this.

So, #1 and #2 should be doable (though difficult to fully implement). #3 is very difficult and would require some design changes and some deep thinking as to how this would effect all tiers of RHQ. At this point in time, I'm thinking we just don't attempt #3.


More information about the rhq-devel mailing list