drift async job purges drift files

John Sanda jsanda at redhat.com
Tue Aug 16 14:32:17 UTC 2011


The point Jay raised is a good one, and I don't think that purging 
content older than some time addresses it. A user may seed the database 
with content with the intent to start drift monitoring against that 
content at some point in the future. If the purge job comes along and 
deletes, things will still work as expected; however, this could happen 
at times other than when a user is just getting started with drift 
monitoring. Consider the following:

* User seeds database with content
* User starts drift monitoring for resources against seeded content
* At some point those resource are uninventoried
* More resources imported into inventory with the intent to perform 
drift monitoring

I can see the above scenario being a likely one in cloud deployments. 
Since there may be situations where the user wants to keep content in 
the database even if it is not being used, I think we need to provide 
the user with the option to mark content as "reserved" for future use.

- John

On 8/16/11 9:50 AM, John Mazzitelli wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=730993
>
> On 08/16/2011 09:44 AM, John Mazzitelli wrote:
>> We can add a system config like the other purge ones - the ones like
>> "purge alerts older than X days" or "purge events older than X days. For
>> example, "purge orphaned (or unused) drift files older than X days".
>>
>> We can add a AND clause in the DELETE SQL:
>>
>> DELETE FROM RHQ_DRIFT_FILE
>>       WHERE (HASH_ID NOT IN (SELECT OLD_DRIFT_FILE FROM RHQ_DRIFT))
>>         AND (HASH_ID NOT IN (SELECT NEW_DRIFT_FILE FROM RHQ_DRIFT))
>>         AND CTIME<   ?
>>
>> where ? is bound to some value in the past (epoch millis) that
>> corresponds to how old a unused drift file is allowed to be without
>> getting purged.
>>
>>
>> On 08/16/2011 09:23 AM, Jay Shaughnessy wrote:
>>> Mazz, one caveat here that we may be able to take care of with a simple
>>> flag or expiration data or something.  We actually may want drift files
>>> that are not (yet) associated with drifts.  This is the whole idea
>>> behind seeding the db with files we expect to be reported from agents.
>>> For example, we know we're going to deploy bundle Foo to 100 machines.
>>> We may very well want to slurp that bundle into the drift backend and
>>> create drift files in advance, so that we never actually need to
>>> download them from an agent.  They'll already be there.
>>>
>>> On 8/13/2011 10:01 AM, John Mazzitelli wrote:
>>>> (this is probably only of interest right now for Jay and John S)
>>>>
>>>> I checked in code that adds to the data purge job that runs hourly. We
>>>> now purge drift files if there are no drifts referencing it. Every hour,
>>>> when you see the data purge job emit its log messages, if you look in
>>>> there, you will see messages about purging drift files.
>>>>
>>>> This means we can clean up and reclaim space for drift files that are no
>>>> longer used (that is, referenced as either an old or new file from any
>>>> drift entry).
>>>>
>>>> This goes through the drift server plugin - if we are using the RHQ DB
>>>> backend, we'll purge unused rows in RHQ_DRIFT_FILE. I left a TODO in the
>>>> MongoDB plugin to do the purging when using MongoDB as the drift backend.
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list