10:43 a.m.
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(a)redhat.com>
> To: hawkular-dev(a)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.