[Hawkular-dev] Should the components depend on the bus ?

[Lucas Ponce]

> When we started the hawkular efforts, I had in mind that the components
> would do minimum tasks as a library with REST/Java APIs and do them well.
> 
> Inventory would manage resources (user defined (an "application", a
> cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
> assign ids...
> Metrics would store/aggregate/compact metrics (like it is today)
> Alerts would define some alert definition "model" and run an engine to
> define when to trigger an alert.
> ...
> 
> Hawkular project would then be a firm/comprehensive solution that are
> using all those components, would proxy the APIs, add security there
> (instead of in each component),...
> 
> But now I start to see that client aspect of the communication bus is
> part of those components I think I understand the motivation for that
> but not sure that this is what we really need. Am I the only one
> thinking that the communication aspect should be left out of the
> components ?
>

I think there is info that will be shared between components, so it's needed to define a shared/common model between components.

For example, alerts component should "listen" from some point data/events to evaluate when to trigger an alert.

In the first prototypes we are supposing that it will be a "MetricsTopic" in the bus where alerts component can subscribe for this data.

This is a minimalist scenario.

But, also, yesterday we were discussing with Jay that we can have more complex scenarios, where an alert definition can compare two periods of time (for example, if this week was better than before), in this last scenario we can have requeriments to ask for aggregate data, and transform it in some model that alerts can use to evaluate alerts conditions.

In this last scenario, it seems that an alert definition could ask for data to metrics subsystem.

So, it would be nice if we can progress in the shared data between components to define what it could be best design to implement these scenarios.

I would start with common data (for example, queues/topic identified, data format shared, etc).


 
> For instance in http://docs.hawkularinventory.apiary.io/ for the
> DumbFeed, I don't think it's the role of the Metrics to send
> notification to the bus, if we need more than collecting metrics then it
> is a job for Hawkular IMO (who may proxy the metrics request and send
> notification to the bus).
> 
> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>