Jkremser, and anyone,

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...

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:

Any Hawkular events generated when MiQ isn't running will likely be missed.
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).
Potentially excessive polling if the number of events is not large.

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.