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

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(a)redhat.com&gt; >> To: hawkular-dev(a)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(a)redhat.com&gt; >>>> 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. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev