<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font face="Calibri">Jkremser, and anyone,<br>
<br>
So I've now got some code working that can move Hawkular events
(events stored via H Alerts) into MiQ as MiQ Events. As a note,
not every Hawkular event will be a MiQ event because MiQ requires
that supported event types are predefined. This mail is more
about the mechanism used to move the events...<br>
<br>
I've started with a primitive mechanism, it's a looping REST Get
with an advancing time window, using the H Alerts rest api via the
hawkular-ruby-client. This has a variety of potential issues,
for example:<br>
</font>
<ul>
<li><font face="Calibri">Any Hawkular events generated when MiQ
isn't running will likely be missed.</font></li>
<li><font face="Calibri">If the timestamps reported on the events
are behind the MiQ polling window they will be missed. (late
arrival, possibly a hawkular server time a bit behind MiQ
server time).<br>
</font></li>
<li><font face="Calibri">Potentially excessive polling if the
number of events is not large.</font></li>
</ul>
<p><font face="Calibri">Certainly some of these issues could be
softened with a little more provider-side smarts, like querying
more into the past and protecting against duplicate event
storage, etc. But I'm wondering what thoughts people may have
on a better mechanism. I know other providers in MiQ use a
variety of techniques to import data, from polling, to blocking
HTTP requests, to queue listeners. I should mention that the
general approach of an MiQ provider is to provide an "Event
Catcher", which runs in a handler process for each provider
instance. The catcher is basically told by MiQ to go get events
and then queues them for MiQ consumption. Let me know what you
think. Also, if anyone would like to see a short demo of what I
have right now I'd be happy to run a short meeting.</font><br>
</p>
</body>
</html>