6:04 p.m.
[sending this to the open source project community mailing lists for RHQ and Wildfly]
This is to kick off a discussion regarding embedding a RHQ agent [3] into an WildFly
instance (which will also be applicable to downstream projects JON and EAP respectively -
but I'll continue to use RHQ and WildFly since the code will almost certainly go in
those upstream projects).
The thought is to embed a RHQ Agent in a running WildFly instance, specifically a Host
Controller. In the standalone RHQ use-case, a single RHQ Agent process runs on a box and
manages all the things on that box. Since there is one Host Controller on a box, it seems
to make sense to embed a RHQ Agent there. This is something we can discuss (do we embed in
Process Controller instead? The initial thought was no, probably not a good idea).
This would allow a person to "flip a switch" to enable RHQ management of their
WildFly infrastructure running on that box without having to separately install a RHQ
agent on their own.
Now, by following the "Extending WildFly 8" example subsystem [1] I already have
an initial implementation of an embedded agent extension subsystem [2] and it is able to
run in a standalone WildFly 6 instance. It will be turned off by default, so its footprint
is minimal by default (just a few extension classes need to be loaded - like the
definitions, the add/remove step handlers, etc). But when you do have it enabled, a
fullblown RHQ Agent will be started in the WildFly instance. Today, I have this working -
it loads all the necessary plugin jars and native libraries to manage platform services
and WildFly resources. The RHQ team might even consider this as its own embedded agent for
use within the RHQ Server itself (since a RHQ Server is itself running in a standalone
WildFly 6 instance, this thus allows a RHQ Server to manage itself with its own embedded
RHQ Agent).
It was my mistaken impression (which Brian mentioned to me recently) that Host Controllers
have extensible subsystems like standalone instances do. I looked in domain.xml, saw
<extension> and <subsystem> tags and just assumed it worked like standalone,
but alas, it does not. So, one question would be - how easy would it be to have extension
subsystems installed and run in a Host controller like we do in standalone instances?
Otherwise, what has to be done to implement a new subsystem in a Host controller, if it is
not done like the "Extending WildFly 8" example.
Another question (probably the first question) to answer is - do we even need to embed an
agent like this? Or, is simply packaging a RHQ Agent with WildFly Host Controllers all
that is needed for a better user-experience than what people have today (which is to
separately install RHQ agents after they install WildFly and domain/host controllers?) Can
an embedded agent provide better functionality than a separate process/instance of the RHQ
agent (even if it is distributed within an WildFly distro?).
There are other issues, obviously, to consider:
* If a Host Controller gets shutdown, that means the RHQ Agent goes down with it (and thus
manageability of that box goes away).
* Do we allow the RHQ Agent running in a Host Controller to manage EVERYTHING on this box
(like a standalone agent would) or do we just want that agent to manage only the WildFly
on that box?
** If its the latter (manage only WildFly), how do we want to be able to manage everything
else on that box (or do we even want to do that?).
* What about testing requirements (what kind of tests are required to get an embedded
agent into the WildFly buld?)
* How do we do packaging of an embedded agent?
* etc. etc. etc. yadda. yadda. yadda.
OK, so that's the kickoff email. I'll let others take it from here and move this
conversation in the directions that people want it to go.
--John Mazz
[1] https://docs.jboss.org/author/display/WFLY8/Example+subsystem
[2] source can be found here:
https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/ser...
[3] see http://www.jboss.org/rhq