On 07/29/2011 12:24 PM, Perry Myers wrote:
> * This console would have to either write its updates directly to
the db
> (which we have been trying to avoid, multiple writers, everything should
> go through conductor api), or call the conductor api, in which case we
> are doing almost everything the previous suggestion would do.
This point has always confused me... Multiple writers to a db is a
perfectly normal/logical thing as long as each writer has it's own
segmented space to write. If it's that big of a concern, then why not
create a separate database on the same DB server (if you're not
comfortable with table segmentation)?
For example, status updates for vms/services coming from Matahari could
go to a table that Conductor ONLY reads from, while Pacemaker Cloud has
read/write access. This eliminates all of the hoop jumping that I'm
seeing in the above two hacky workarounds for using a database properly
Also, if the intent is that the conductor api is the only interface that
is acceptable, then why not just provide REST api calls that Pacemaker
Cloud can use directly? Yes, it's a bit of glue code for the Pacemaker
Cloud guys to write, but it seems a LOT simpler than the generic
HTTP/QMF bridge, which IMO smacks of over-engineering.
Jason,
I read both of your proposals.
I prefer Perry's suggestion of a standard conductor API if direct QMF
integration is not possible. This allows each application to write
their own glue code for conductor and maintain it directly. It appears
direct QMF integration in conductor is blocked on the threading/non
event driven nature of QMF as stated in your last email.
One question I have with this model is the HTTP transmission model.
Sending events to this conductor API is easy - just write the http data.
Retrieving new events (specifically deployable start + xml data) is
where I see problems - we don't want to poll in our app for new
deployable information. Pacemaker cloud devs prefer event driven
architectures rather then polling.
Is that possible with a http interface?
Regards
-stevve
Thoughts?
Perry
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel