----- Original Message -----
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.
Right, I think its the plugin redeploy case that most needs a consistent api.
Using the drop directory is easy for initial install, but if you are making frequent
plugin updates, especially in a multi-server environment, I expect having an api would get
you much more consistent semantics.
- John
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel