Last modified: 2014-07-12 18:20:53 UTC
Bug #67912 showed that role::labs::lvm::biglogs is fundamentally broken: You can't move around/shadow /var/log in a running system. I thought about some super-duper OpenStackManager UI where you could specify the partitioning and during reboots OpenStack would shuffle the files and volumes accordingly, so that you always have a clean system, when Yuvi pointed out a far superior solution: If we increase the size of the default /var partition by (for Tools, other projects may need more) 2 GByte, we wouldn't have to think about all that complex stuff, because (at Tools) /var/log is usually less than 2 GBytes big. With the same step, we might want to set up a separate /tmp partition (could be even ramdisk) to avoid the problems of people filling that up as well. This will require a bit of disk space at virt*, and it will not solve all partitioning needs there are at Labs, but I think it is a quick solution for 90 % that could last a long time.
This is definitely the wrong solution; doing it this /at best/ simply delays the problem and fixes absolutely nothing. Anything that stuff things into /var/log needs to be careful about proper log rotation regardless of whether there are 2G or 100G available. Being able to specify the size of an LVM volume at creation time would be fine, so would fixing the class to be smarter about pivoting the mountpoints when it gets applied the first time; but any fixed partitioning scheme in the image is doomed to fail. (Also, /tmp in ram is a very bad idea on physical hardware as it makes it trivial for memory to end up exhausted - on virtual hardware it increases the memory footprint at the detriment of performance of every VM which is even worse).
