| Summary: | aeolus-cleanup doesn't clean up /var/tmp and /var/lib/iwhd/* | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | Martin Kočí <mkoci> |
| Component: | aeolus-configure | Assignee: | Richard Su <rwsu> |
| Status: | CLOSED ERRATA | QA Contact: | Giulio Fidente <gfidente> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0.0 | CC: | akarol, asettle, cpelland, deltacloud-maint, dmacpher, gfidente, juwu, mfojtik, morazi, mzatko, ssachdev, sseago, zaitcev |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | aeolus-configure-2.8.7-1.el6cf | Doc Type: | Bug Fix |
| Doc Text: |
Running aeolus-cleanup did not clean up /var/tmp and /var/lib/iwhd/* properly. This bug fix updates Conductor to remove imagefactory-mock and deltacloud-mock* from /var/tmp when running aeolus-cleanup and ensures /var/lib/iwhd/* only contains empty sub-directories.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-12-04 14:57:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Martin Kočí
2012-03-05 16:53:59 UTC
Hmm. It's not supposed to remove /var/lib/iwhd/* though -- the directories should remain there. So the regular files under /var/lib/iwhd should be removed, but the top level dirs (i.e. /var/lib/iwhd/images, etc) should not be deleted -- otherwise object creation in iwhd starts failing. (In reply to comment #1) > Hmm. It's not supposed to remove /var/lib/iwhd/* though -- the directories > should remain there. So the regular files under /var/lib/iwhd should be > removed, but the top level dirs (i.e. /var/lib/iwhd/images, etc) should not be > deleted -- otherwise object creation in iwhd starts failing. OK, in any case the regular files under /var/lib/iwhd are not removed in this version. In previous version directories /var/lib/iwhd/* were removed though. Moreover if you do fresh install of aeolus-all then directory /var/lib/iwhd is empty so I assume that these dirs (/var/lib/iwhd/images) will be created when needed. I do not know what the aeolus-cleanup script is supposed to accomplish, but I advise against going around iwhd's back and into the store with just one practical exception: blowing everything away. The biggest issue is the consistency. If you 1. remove Mongo DB, 2. remove /var/lib/iwhd/*, then you reset everything to post-install state and there is no problem with consistency. Otherwise, something will break eventually and I cannot help it. I believe based on a late night debug session with Richard Su and Pete that the present behavior is correct (and aeolus-cleanup only cleans up via the iwhd rest api to boot). In addition to Pete's confirmation above, I'd like to get Richard to confirm present behavior and mark this as NOT_A_BUG. Bonus points if we are able to dig up the original BZ that caused us to stop removing those directories. My 2 cents: This can lead to filling up the filesystem. Like the database, these directories should be purged of the data as it is ultimately orphaned with a purge of the database. I assume aeolus-cleanup purifies the db. Currently, aeolus-cleanup removes the objects in iwhd and mongodb except buckets. There isn't a mechanism to remove the buckets at the moment. Because each bucket corresponds to a subdirectory under /var/lib/iwhd, purging /var/lib/iwhd will cause iwhd to get into an inconsistent state. This was causing another bug: https://bugzilla.redhat.com/show_bug.cgi?id=788397 And this is the reason we disabled purging of /var/lib/iwhd. For after 1.0, we'd like to have iwhd creates its own database in mongodb. This will allow us to drop the database and to purge /var/lib/iwhd without repercussions. Martin Taylor has also found a way to remove the buckets from mongodb through the mongo utility. That's also something to consider after 1.0. For /var/tmp. I see deltacloud has written some files that can be cleaned up. I just need to confirm with mfojtik that is something we want to do. lutter mentioned that these temporary files are actually being relocated to /var/lib in another BZ. cc'ing mfojtik to get his opinion on this matter. I think the main issue I ran into was removing the bucket subdirectories. If we purge the files under them but _not_ the subdirectories themselves we won't have filesystem filling-up issues. However, are there other reasons that removing the data files as part of cleanup would cause inconsistency issues (assuming the subdirs are retained?) It's all kinds of insane that we do not implement deletion of buckets, at least when they're empty. It needs to be done. Let's file a new RedMine task or whatever. We have special rake task in Deltacloud to clean all mock-fixtures copied to /var/tmp over time for given user. firefly ~/code/core/server $ rake mock:fixtures:clean rm -rf /var/tmp/deltacloud-mock-mfojtik This rake task should be part of aeolus-cleanup. (In reply to comment #9) > We have special rake task in Deltacloud to clean all mock-fixtures copied to > /var/tmp over time for given user. > > firefly ~/code/core/server $ rake mock:fixtures:clean > rm -rf /var/tmp/deltacloud-mock-mfojtik > > This rake task should be part of aeolus-cleanup. Michal, I don't see the Rakefile in the deltacloud-core rpm distribution. Does the task do anything additional than the rm -rf command? Pushed to aeolus-configure commit 6f936542dc3373587f4be9b358114efd2564abba cleanup is working fine with aeolus-configure-2.8.7-1.el6cf , the actual results are: [root@qeblade22 ~]# find /var/tmp/ /var/tmp/ [root@qeblade22 ~]# find /var/lib/iwhd/ /var/lib/iwhd/ /var/lib/iwhd/templates /var/lib/iwhd/icicles /var/lib/iwhd/images /var/lib/iwhd/target_images /var/lib/iwhd/builds /var/lib/iwhd/provider_images Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-1516.html |