[Hawkular-dev] Hawkular integration

Thomas Heute theute at redhat.com
Wed May 20 04:33:52 EDT 2015



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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>


More information about the hawkular-dev mailing list