On 16.10.17 23:07, Laurence Field wrote: > Hi Steffen, > > On 16/10/17 16:46, Steffen Möller wrote: >> >> And he also builds the complete packages together with the server side >> components afterwards that go to the experimental section of Debian - >> see the boinc-server-maker package >> https://packages.qa.debian.org/b/boinc/news/20171005T094923Z.html. It >> would help a lot if the server bits in master are always be at a stage >> that it could be released. > Thanks, I was already aware of the server in the experimental section > and completely agree that master should always be 'deployable'. > Recently I built a server package for CentOS7 and asked for some > feedback on this very list. There was none.
That server-side package is somewhat of importance to me - please kindly (re)send me a pointer to your packaging instructions and I certainly will have comments - I mean, I have tons of comments on what I had once come up with :) > At the BOINC workshop in Paris this was discussed and the consensus > was to try using Docker for the server releases. Right. Would work. And it would make some sense to capsule it all away, too. I just hope you get it into Docker/Singularity as a package, not from the sources. The boinc-server-maker package ships make-project, including the example apps, so there is no need to perform the compilation, and the Docker image is based on Debian (old-stable) anyway. Takes far less than five minutes, too :) > The approach was stimulated by this presentation from Marius. We at > LHC@home plan to investigate this for our project at some point in the > future. > > https://indico.cern.ch/event/648533/contributions/2710464/attachments/1519821/2373725/boincserverdocker.pdf > Except that your are in Scientific Linux land, so I presume. >> In my mind this goes as far as that for automated testing we could have >> dummy project set up in an automated fashion and do few workunits on >> those. >> > It seems from the presentation that we are not that far from this goal. Good. The server side is not only about getting the project going. It is also about clarifying the exact include paths and generally helping projects with updates/upgrades of the BOINC-parts of their infrastructure. And then it does not matter if you run on bare metal or with some sort of virtualisation. You want to know about what version of the BOINC server was updated with what other version and that it has worked. Linux distributions are pretty good at this. As a neat side effect, the example projects get compiled for the many architectures of Debian, which you can collect and distribute to clients. Most important to me is that the BOINC server as a package in a regular Linux distribution brings (data parallel) HPC to every home, to every scientific institute. I tend to think of it as a social achievement. Having containers/a VM in between is desirable for security purposes, but it also weakens the point a bit. Sorry for being somewhat "emotional" here, Steffen _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
