RFC Feature Planning: Deployment Activity History

Tzu-Mainn Chen tzumainn at redhat.com
Tue Apr 3 04:05:48 UTC 2012


Thanks for the comments!  My comments in-line:

----- Original Message -----
> From: "Matt Wagner" <matt.wagner at redhat.com>
> To: "Tzu-Mainn Chen" <tzumainn at redhat.com>
> Cc: aeolus-devel at lists.fedorahosted.org
> Sent: Monday, April 2, 2012 9:49:02 AM
> Subject: Re: RFC Feature Planning: Deployment Activity History
> 
> On Fri, Mar 30, 2012 at 11:59:11AM -0400, Tzu-Mainn Chen wrote:
> > https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Allow_Conductor_to_keep_a_history_of_deployment_activity
> 
> So I wrote the below email and was about to send it, when I realized
> that I'd focused on the technical implementation details without ever
> fully understanding the overall use case. But it's not abundantly
> clear
> to me what that entails. What information, exactly, are we intending
> to
> keep? I wonder if we should look at stashing core information in the
> Events table?
> 

To be honest, I assumed that the scope of the task was simply to create a way to store events, and then worry about (potentially) adding events later.  I'd hope that the implementation certainly wouldn't preclude that possibility, and expandability is definitely something worth keeping in mind.

> 
> > The document talks about two possible approaches to keeping
> > deployment activity; one is to use an archive table, and another
> > is to use a soft_delete flag.  I'd be interested in hearing
> > people's thoughts on both.
> 
> I was going to mention that I'm still fond of acts_as_paranoid, but I
> just saw your mention on the wiki page that Tomas sent a patch adding
> archivist six months ago. I'm all for just using that in this case. I
> think we're likely to need to stitch together associations anyway
> when
> we're dealing with deleted objects.
> 
> Though, FWIW, using soft delete wouldn't necessarily require any
> major
> changes. acts_as_paranoid would override the finder methods of AR to
> add
> a "WHERE deleted_at IS NULL" to all queries unless you ran
> "find_with_deleted". If we did this ourselves, we could probably just
> use a default scope and a with_deleted method to override it.
> 

I personally prefer the soft delete approach, because my experience with playing with associations is not good; it's possible a bad association took my lunch money in grade school.

> > Oh, and the document also talks about potentially using dbomatic
> > for periodic history purges.  I know there's been some discussion
> > around dbomatic, so if someone had an opinion about that as well.
> > . .
> >
> 
> I think I talked to you on IRC about this and didn't note this
> objection, so I apologize for suddenly raising it. ;) But it occurs
> to
> me now that cleaning up old history is something that we want to do
> perhaps once a month, not every couple of minutes, so maybe we should
> just use cron. What if we added a rake task / little script that did
> this, using a configurable time period? Then we could ship with a
> reasonable default (do a monthly cleanup of entries older than 6
> months?), but allow administrators to change it by just editing
> crontab.
> (I'm also not entirely convinced that deleting archived entries by
> default is a good thing... Some users might want to preserve history
> indefinitely. This way they could at least disable it easily.)

There's a separate task (specified in the document) that specifies that the administrator should be able to configure history purges.  I should add details to that section to specify what I think that means.  In any case, I disagree that cleaning up old history is a once-a-month task, but the point about cron still stands.  What I *do* want to avoid is the sense that Conductor is using multiple schedulers for multiple tasks when one scheduler could do; I don't think that's a pleasant user experience.  Ideally, though, the action and the scheduler should be reasonably discrete.  I'll make a note of the issue in the documentation.

> 
> One additional note -- the last sentence of your "Summary" section
> includes this interesting tidbit: "Finally, historical event data
> will
> need to be searched efficiently. In order to do so, we will evaluate
> Katello's search implementation and see if it is suitable."
> 
> That sounds like a really good idea, although I suspect it'll be a
> good
> bit of work, enough that I wonder if it should be its own feature. I
> think we'd need to work with Katello to make sure it was
> appropriately
> configured for multi-tenancy, and make sure that Katello and Aeolus
> both
> included a dependency on it, plus make sure that we had consistent
> configuration so that if one project set it up the other project
> could
> use it without problems. It's definitely achievable and likely
> worthwhile; I just think it deserves scoping as a bigger task.
> (IMHO.)
> 
> -- Matt
> 



More information about the aeolus-devel mailing list