large jumps in rootfs disk space should trigger a bug |
||||||||||
Issue descriptionwe've got a dashboard that tracks disk usage: https://chromeperf.appspot.com/report test suite: build_RootFilesystemSize bot: cros-glimmer (but any will do) subtest: bytes_rootfs_prod then look at the date range at the bottom. stretch it out so it goes back to 2016-03. you'll see at least three red ! marks in there. each of those should have triggered a bug that needed approval/resolving. otherwise, we end up with a slow silent march to out-of-disk space and then canaries/paladins start dying ( issue 650105 & issue 651224 ).
,
Feb 18 2017
,
Apr 4 2017
adlr - any chance we could throw some nooglers at this?
,
Apr 4 2017
,
Apr 10 2017
,
Apr 10 2017
,
Apr 10 2017
FWIW, I get alerts whenever the rootfs grows even just a little (I've gotten warnings for 15MB increase). I track them down and discuss w/ the person about how to fix things. If we can make a bug that would be ideal, as right now I am doing this just on email.
,
Apr 10 2017
#7 How do you get the alerts?
,
Apr 10 2017
Deymo wrote me in an email a while back: "Join g/chromeos-installer-bugs and you will get an email whenever there's a more than 1% increase in the used filesystem size."
,
Apr 10 2017
First: hi! First day on Chrome OS. *waves* I've been reading about the manner in which https://chromeperf.appspot.com functions. I found this documentation which indicates that its possible to configure a bug component when a performance alert fires: https://github.com/catapult-project/catapult/blob/master/dashboard/docs/admin-tasks.md . At first, it seemed that this had never been configured for *any* Chrome OS component according to this spreadsheet: go/chrome-benchmarks . This was apparently the outcome of this initiative: https://docs.google.com/document/d/1qlbrSRtqZpCyp1R1HCt0xLklMHno-Mvuz5U24QyQKh4/edit . However, with adlr@'s link to g/chromeos-installer-bugs, that would seem to indicate that someone has configured the Chrome OS Perf Sherrif alerting but used email to do so. I can't confirm that, though, because I don't have access to the Admin console. To fix this, all it would seem that I need to do is to file a ticket in the Perf console UI via "Report Issue" > "Request Monitoring for Tests". So: * Do we want to keep the existing emails to g/chromeos-installer-bugs? * Which component do we want to file the bugs in? * Which email aliases/owners do we want to assign/CC the bug to? My guess would be that assigning the bug to a large organization would result in diffusion of responsibility and the alert being ignored. The spirit of the initiative referenced above seems to be that small groups of folks own specific alerts. However, that may be quite old so I don't know if that's still the cultural norm. Thoughts?
,
Apr 10 2017
- Keep the current emails going to the list - not sure which component we want - You can assign to me for now
,
Apr 10 2017
Ok, will use OS>Installer for now. LMK if you want something different.
,
Apr 10 2017
,
Apr 12 2017
,
May 30 2017
,
Aug 1 2017
,
Jan 22 2018
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by adlr@chromium.org
, Sep 29 2016