Ticket #1860 (closed enhancement: fixed)
Opened 2013-05-10T12:58:46-05:00
Last modified 2013-05-31T16:16:40-05:00
Add a Jenkins job for monitoring the disk usage on http://sites.imagej.net/
| Reported by: | dscho | Owned by: | dscho |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Server Admin | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | curtis | Blocked By: | #1862 |
| Blocking: | #1857 |
Description
For the moment, sites.imagej.net shares disk space with openspim.org, and in any case, users of sites.imagej.net will share disk space with each other. To prevent abuse (and thereby denying other users the space), let's monitor the disk usage using Jenkins.
Change History
comment:1 Changed 2013-05-10T12:59:59-05:00 by dscho
comment:3 Changed 2013-05-12T10:16:22-05:00 by dscho
- Status changed from new to closed
- Resolution set to fixed
This job is now in place: http://jenkins.imagej.net/job/Monitor-sites.imagej.net/
comment:4 Changed 2013-05-12T10:35:32-05:00 by dscho
Forgot to mention: to be able to mark the build as unstable when a soft quota is reached, or when unexpected files were found, I also copied jenkins-cli.jar into ~jenkins/bin/ and added a private key.
comment:5 Changed 2013-05-13T09:59:28-05:00 by curtis
So if I understand correctly, Jenkins is running a script which calls jenkins-cli to change Jenkins state? Wouldn't it be simpler to use Groovy postbuild to set the build to unstable that way?
(I took a very quick look at the job to find out the answer for myself, but it is quite complex, with a long shell script embedded in the job, so I am punting with this comment instead.)
comment:6 Changed 2013-05-13T11:09:55-05:00 by dscho
Jenkins runs the shell script on the node (and thus has easy access to the files generated by said script), but runs the postbuild on the master (which does not).
Actually, in our case, I archive the files so the postbuild *could* access the files and read them and analyze them, but I think doing that would be more fragile (and also would require more code to begin with, as shell is *still* more expressive than Groovy).
comment:7 Changed 2013-05-13T11:12:55-05:00 by curtis
OK, thanks, that makes sense. The current approach sounds fine then. Another possibility would be to change the shell script to do the analysis, but rather than using jenkins-cli to mark the build as unstable, instead write out a file RESULT with e.g. "Success" or "Unstable" or "Failure" as its contents, then have the Groovy postbuild use that to decide. But I don't feel strongly about it.
comment:8 Changed 2013-05-31T16:16:40-05:00 by bdezonia
- Milestone changed from imagej2-b8-analysis to imagej2-b7-ndim-data
My original plan was to do it via quotas, but quotas are only per-user and per-filesystem, not per-directory. Since the same "user" (i.e. www-data) owns all the files, quotas are pretty useless here.