3:33 a.m.
On 05/20/2015 10:04 AM, Lucas Ponce wrote:
Hello,
We were discussing in the F2F (and I guess it is still an on-going topic) about the
components integration in hawkular.
I want to start using accounts with the REST endpoints in alerts and I would like to know
where all the components are going to live.
If I am not wrong, I remember two approaches:
- A big hawkular.ear (with all components inside).
- A modules approach.
I think the main difference is:
a - 1 server that scale by adding more servers (same server) in a cluster
b - "microservices" kind-of architecture were if you need more metrics
"power" you start new metrics nodes, if you need more alert "power"
While b offers most flexibility, I think this is overkill as it adds a
lot of complexity to setup. It doesn't match with our target audience.
So I am definitely advocating for "a"
So, at some point we need to design integration tests to validate
that components work well with accounts and I guess we need to decide how to do that.
At the moment, I see that components (metrics, alerts) have integration tests, I
don't have the details for metrics, but for alerts what it uses the old nest
distribution to put an embedded cassandra + alerts components to run the REST endpoints.
This is useful as JUnit tests are not enough to validate the full scenarios.
Now I think we need to agree which strategy we need to follow.
Thomas Heute and others commented (if I am wrong, please correct me) that is good to have
glue code and integration tests inside hawkular, so hawkular project has responsability to
put pieces together and validate it is correct.
Correct.
I want the components (as in github repo) to do few things and do them
well, they are supposed to mature relatively quickly and put in
"maintenance", while all the actual features of the product belong to
Hawkular.
If we don't do that, then the "componentization" is just a burden IMO.
IMO the unit tests belong to the components, the integration tests
belong to Hawkular and Selenium/higher level tests belong to some
external project. (I forgot if it was explicitly defined by Heiko at the
f2f).
With or without a bus, it's Hawkular responsibility to "send" metrics to
Hawkular metrics when something needs to be stored, "send" metrics to
Hawkular alerts when something needs to be evaluated...
I questioned a while ago if the REST APIs should really belong to the
component or if they should just be "a set of jars", we definitely need
a REST API for Hawkular (at least for the UI).
Integration tests in the component don't give a lot of warranty for
Hawkular itself.
Note: Hawkular Metrics is a bit particular, it has his own delivery as
well as being part of Hawkular.
Gary Brown and others commented (please, if it is not correct, feel
free to correct me) that glue code should live in the component repo, as it has more sense
to put our modifications there instead to propagate the change across several repo.
I like the option b) that the glue code lives in the component, but I see the benefits of
a).
is there a possibility between something in the middle ? A tradeoff between both
approaches ?
So I guess we need to find an agreement, if we need to move code it should be done
quickly and also we need to test things.
I don't see how to proper integrate accounts without this topic more clear.
(I don't remember there is a final decision in the mailing list, please, point me to
that if I missed it).
Thanks for bringing this up, I wanted to :)
Thomas
Thanks a lot,
Lucas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev