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

[Stefan Negrea]

----- Original Message -----
> From: "Thomas Segismont" <tsegismo at redhat.com>
> To: hawkular-dev at lists.jboss.org
> Sent: Monday, November 9, 2015 11:48:05 AM
> Subject: 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.

I never said something is broken. The document is meant to be an iteration over what we have today. More precisely, contains two proposals for moving forward with an unified communication channel. And also there is a proposal for a new feature. I asked for feedback on those two communication methods to adopt one; with the goal to support the newly proposed feature.

The current implementation is not broken for the current use cases (the integration in Hawkular). But that is not the point, and neither did I claim that is broken. It's not about fixing something that is broken but about creating something new. Just one example, a distributed environment with multiple Metrics and Alerts deployments will just not work with what is there today. And that was discussed thoroughly prior to making the document public. 

Thomas, you are yet to propose an alternative Phase 1 (or 0); or even changes to the current document.

> 
> 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.

I know that you know that I know about the current state of the features. To reiterate, I am looking for a positive path forward. 

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