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

On Nov 10, 2015, at 4:36 PM, Stefan Negrea <snegrea(a)redhat.com&gt; wrote: 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(a)redhat.com&gt; > To: hawkular-dev(a)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(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