On Wed, Aug 17, 2011 at 03:46:54PM -0400, Jason Guiditta wrote:
Again, all these things are surfaced as QMF events currently, _but they
are captured nowhere_. So the question is, where does it make sense to
store these things? I only see 2 main options here, and which we choose
directly impacts many other aspects of this integration:
1. Store all this metadata in iwhd. Iwhd is the canonical home for
information about images, so depending how you view this, all the
above metrics are information about an object iwhd owns. If you follow
this line of reasoning, it may make sense for iwhd to store status,
percent complete, and error metadata.
I think this makes sense to me, and we're already using iwhd for other
stuff, obviously.
2. Store these things in Conductor. In this way of thinking,
Conductor
is trying to provide additional useful information to the user on
concepts iwhd does not know or care about, therefore it makes no sense
to have this data in iwhd.
I don't necessarily feel strongly about this, but the more I think about
this, the more I think that this isn't the right way to go -- otherwise
we end up storing information about images both in Warehouse and in
Conductor's local database.
=== Part 2: Conductor <-> Factory Communication ===
In order to build/push from Conductor, we have to bring back in the
dependency of Conductor communicating with factory in some way. In the
past, we have tried several approaches to this:
* Embed a console directly in the webapp. This did not work well due to
ruby threading issues and process blocking. Also, if the console
encounters some kind of error, you need to restart the entire webapp to
recover from it.
I don't think I was around when this was in place, so perhaps I'm
missing part of the picture, but this approach appears to have no
redeeming qualities.
* Separate Process (this used the delayed_job gem). This basically
had
a 'job' inserted into a tasks table, and the worker process would poll
that table for new entries. Whenever a new one was found, it would do
whatever was defined in the job object's execute/run type method. This
is a similar approach to what we used to do with taskomatic/condor, but
in a more generic way. As I write this, I am trying to remember if this
just fired off a request to connector (in next bullet), and let that
handle events, or something else - I cannot recall for sure which it
was.
* Separate app. This was the aeolus-connector, or HTTP/QMF Bridge, as
it has more recently been called. It interacted with conductor via the
conductor's REST api (albeit simple bits) and had a console inside to
talk to factory. While this would require a restart if console died, it
could be done independently of the web app, minimizing impact.
It seems like, ideally, we'd just toss a job over to Factory, and let it
fire updates at us / fire a "completed" event, rather than requiring us
to use something like delayed_job to process. I think that argues for
the "separate app" approach, at least assuming I understand the separate
process / separate app difference correctly.
* Is qmf actually buying us anything when talking to factory?
It seems to me like it makes our lives harder on the Conductor side, but
I suspect it's advantageous on the Factory side to just speak QMF
instead of having to know how to call out to Conductor to pass updates.
For
pacemaker-cloud, we decided it would be simpler for all involved to just
have an HTTP interface on each side. Perhaps this would be worth
considering in this case as well? This may at least partly be
determined by weighing the amount of work for either approach, as well
as what actually makes the most sense from a design standpoint.
Yes, this is where I get hung up. I'm not sure QMF is the best choice in
this case, but I'm also not sure that we'd do anything but make
ourselves even more miserable if we tried to redo the whole thing with
some sort of RESTful interface.
Apologies for such a long email, but I fear even with all that I
have
tried to cover here, there is much more that this may bring up. I am
somewhat afraid what this thread will evolve into :)
Quick recap of the main questions (I think I) am trying to ask:
* Where should we store information on builds?
* How should Factory and Conductor communicate this information?
I'm not sure if my answers above actually paint a working system or not.
If we're storing this data in Warehouse, does it make sense for Factory
to just update it directly? (I suppose this is, on some level, shoveling
the work off to someone else, but it seems less roundabout than us
having a process to sit between Factory and Warehouse when the two have
to interact anyway.)
-- Matt