A bunch of questions...

Jay Shaughnessy jshaughn at redhat.com
Thu Aug 4 18:18:47 UTC 2011



On 8/3/2011 2:36 PM, John Mazzitelli wrote:
>> In creating the agent plugin we have added a number of operations that
>> are really intended to be used by the Remote Java client program and not
>> the JON UI users.  Is there any way to hide agent operations so they do
>> no appear in the Operations menu or pull-down in the Operations tab?
>> Our work-around is to prefix the display name of the operations with
>> some character string that at least sorts them into a separate group.
> No.<operation>  metadata refers to operations that are exposed by the
> plugin to the users, either via UI or CLI.
>
> I assume these are operations that are exposed for use by your server
> plugin only? We have nothing in place or planned for such a feature,
> though it might not be too hard to implement something like this
> (perhaps add a hidden="true" attribute to<operations>  ????). Feel free
> to write up a BZ to track this request.
I don't know if it would work, but perhaps have a single operation that 
takes arguments that could in turn invoke "hidden" operations.  And 
don't document the arguments.  For example, the RHQ Agent has a 'Prompt 
Command' operation that just takes any legal command prompt string as an 
argument.
>
>> We are looking at a situation where we will have multiple alert
>> notifications to gather snapshots from multiple resources.  What is the
>> process for executing multiple notifications?  Are they executed
>> serially or in parallel?  If serial, is there a way to "chain" alerts to
>> get them to simulate parallel execution (at least get things going close
>> to simultaneously)?  Would multiple separate alerts on the same
>> conditions do any better?
> I think the alert notifications are invoked serially. Heiko R. might
> know more - I think he worked in the notifications area.
>
> I doubt multiple alerts on the same condition become more "parallel" -
> but we do put messages on a JMS queue whenever we deem an alert needs to
> be emitted - maybe that makes things more concurrent?
>
>> In a related question, we would really like an alert notification to do
>> several things:
>>
>> - trigger diagnostic mode
>> - wait a while
>> - gather a diagnostic snapshot
>>
>> Is it OK to have an alert wait?  Is there a better way to do this like
>> "chaining" or something similar?  Can we get multiple such notifications
>> going at the "same" time (previous question)?
> I don't think it matters if an alert notification takes a while to
> complete. Although, I can't say that we have long lasting notifications
> - but I don't think we have any kind of timeout going on there.
>
> Would have to check the code that calls the notification server plugin
> to see if there is any kind of time out going on there. Heiko?
>
>> Is there any way to manage the snapshot reports on the JON server?  At a
>> minimum we would probably want to age them off to prevent using all the
>> disk space.  Ideally, the user would manage them via the JON UI--is
>> there any support for this?  Can periodic scripts be scheduled on the
>> JON server to clean up these snapshots?  Our current default is to
>> schedule a periodic operation in the JON Server RHQ Agent, if available.
> Obviously, as you know, the snapshot stuff is not at all considered
> filled out. We don't do any managing of that such that we purge old ones.
>
> That said, you can easily write a server plugin that defines a scheduled
> job (you can do this easily via the server plugin descriptor metadata)
> and that scheduled job runs periodically every X (minutes, days, hours,
> whatever) and does whatever it is you want - such as purge a downloads
> directory of old files.
>
> If you already have a server plugin (which you do), just add this
> metadata to your plugin's descriptor. In your server plugin descriptor,
> you add to it a scheduled job and your plugin's job method (which you
> write and add to your server plugin component) will be called periodically.
>
> See:
> http://rhq-project.org/display/RHQ/Server+Plugin+Development#ServerPluginDevelopment-ScheduledJobs
>
> This should be easy to do.
>
>> At the lowest level we have some resources that represent "dynamic"
>> entities which may come and go.
> We can detect new resources - but when resources go away, we do not
> remove them from inventory. Any resource that makes it into inventory
> requires admin intervention to remove it (in other words, a human user
> needs to tell us, "this resource is old, we no longer want to manage it
> nor do we want to keep any audit trails associated with it around - so
> uninventory it".
A CLI job could feasibly remove resources based on some sort of 
criteria.  If at some point we finally offer a "Down and has been down 
for X amount of time" it may be feasible to set up alerting that will 
uninventory a "dead" resource.
>
>>   Is there a way to schedule discovery or
>> set the discovery interval?
> The platform resource has a "Manual discovery" operation. Schedule it
> like any other operation. Its parameter "Detailed Discovery?" means (if
> true) you want to detect child services under existing servers. If
> false, you just want to detect new servers - but it will not detect new
> services under existing (that is, already in inventory) servers.
>
> See the FAQ (mentioned below) for more in discovery intervals
> (server-scan and service-scan intervals).
>
>>   What is the normal discovery process?  Does
>> it run just once when the root resource is discovered?  Would the user
>> have to un-inventory and re-import root resources to see changes?
> See the FAQ titled, "Explain how agent scans for resources" found here:
>
> http://rhq-project.org/display/JOPR2/FAQ#FAQ-Explainhowtheagentscansforresources
>
>> Is
>> there a way for an agent to periodically discover new (child) resources
>> and report them to the server?
> See above.
>
>> Is there any kind of graph for calltime metrics?
> We used to have a lame graph for calltime, but it didn't really show
> much. We now just have tabular views for calltime metrics. The old graph
> views might still exist in the JSP pages, but I don't think we link to
> those anymore and those pages might even be broken. As it stands, we
> have no plans for any calltime metric GRAPHS - just tabular views.
>
> Ian might know more, I'm just going by memory here, but Ian I think
> knows more about the calltime graphs/tables.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>


More information about the rhq-devel mailing list