rhq plugin tool chain

Charles Crouch ccrouch at redhat.com
Tue Feb 15 13:25:50 UTC 2011



----- 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 at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list