[Hawkular-dev] Hawkular integration

[Thomas Heute]

On 05/20/2015 10:50 AM, Gary Brown wrote:
>
>
> ----- Original Message -----
>>
>>
>> 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"
>>
>
> One issue may be patching the product - if each component has its own deployment (with glue added using overlay), then if a component needs to be patched, it is just a case of replacing that one module.

I don't think it makes a difference, we would want to touch the smallest 
possible part because one-off patches may collide.

>
>
>>
>>> 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.
>
> I don't see this as a burden, I think it makes the boundaries between components much cleaner - each component with its integration points can be tested locally before being assembled/configured within hawkular.

I think it actually ties more the components together and would require 
more frequent releases of the components.
>
>>
>> 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).
>
> I believe the correct separation of tests should be:
>
> Component - unit and component related integration tests - to minimise unnecessary dependencies being introduced and therefore impacting the component tests.
>
> Hawkular - end to end integration and UI tests.
>
>>
>> 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.
>>
>
> We also need to consider component reuse. If all of the integration glue code is in hawkular, then any other projects that want to reuse just one component has to depend on artifacts from two repos. If all of the glue code was also in component, then (as with hawkular) the other components simply assemble the required components and configure as required.

Which components and reuse where ?
I think a library can be reused, or Hawkular metrics can be reused as 
standalone project. I hardly think that a component depending on the bus 
would be reused by anyone.

Thomas

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