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

[Thomas Segismont]

Le 09/11/2015 18:10, Stefan Negrea a écrit :
> Hello Thomas,
>
> So far there is no concrete proposal, only why things should not be done; which equates to inaction. I am not the most imaginative person on the planet so I might fail on that front, but I think the plan that I proposed had some cohesion and it was forward looking.
>
>
> Here is a good course of action:
> 1) Propose something new; completely new or partially new
> 2) Get the majority of the group (Metrics + Alerts teams) to agree on the path
> 3) Create the plan to accomplish it and lead the group to implement the plan

I understand the goals of your proposal. I'm simply opposed to 
re-writing what already exists, unless it is proven that it is broken.

Given the stress you rightfully put on moving fast, improving the 
existing system seems like a reasonable approach.

Now maybe you didn't know the features are already there, but they are.

>
>
> Thank you,
> Stefan Negrea
>
> ----- Original Message -----
>> From: "Thomas Segismont" <tsegismo at redhat.com>
>> To: hawkular-dev at lists.jboss.org
>> Sent: Monday, November 9, 2015 10:43:26 AM
>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
>>
>> 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.
>> _______________________________________________
>> 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
>