* 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.
Thoughts?
Perry