4 a.m.
I was looking at the proposal my alter ego send to this list a couple of weeks ago:
http://www.rhq-project.org/display/RHQ/AS7+console
What I don't understand is, why should there be an interim layer between the AS7
management API's
(configuration, deployment, etc) and the web-UI?
As described, management of the domain model would be another plugin to the RHQ
container,
equivalent to any other plugin, like the JMX and HornetQ plugins.
I was expecting that any subsystem (i.e. hornetq) would be directly interfacing the AS7
management API's (domain model, deployment, etc). What's the purpose of having
another intermediary layer like the plugin container?
I am trying get a better understanding how all the pieces fit together, especially bearing
in mind that we have an
"embedded console" legacy and that AS7 products will be managed by JON,
somewhere upstream in the product chain.
On a first glance I did assume that any subsystem directly interfaces the new API's
that are currently fleshed out. Instead of retrofit existing plugins on the new API. But
maybe that's because I don't see the big picture, especially how this integrates
with JON later on. But is this an actual requirement? I guess it all boils down to the
question what API customers should get to see, when they want to extend the management
capabilities or integrate with it? Will it it be the RHQ plugin API or the new AS7
management API?
Why RHQ in the first place? How does it relate to JON?
An alternative would be: AS7 Management API <-> REST interface <-> Web-UI.
What are the benefits, drawbacks of each approach?
Ike
(formerly know as Heiko Braun, in order to avoid confusion)
9:26 a.m.
On 01/11/2011 04:00 AM, Heiko Braun wrote:
I was looking at the proposal my alter ego send to this list a
couple
of weeks ago: http://www.rhq-project.org/display/RHQ/AS7+console
What I don't understand is, why should there be an interim layer
between the AS7 management API's (configuration, deployment, etc) and
the web-UI?
Yeah. I think it's really kind of crazy to focus on the architecture
without having acquired the basic requirements.
Before we go picking technologies, we need to know:
1. What information should be presented? Be specific - at least, more
specific than "everything".
2. How should the information be organized? In domain mode, maybe
multiple tree views (domain->host->server, domain->servergroup->server)
depending on what information you're after; per server, maybe a basic
tree that's similar to the server model layout?
3. How should the interface flow? For example, perhaps I have a fixed
tree view on the left-hand side that I click on to get at other parts of
the system.
4. Performance requirements? We ought to stipulate that on 2 or 3
specific test platforms, the UI takes no more than, say, a second or two
to fully initialize, and that we take measures to keep assets small so
that page load time doesn't become a significantly detrimental factor.
5. How real-time should the interface be? Are UI views updated
dynamically as they change on the server, for example?
Picking tech before all of these questions are answered is putting the
cart before the horse, to say the least. History has shown that
considering requirements as a second step has led to failure far more
often than not. We need to know what exactly we're trying to accomplish.
--
- DML
2:41 a.m.
I do generally agree with your statements.
But in this case, I was trying to understand the RHQ proposal and their reasoning.
One piece of the puzzle is the RHQ plugin legacy and the JON upstream .
The plugin legacy question basically target re-use, whereas the JON upstream aims at
integration at some later point.
[Plugin re-use]
It would be interesting to know about how many plugins we actually speak about.
The smaller the number, the the more reasonable it becomes to simply rewrite them.
[JON Upstream]
This question is a little more complicated. The AS7 console and JON have an overlap in use
cases.
I can see two strategies at this stage: Either we make sure the AS7 console feeds directly
into JON upstream
(i.e. by re-using the plugin container), which is what H. Rupp suggests I think. Or we
remove the overlap in use cases,
but at the same time make sure both management UI's can be used in conjunction. For
instance by providing means to
combine the UI's in a single console. From what I know so far, the later seems to the
best option to me.
Ike
On Jan 11, 2011, at 4:26 PM, David M. Lloyd wrote:
On 01/11/2011 04:00 AM, Heiko Braun wrote:
> I was looking at the proposal my alter ego send to this list a couple
> of weeks ago: http://www.rhq-project.org/display/RHQ/AS7+console
>
> What I don't understand is, why should there be an interim layer
> between the AS7 management API's (configuration, deployment, etc) and
> the web-UI?
Yeah. I think it's really kind of crazy to focus on the architecture
without having acquired the basic requirements.
Before we go picking technologies, we need to know:
1. What information should be presented? Be specific - at least, more
specific than "everything".
2. How should the information be organized? In domain mode, maybe
multiple tree views (domain->host->server, domain->servergroup->server)
depending on what information you're after; per server, maybe a basic
tree that's similar to the server model layout?
3. How should the interface flow? For example, perhaps I have a fixed
tree view on the left-hand side that I click on to get at other parts of
the system.
4. Performance requirements? We ought to stipulate that on 2 or 3
specific test platforms, the UI takes no more than, say, a second or two
to fully initialize, and that we take measures to keep assets small so
that page load time doesn't become a significantly detrimental factor.
5. How real-time should the interface be? Are UI views updated
dynamically as they change on the server, for example?
Picking tech before all of these questions are answered is putting the
cart before the horse, to say the least. History has shown that
considering requirements as a second step has led to failure far more
often than not. We need to know what exactly we're trying to accomplish.
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:28 a.m.
Am 12.01.2011 um 09:41 schrieb Heiko Braun:
[Plugin re-use]
It would be interesting to know about how many plugins we actually speak about.
The smaller the number, the the more reasonable it becomes to simply rewrite them.
We (= RHQ project have ~50 plugins, where not all apply) and then there are
external ones like HornetQ, Infinispan, SOA-P, Dataservices, ...
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
6:35 a.m.
We would need to know which ones apply to EAP.
When I say apply I mean the ones that actually manage subsystems
that will be deployed on AS7. Excluding those that manage external resources like Apache,
etc.
Would it be possible to get list of plugins with a brief description?
Maybe such a list already exists somewhere?
In order to do a fair judgement, we would need to know how much porting effort
we actually speak about.
A second interesting question address the abstraction between the plugin (or container)
and the managed runtime components. I would expect an adaptor layer that mediates
changes between target runtimes (i.e. AS4, AS5) and the actually plugin container
versions.
If such a layer exists, can it accommodate the changes required to run on the new domain
model,
so that the plugin doesn't need to be changed?
Ike
On Jan 12, 2011, at 1:28 PM, Heiko W.Rupp wrote:
Am 12.01.2011 um 09:41 schrieb Heiko Braun:
> [Plugin re-use]
> It would be interesting to know about how many plugins we actually speak about.
> The smaller the number, the the more reasonable it becomes to simply rewrite them.
We (= RHQ project have ~50 plugins, where not all apply) and then there are
external ones like HornetQ, Infinispan, SOA-P, Dataservices, ...
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:55 a.m.
On 1/11/11 4:00 AM, Heiko Braun wrote:
I was looking at the proposal my alter ego send to this list a couple
of weeks ago: http://www.rhq-project.org/display/RHQ/AS7+console
What I don't understand is, why should there be an interim layer
between the AS7 management API's
As described, management of the domain model would be another plugin
to the RHQ container, equivalent to any other plugin, like the JMX
and HornetQ plugins.
I was expecting that any subsystem (i.e. hornetq) would be directly
interfacing the AS7 management API's (domain model, deployment, etc).
That's correct. The only way to have consistency between configuration
and management is if subsystems are part of AS and thus interface
directly with the AS7 APIs. So all of our subsystems need to be
implemented this way.
What's the purpose of having another intermediary layer like the
plugin container?
It would certainly be redundant. The only advantage I can think of to
doing this is that it allows you to manage things that are outside of AS
(like say a database). However, this would be completely disconnected
from the domain topology views, and not have the same shared
configuration persistence. For this reason an ISV wanting to extend AS
would probably favor a domain extension vs a RHQ plugin.
Lastly, even if RHQ is needed to support external component management
(which isn't a requirement right now), it will likely save time to just
use the AS APIs for talking to AS, and RHQ for talking to whatever is
managed by it.
I am trying get a better understanding how all the pieces fit
together, especially bearing in mind that we have an "embedded
console" legacy and that AS7 products will be managed by JON,
somewhere upstream in the product chain.
On a first glance I did assume that any subsystem directly
interfaces the new API's that are currently fleshed out. Instead of
retrofit existing plugins on the new API. But maybe that's because I
don't see the big picture, especially how this integrates with JON
later on.
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.
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.
However, IMO, in the interest of time (and where we are in our schedule)
we should worry about one UI at a time, and focus on what is best for
the embedded console.
I guess it all boils
down to the question what API customers should get to see, when they
want to extend the management capabilities or integrate with it? Will
it it be the RHQ plugin API or the new AS7 management API?
See above.
Why RHQ in the first place? How does it relate to JON? An
alternative
would be: AS7 Management API<-> REST interface<-> Web-UI. What are
the benefits, drawbacks of each approach?
Yet another alternative, which IMO is probably the best contender is
using the small detyped Java API. That essentially has all of the
benefits of an HTTP interface, but without the need to marshal to and
from plain text JSON/XML (less serialization overhead).
--
Jason T. Greene
JBoss, a division of Red Hat
10:21 a.m.
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.
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.
> 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.
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.
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
10:59 a.m.
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
2:48 a.m.
I think this has been understood by everybody.
The domain model will be the authoritative source and entrypoint for any management
interface.
On Jan 11, 2011, at 5:59 PM, Jason T. Greene wrote:
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.
4:37 a.m.
Am 12.01.2011 um 09:48 schrieb Heiko Braun:
I think this has been understood by everybody.
The domain model will be the authoritative source and entrypoint for any management
interface.
Yes. I totally agree here and this was always my base proposition.
Still the question about reuse of existing plugins is more than a technical
thing. It is about "who is doing the work" and "who likes doing double
work" and so on.
Heiko (pilhuhn)
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
6:19 a.m.
Do you have a list of existing plugins?
Just to add some meat the the discussion.
On Jan 12, 2011, at 11:37 AM, Heiko W.Rupp wrote:
Am 12.01.2011 um 09:48 schrieb Heiko Braun:
>
> I think this has been understood by everybody.
> The domain model will be the authoritative source and entrypoint for any management
> interface.
Yes. I totally agree here and this was always my base proposition.
Still the question about reuse of existing plugins is more than a technical
thing. It is about "who is doing the work" and "who likes doing double
work" and so on.
Heiko (pilhuhn)
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:42 a.m.
On 1/12/11 4:37 AM, Heiko W.Rupp wrote:
Am 12.01.2011 um 09:48 schrieb Heiko Braun:
>
> I think this has been understood by everybody.
> The domain model will be the authoritative source and entrypoint for any management
> interface.
Yes. I totally agree here and this was always my base proposition.
Still the question about reuse of existing plugins is more than a technical
thing. It is about "who is doing the work" and "who likes doing double
work" and so on.
It's not just technical, it's also scope. We have a defined scope and
set of requirements. Anything that falls out of those requirements is a
much lower priority than thing that do. So, since reuse of plugins is
not a requirement, and it does not help us meet our existing
requirements, it's out of scope.
--
Jason T. Greene
JBoss, a division of Red Hat
12:14 p.m.
New subject: Can't build trunk with OpenJDK
This import doesn't allow building trunk with OpenJDK:
org.jboss.as.server.deployment.DeployerChainsService
...
import com.sun.servicetag.ServiceTag
Our build should be JDK neutral so I suppose this is a bug?
/D
[dimitris@localhost jboss-as7]$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.3) (fedora-49.1.9.3.fc14-i386)
OpenJDK Client VM (build 19.0-b09, mixed mode)
[dimitris@localhost jboss-as7]$
12:19 p.m.
New subject: Can't build trunk with OpenJDK
On 01/12/2011 12:14 PM, Dimitris Andreadis wrote:
This import doesn't allow building trunk with OpenJDK:
org.jboss.as.server.deployment.DeployerChainsService
...
import com.sun.servicetag.ServiceTag
Our build should be JDK neutral so I suppose this is a bug?
Yeah definitely.
--
- DML
12:20 p.m.
New subject: Can't build trunk with OpenJDK
On 1/12/11 12:14 PM, Dimitris Andreadis wrote:
This import doesn't allow building trunk with OpenJDK:
org.jboss.as.server.deployment.DeployerChainsService
...
import com.sun.servicetag.ServiceTag
Our build should be JDK neutral so I suppose this is a bug?
Yes, especially since this class is not even used. It looks like an IDE
tab complete gone wrong.
--
Jason T. Greene
JBoss, a division of Red Hat
12:28 p.m.
New subject: Can't build trunk with OpenJDK
My first accidental contribution, I'm trilled :)
On 12/01/2011 20:20, Jason T. Greene wrote:
On 1/12/11 12:14 PM, Dimitris Andreadis wrote:
> This import doesn't allow building trunk with OpenJDK:
>
> org.jboss.as.server.deployment.DeployerChainsService
> ...
> import com.sun.servicetag.ServiceTag
>
> Our build should be JDK neutral so I suppose this is a bug?
Yes, especially since this class is not even used. It looks like an IDE
tab complete gone wrong.
2:44 a.m.
Agreed, but we need to sort out any issue that might prevent
integration with JON at a later stage. At least the implications (amount of work,
preferred architecture)
should be clear.
On Jan 11, 2011, at 4:55 PM, Jason T. Greene wrote:
However, IMO, in the interest of time (and where we are in our
schedule)
we should worry about one UI at a time, and focus on what is best for
the embedded console.
5082
days inactive
5083
days old
16 comments
5 participants
participants (5)
-
David M. Lloyd -
Dimitris Andreadis -
Heiko Braun -
Heiko W.Rupp -
Jason T. Greene