rhq plugin tool chain

John Sanda jsanda at redhat.com
Mon Feb 14 17:35:35 UTC 2011


On 2/14/11 10:46 AM, Charles Crouch wrote:
>
> ----- Original Message -----
>> Am 14.02.2011 um 14:33 schrieb Charles Crouch:
>>
>>> 1) Start off with a .txt file containing mbean names and attribute
>>> values to be monitored
>> There are two starting points imo:
>>
>> 1a) existing "binary" MBean that should be monitored
>> 1b) new MBean to be written
>>
>>
>>> 2) Generate an rhq-plugin.xml from the .txt file in 1). This would
>>> extend the jmx plugin, and for basic monitoring require no java code
>>> in the plugin
>> 2a) the .txt file could be partially created by connecting to the
>> MBean server and reading the attributes and operations of the MBean.
>> here the user needs to take the .txt file, and augment it with
>> semantics
>> 2b) use annotations from modules/helpers/pluginAnnotations and put
>> them on the source so that the semantics are there. Then
>> use a doclet in conjunction with the pluginGen to create a full plugin
>> descriptor like Galder has done.
>>
> Good suggestions. There are lots of options for how to generate the plugin descriptor.
> Have you got a link to Galders work?
>
>>> 3) Package the rhq-plugin.xml from 2) into a plugin .jar file
>>> 4) Deploy the plugin .jar from 3) into an RHQ server
>>> 5) Tell the agents to go refresh their plugins
>>> 6) Agents should now be collecting all the metrics mentioned in 1)
>>>
>>> In terms of automation I think all steps besides 4) should be
>>> feasible right now? Regarding 4) I'm not seeing this in the remote
>>> api. Any major reason it couldn't be added?
>>>
>> 4 can just be a (s)cp command to the plugin dropbox on the server.
>>
> I think thats a good work around for now, however this approach doesn't have the best semantics, e.g. not synchronous, ugly edge cases, in a multi server environment, jsanda can comment on specifics. So ultimately I think having an api, similarly to the bundle file creation apis that take a stream or a url would be optimal.
>
>
Not sure  I completely understand the discussion, but there shouldn't be 
any problems with copying copying the plugin jar file to the plugin drop 
box in a multi-server environment. Let's say we have to servers A and B. 
Regardless of which server's plugin dropbox the plugin is copied to, the 
agent plugin scanner running on the server will detect the new plugin 
and add it to the database so that it can be handled by either server. 
When agents download plugins, they are always getting from the db. The 
possible problems I learned about in a multi-server environment involved 
my work with plugin deletion. We cannot delete the plugin row in the 
RHQ_PLUGINS table. If we did this on server A, it would know that the 
plugin has been deleted, but the agent plugin scanner on server B 
wouldn't know that. It would find the deleted plugin on its file system, 
not in the database, and would then proceed to reinstall it.

I think the real issue is the lack of an api. There needs to be a 
mechanism to verify that the plugin has been updated on the server and I 
am not sure if we currently expose an api for that.

- John


More information about the rhq-devel mailing list