On 06/23/11 - 11:44:52AM, Mo Morsi wrote:
---
recipes/aeolus/files/condor_config.local | 5 -----
recipes/aeolus/manifests/conductor.pp | 4 ----
spec/spec_helper.rb | 2 +-
3 files changed, 1 insertions(+), 10 deletions(-)
I thought about this a bit more this weekend, and we may want to re-think our
strategy here. Instead of removing dbomatic, I'm actually going to propose
a sort of hybrid solution.
We know that we are going to need audit logs from jobs in the future. That is,
when condor notices that a job state has changed (due to some external
influence, for instance), we want it to inform the conductor about it so that
the conductor can eventually show it to the user. In order to do this sort
of auditing, we are going to need something dbomatic-like.
The biggest problem I see with dbomatic as it stands is that it writes to the
database tables that the conductor is also reading/writing from. I think we
want to get away from that. However, I'm also thinking that if we can get the
data from condor into the conductor database, it will be much easier for us
to solve the solr update-before-searching problem.
Therefore, I propose that we keep dbomatic, but add a separate database table
for audit logs. Then every time dbomatic sees a new event, it will write it
to the audit table *only*. From conductor's point-of-view, the audit table is
read-only. When we go to do a search on something like instance state, we can
put a "pre-search" hook in so that we update the instance state from the audit
table into the normal conductor instance table, and then do the search.
What do people think about this solution? It is a little more complicated,
but I think it will solve most of the problems that we are trying to solve by
getting rid of dbomatic.
--
Chris Lalancette