[Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0

[Thomas Segismont]

Le 09/11/2015 16:48, Stefan Negrea a écrit :
> Hello,
>
> That document uses what is already implemented as a base. Phase 0 (a prototype phase) should take the current implementation to the next level. All the things in the document where logical increments to what we have today. The goal was to have a quick Phase 0 to build something that we can get feedback on.

The use case detailed in the example is already possible with a Hawkular 
server.

I don't understand what taking the "current implementation to the next 
level" means.

>
> As for the requirements, there are no requirement and there will probably be very little requirements. There is no external entity to give us some requirements at this stage. If you consider that what is proposed in the document is wrong, I open to suggestions. However, I caution against inaction or slow action.
>

The use case detailed in the document is fine. But there's no need to 
prototype an integration if it already exists.

> Whatever we do should follow two basic principles:
> 1) Fast phase, 2-3 weeks of development
> 2) Build something simple that enables more complicated features in the future
>

I have yet to see a feature which requires to rebuild a new integration 
mechanism.

>
> More replies inline below ....
>
>
> Thank you,
> Stefan
>
>
> ----- Original Message -----
>> From: "Thomas Segismont" <tsegismo at redhat.com>
>> To: hawkular-dev at lists.jboss.org
>> Sent: Monday, November 9, 2015 9:16:48 AM
>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
>>
>> Hi,
>>
>> Phase 0 is already implemented:
>> - Metrics can receive data over HTTP
>> - Metrics can publish inserted data to the bus
>> - Webhooks can be created/configured via the Alerts API
>> - Alerts is able to consume data from the bus
>
> That is not what the document states as goals for Phase 0. As the document is written what you described is a prerequisite for Phase 0.

 From Google docs:
"This document has two parts. First are the details about how to 
exchange data between the two services. And then, there is a description 
of a simple feature that can showcase the integration."

1. Data exchange between the two services is already implemented.
2. The user facing feature is already possible with a Hawkular server.

So phase 0 is over. Period.

>
>>
>> I can't see why we need to expose an endpoint in Metrics API to setup a
>> set of conditions in Alerts. The Alerts API does the job.
>
> Disconnected APIs are not an integrated solutions. Just as an example, the are issues with the maturity of the APIs on both ends. Until we go through the exercise of trying to integrate the two in a user facing feature we will not see the differences or be able to provide something meaningful to users.

What does disconnected mean? That they are not implemented by the same 
software component? In this case it's not a problem.

The webhook API won't be more mature because it's re-written from Alerts 
into Metrics. Maybe I missed your point.

Integration of Alerts and Metrics has been demonstrated and used this 
very afternoon at Devoxx by Clément in the vertx workshop. I'd bet no 
attendee (other than Juca) did notice there was 2 software components 
behind the service.

Truth is the scenario described in the document lacks an integration 
test. I believe this could be added to:
https://github.com/hawkular/hawkular/tree/master/modules/end-to-end-test

>
>>
>> Do you already know the use cases for Phase 1?
>
> There are no requirements, and probably there will be no requirements in the next month (or even more). That is not the way to approach this.

 From my POV, the way to approach this is to write documentation and 
tests for all the awesome features which already work but people 
(including in our community) aren't aware of.