Ticket #1860 (closed enhancement: fixed)

Opened 6 years ago

Last modified 6 years ago

Add a Jenkins job for monitoring the disk usage on http://sites.imagej.net/

Reported by: dscho Owned by: dscho
Priority: major Milestone: imagej2-b7-ndim-data
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 6 years ago by dscho

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.

comment:2 Changed 6 years ago by dscho

  • Blocked By 1862 added

comment:3 Changed 6 years ago by dscho

  • Status changed from new to closed
  • Resolution set to fixed

comment:4 Changed 6 years ago 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 6 years ago 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 6 years ago 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 6 years ago 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 6 years ago by bdezonia

  • Milestone changed from imagej2-b8-analysis to imagej2-b7-ndim-data
Note: See TracTickets for help on using tickets.