> So assuming saros-build2 is provided with the same virtual hardware as > saros-build ...
That's what our IT keeps telling me. > WTF is wrong with saros-build ? Can you really misconfigure a UNIX > system in such a bad way ? The first weird thing about saros-build back in 2012 was that it slowed down after upgrading it from one to two CPUs. (We downgraded to one CPU but we basically learned nothing from this [1,2]). If you look at htop while any Jenkins job (preferably with lots of I/O) is running, you'll see that up to 95% of the CPU time is spent in Kernel space. (For instance, taking rsync's time during an execution of Saros-Core-Gerrit-QA [3]: real 0m27.217s; user 0m1.170s; sys 0m23.840s -- on saros-build2 it's: real 0m0.204s; user 0m0.064s; sys 0m0.144s) I have no explanation for this. And thankfully I don’t have to as we will able to forget saros-build altogether soon :) Franz [1] http://thread.gmane.org/gmane.comp.ide.eclipse.saros.devel/281 [2] http://thread.gmane.org/gmane.comp.ide.eclipse.saros.devel/288/focus=293 [3] http://saros-build.imp.fu-berlin.de/jenkins/job/Saros-Core-Gerrit-QA/554/consoleFull -----Original Message----- From: Stefan Rossbach [mailto:srossb...@arcor.de] Sent: Wednesday, February 17, 2016 8:39 PM To: Zieris, Franz <franz.zie...@fu-berlin.de>; dpp-devel@lists.sourceforge.net Subject: Re: [DPP-Devel] What is saros-build2? So assuming saros-build2 is provided with the same virtual hardware as saros-build ... WTF is wrong with saros-build ? Can you really misconfigure a UNIX system in such a bad way ? On 17.02.2016 20:33, Zieris, Franz wrote: > Arsenij asked: >> What's the difference between saros-build and saros-build2 ? > Well, about seven years of patchy maintenance work. > > Seriously: > Both are virtual machines hosted by our in-department IT, with similar > "hardware" characteristics. > Saros-build2, however, is set up programmatically. > This is done through Saltstack [1], which our IT uses routinely for several > tasks (if you heard of Puppet: it's somewhat similar). > > The idea behind this is to make maintenance much easier: > Instead of "sudo apt-get upgrade"-ing on the machine, you just edit a > configuration file and let SaltStack reconfigure the machine. > In addition, all custom configurations (usually in the form of config files) > are stored along-side the system config in a Git repository. > > The deal with saros-build2 is the following: > - Our IT provides the machine with the packages and services we want. > So far, it's an up-to-date Debian machine with running instances of > Jenkins, Gerrit and SonarQube. > - Every update on these services themselves is done by the IT. > If we something new (such as NodeJS), we write a ticket, they create a > new Git commit in the server config repo, and update the server. > - Everything inside is up to us: The Jenkins plugins installed, all jobs > configuration, the SonarQube setup, etc. > This is considered user data and therefore backuped regularly by the IT. > > As of now, saros-build2 is only reachable from within Freie Universität (or > VPN or ZEDAT http proxy). > Anyone in the right network, here you go: > - http://saros-build2.imp.fu-berlin.de/gerrit > - http://saros-build2.imp.fu-berlin.de/jenkins > - http://saros-build2.imp.fu-berlin.de/sonarqube > > I'm currently in the process of moving more of our "user data", i.e. Jenkins > jobs and everything around them, to the new machine. > As soon as this is complete, we will shut down saros-build and make > saros-build2 available under the standard domain. > > The machines saros-eclipse1 and 2 will also be replaced in this manner. > > Actually, moving the STF jobs to the new server is basically the only > critical thing left. > This means: In principle we could switch to saros-build2 already, make it > publicly visible and deactivate everything but the STF jobs on old > saros-build. > > Any thoughts? > > Franz > > PS: Just in case you thought moving some Jenkins jobs would be not a big deal > ... > I spent 16 hours during my weekend getting the three amigos (Gerrit, Jenkins, > SonarQube) working together. > This was because I did not just copy the old Jenkins jobs, but split them up, > joined them, streamlined them. > It actually was fun -- partly because the server did response in under a > second to all my HTTP requests ... > > [1] https://docs.saltstack.com/en/latest/ > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
