[jboss-as7-dev] AS7 console, RHQ

[Jason T. Greene]

On 1/11/11 10:21 AM, Heiko W.Rupp wrote:
>
> Am 11.01.2011 um 16:55 schrieb Jason T. Greene:
>> Retrofitting existing plugins for AS functionality is a non-option. They
>> have to be integration with the domain APIs, else we just can't do
>> unified configuration.
>
> I completely understand your point.
> The point I am trying to make is that users / projects have written
> management plugins for RHQ/JON as they are the people that know their stuff.
> Now not using this, but re-doing via domain imposes either a burden on AS
> guys to rei-mplement or on the project to re-implement.

Yes but we can only consider options that meet the requirements. 
Unfortunately this is just the cost of making a paradigm shift.

> The current RHQ model is one where the AS plugin can have other plugins
> as children so that subsystems appear in the tree "in natural position". So
> if a user e.g. installs portal on EAP, he would take the portlet-plugin, drop to
> console and be able to monitor his portal.

Displaying it in the proper "place" is only part of the problem. Getting 
the updates to apply correctly and consistently according to a 
multi-node topology and it's policies is the real challenge. Also the 
console is only one of the interfaces we are supposed to provide the 
user (per requirements). Another is an API and a CLI. All of the 
interfaces are supposed to be completely consistent.
>
>
>>> But is this an actual requirement?
>>
>> I have not seen any requirements on reusing existing RHQ plugins. I am
>> not sure what the JON schedule is, but at some point it will be updated
>> to use the AS7 domain APIs, and I assume that the JON team will likely
>> use an RHQ plugin to do that, since that is their architecture.
>
>
> JON / RHQ would have a plugin that talks to the domain and discover and manage
> stuff via this.
> Nowadays JON has the base AS plugin which does the base stuff and a HornetQ plugin
> which talks to HornetQ via JMX.
> With the full domain management, either the RHQ team writes an AS plugin with the
> knowledge of all (future) subsystems in it or we decompose again. Which means that
> in this example the HornetQ team writes another plugin that goes through domain to obtain
> metrics and does configuration. I do not think the HornetQ guys will be happy to write another
> plugin.

The HQ subsystem in AS7 is mostly complete. They provide an internal API 
that we build an AS subsystem on that adds the details to the domain.

Again, using the JMX plugin is a non-option. When someone changes an HQ 
setting on a server group with 3 servers, it must be applied to all 3 
servers, and it must show up in the configuration file and in the user 
exposed domain API. This is what we have already acheived.

> And the same will apply to customers who have written their specific management stuff
> and which they would need to re-do for AS7.
>
> Having said this, I can imagine some way where the plugins (if they are JMX based) would
> call via JMX plugin, but this one would intercept the calls and do them via domain instead.
>
> But I do not see management plugin code duplication as a good idea. Plugins for subsystems
> should be written by the subsystem owners and not by RHQ/JON nor by Base AS.

It's not really duplication as much as replacement. The whole concept of 
domain management in the AS requires that the AS do the domain 
management. There is just no way around that.

-- 
Jason T. Greene
JBoss, a division of Red Hat