[Hawkular-dev] Event Store

Gary Brown gbrown at redhat.com
Sat May 9 12:33:26 EDT 2015


Hi Lucas

I think we probably need to revisit the use cases for the event store - possibly Thomas can outline his use case again and we start from there.

Unfortunately I wasn't in the architecture session, as I wanted to hear about the testing strategy, but sounds like treating each component standalone with the ability to publish relevant information of interest to other components via the bus (in certain configurations) is a good way to go.

Regards
Gary


----- Original Message -----
> Hi,
> 
> > 
> > Hi Lucas
> > 
> > ----- Original Message -----
> > > > Although it could be provided as a separate component, I am not sure we
> > > > have
> > > > any use cases where it would be used independent of the bus, so think
> > > > it
> > > > is
> > > > probably best to include it as additional functionality within the Bus
> > > > component.
> > > > 
> > > > Agree/disagree?
> > > > 
> > > 
> > > In terms of archicture I would suggest to follow a similar architecture
> > > discussed for metrics/alerts/inventory.
> > > 
> > > A main component with this persistence/Java API dependencies and then to
> > > a
> > > Listener/CDI/TBD (glue) project that integrate the component with the
> > > Bus,
> > > so then if needed, component could work without Bus dependencies.
> > > Perhaps we don't have an isolated use case without kettle/bus but I think
> > > that in that way we can unify the picture.
> > > 
> > 
> > That sounds reasonable - although it is slightly different to how the
> > events/alerts discussion went (I believe) where I think the suggestion was
> > that events were persisted off the bus, including Alerts being published
> > and
> > stored, rather than locally storing - possibly my misunderstanding.
> > 
> > However on reflection that would make the components more dependent upon
> > the
> > bus, so probably better to have a shared 'persistence' component, as you
> > suggest, which could be used by all of the other components to persist
> > information directly, and then use the bus to publish the data for further
> > processing.
> > 
> > In terms of Elasticsearch - this 'persistence' component could initially
> > simply wrap Cassandra and then as we understand the query requirements, add
> > (possibly optional) support for Elasticsearch to do the advanced queries.
> > 
> > Only component I am not sure about how it may use this shared 'persistence'
> > component is Inventory, as it uses Cassandra via Titan?
> > 
> 
> my points are two discuss perhaps in two layers:
> 
> - the business aspect, to map better what an Event needs to be (what not) to
> identify the business implications in terms of lifecycle, where/when is
> generated, how interacts with alerts/metrics/possible inventory as well. It
> was an interesting meeting, as I think that the Event can be also mapped
> with log entries/audit/other messages, etc. But on this layer I would like
> to get the busines concept.
> 
> - In the architecture aspect, I guess you are right, perhaps I didn't detail
> better my previous email, for example, in alerts, the architecture is to
> have a main engine that have a dependency with the cassandra cluster that
> can be shared (or not, this could be a future discussion) with metrics or
> other components, but the engine itself it has not a direct dependency with
> the bus, we add the bus dependency in an additional project, so we can have
> both alternatives: a use case where we can use the component in a standalone
> way or with the bus scenario, so it's a configuration/packaging option. My
> suggestion is that would be also interesting for EventsStore. Also, perhaps
> the ElasticSearch service can be shared as well for other components in the
> future.
> 
> Regards,
> Lucas
> 
> 
> > Regards
> > Gary
> > _______________________________________________
> > 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
> 


More information about the hawkular-dev mailing list