https://bugzilla.wikimedia.org/show_bug.cgi?id=73472
--- Comment #10 from Greg Grossmeier <g...@wikimedia.org> --- (In reply to Andrew Bogott from comment #9) > (In reply to Greg Grossmeier from comment #8) > > (In reply to Andrew Bogott from comment #7) > > > Greg -- > > > > > > For new instances /var/log is somewhat resizeable. > > > > How much? Can we just change the default for new deployment-prep instances > > to be $large-enough-to-not-matter? > > Resizeable up to the available space selected when the instance was > originally created. > > It should be possible to set up sizing of /var/log based on project. I'll > have a look at that if that's the direction you want to go. I guess we should way this ^ and the unbounded growth concern below. > > Worst case scenario is creating a second instance of whatever with a larger > > disk, moving traffic to it, then shutting down the old one, right? > > That's correct. In perfect-puppet-land, doing that should be trivial, but > I've been led to understand that in the real world it's a big pain. Sadly, but that also points out other legitimate bugs :) > > (as opposed to addressing the real underlying > > issue of too little space on the VMs we use for our integration environment > > which everyone depends on daily). > > One might argue that the 'real problem' is unbounded log growth, and that > beta just displays the symptoms sooner than production. But I don't know if > the issue really is unbounded growth or if growth is bounded properly but > just bounded outside the capacity of existing instances. Touche. But I'm still worried about all the differences between prod and beta that cause surprises :/ -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
