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

Wed Nov 11 04:22:29 EST 2015

Come on Stefan, you knew the answer, as you knew that I know that you 
know... etc the state of features.

I never said Hawkular (currently) offers a single method like the one 
described in the proposal. I said adding such a new method is not a 
justification for creating a new Hawkular components integration. And I 
have yet to see a non fabricated example for this important assumption 
change.

By the way, I suspect it wouldn't be very hard to implement the method 
in the Alerts component so that all the process below is automatically 
setup for you.

Eventually, I have asked for the spirit/answer/motivations of the 
proposal. The answer was "the current implementation will not work". I 
believe it is obvious that it does.

Le 10/11/2015 23:23, Stefan Negrea a écrit :
>
>
> ----- Original Message -----
>> From: "Thomas Segismont" <tsegismo at redhat.com>
>> To: hawkular-dev at lists.jboss.org
>> Sent: Tuesday, November 10, 2015 4:09:15 PM
>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
>>
>> - Start a Hawkular server
>> - Use the REST resources under /hawkular/alerts to create a trigger for
>> 'my_fancy_gauge'
>> - Use the REST resources under /hawkular/alerts to create an external
>> condition (my understanding is that such a condition will always
>> evaluate to true if data is received)
>> - Use the REST resources under /hawkular/alerts to create a webhook action
>> - Use the REST resources under /hawkular/metrics to publish data
>
> I was afraid of that answer. That was neither the spirit nor the intent of the proposal.
>
>>
>>
>> Le 10/11/2015 22:36, Stefan Negrea a écrit :
>>>
>>>
>>> Thomas, I will ask the same thing I asked John earlier. Can you then please
>>> walk through how to implement the feature proposed in the document? I can
>>> see how it can be done in the proposals I put in the document and
>>> discussed so far. But looks like you might have a different alternative.
>>> Do you mind explaining the alternative and walking through the design and
>>> implementation?
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Thomas Segismont" <tsegismo at redhat.com>
>>>> To: hawkular-dev at lists.jboss.org
>>>> Sent: Tuesday, November 10, 2015 3:06:33 PM
>>>> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
>>>>
>>>> Le 10/11/2015 18:09, John Sanda a écrit :
>>>>>> After this long introduction, there are three main reasons the current
>>>>>> solution needs improvements:
>>>>>>>
>>>>>>> 1) Addressability -> the current solution does not work in the
>>>>>>> distributed environment because there is no clear way how to access the
>>>>>>> public API of the services deployed. Let's say the installation spread
>>>>>>> across 5 containers. How can I make a public API call from a Metrics
>>>>>>> instance to an Alerts instance. There is no directory to know where the
>>>>>>> Alerts or Metrics instances are deployed.
>>>>> Addressability is provided by the messaging system. There is no need for
>>>>> a
>>>>> directory. You just to need to communicate with the messaging
>>>>> server/broker. Beyond that there are a lot of features around
>>>>> addressability and routing such as message selectors, message grouping,
>>>>> hierarchical topics, and more.
>>>>
>>>> +1
>>>>
>>>>>
>>>>>>> 2) Load distribution -> there is no clear way on how the load
>>>>>>> distribution works or who is responsible for it.
>>>>> Again, this is largely handled by the messaging system. Multiple
>>>>> consumers
>>>>> take messages from a queue where each message corresponds to work to be
>>>>> done.
>>>>>
>>>>
>>>> Right, load distribution is a feature of the messaging system. As for
>>>> HTTP load balancing, there is hardware and software dedicated to this, I
>>>> would avoid building an HTTP load balancer into the project.
>>>>
>>>>>>> 3) Availability of the existing public API -> There is no reason to
>>>>>>> implement a new API just for the purposes of communicating between the
>>>>>>> components. Given that we strive for this micro-service architecture,
>>>>>>> the one and single public API should be the main method for
>>>>>>> communicating between components for request-reply.
>>>>> I do not think it is a given that we strive for a micro-service
>>>>> architecture. It might make more sense in an OpenShift environment, but I
>>>>> don’t think it necessarily does in general.
>>>>>
>>>>>
>>>>>>> We might need to extend what we have but the public API should be front
>>>>>>> and centre. So if we use JMS or HTTP (or both, or UDP, or any other
>>>>>>> method), the public API interface should be available over all the
>>>>>>> channels. Sure there might be difference on how to make a request in
>>>>>>> JMS
>>>>>>> vs HTTP (one with temporary queues, and the other with direct http
>>>>>>> connections) but the functionality should be identical.
>>>>> I don’t know that I agree with this. Suppose we decide to offer an API
>>>>> for
>>>>> inserting metric data over UDP to support really high throughput
>>>>> situations. Are you suggesting for example that the operations we provide
>>>>> via REST for reading metric data should also be available via the UDP
>>>>> API?
>>>>> And since the motivation for a UDP API is performance/throughput, we
>>>>> might
>>>>> event want to a more compact request format than JSON.
>>>>>
>>>>> Lastly and most importantly, if you want push for an alternative
>>>>> communication mechanism between components in H-Metrics and H-Alerts,
>>>>> then
>>>>> you push for the same across all of Hawkular because it does not make to
>>>>> have to support two different mechanisms.
>>>>
>>>>
>>>> The public API (JSON over HTTP) is how the users must interact with the
>>>> Hawkular platform. It is the unique entry point for the users.
>>>>
>>>>
>>>> It's has been agreed during the project inception to make Hawkular
>>>> components talk to each other via the bus. It is not a trivial change to
>>>> break this assumption: everything the bus provides (see above) will need
>>>> to be re-implemented.
>>>> That is why I am opposed to the change, unless it is proven that it is a
>>>> limitation.
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>