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

[Stefan Negrea]

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
>