12:09 p.m.
It is a little bit hard to jump into this long threads but interesting.
I am going to describe my thoughts if that can help (or not) into this discussion.
I think before to get into low level details, it is good to discuss perhaps in some high
level motivations as ThomasS commented, and that might help to check in we are everyone in
the same page.
Today (if I am not wrong) we have three/four main scenarios where our efforts are driven:
- A standalone use of Hawkular Metrics (mainly for OpenShift).
- Hawkular, a integrated project of several components/subproject
(bus,accounts,metrics,alerts,inventory,agent,ui,new ones).
- Hawkular BTM (not sure if this will be consumed as part of Hawkular as add-on, or a
variant).
- Hawkular DataMining module (not sure if this will be consumed as part of Hawkular as
add-on, or a variant).
It happens as our components are decoupled and can be consumed separately, so it could be
valid if the same user that is using metrics in standalone can add alerts too to work
together, but probably that user is not interested in the full Hawkular solution as it has
developed its own security, feeds and inventory frameworks (or any combination).
So, for me, a legitimate question could be: "how easy it can be to put two components
working together?".
That I think is what we are discussing here.
So, if a user can deploy a metrics.war and alerts.war in the deployments folder on a
standard wildfly server, that could be interesting an attractive for everyone (or at least
that I think is our main motivation for this discussion).
And it can be worth to study what we need to do this, if we might have some limitation in
terms of scalability
(if any, which is something read but not discussed in deep, several strong statements
about architecture but that needs to be ellaborated).
If at the end, we reach to a conclusion that communication between components needs an
extra effort, I have my conclusion clear: we need to go through Hawkular, not replicating
things, or in other words, focus all efforst in a single solution that can be used in
several scenarios.