<div dir="ltr">Hello everyone,<div><br></div><div>Zorg is a common code for multiple different buildbot setups. This is why it sits in its own subtree.</div><div>The only tricky thing there is that it assumes some relative position of zorg and master setup. Documenting this would save somebody some time.</div>
<div><br></div><div>All together wasn't a problem so far. But having a better documentation and a set of files for a simple local setup is a good idea. Patches are welcome. Otherwise it will wait till I have time for this.</div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">* Buildbot should load slaves from a file not under version control </span><span style="font-family:arial,sans-serif;font-size:13px">for local testing.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">I'm skeptical about pre-cooked dev buildbot/zorg setup. In any real case, a developer will need to modify the master to host a custom builder which is work in progress. The best we can do is preparing a consistent set of configuration files for a simple existing builder (just one), but all files should be under the version control. So one could be sure the setup is complete and could see the local changes he/she made and roll them back if desired.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">The rest is fine with me.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">* reload()</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">As Daniel mentioned, we are trying to apply as much changes as practical without restarting the production buildbot. Each restart is a disturbance.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">* Ancient version of buildbot.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><font face="arial, sans-serif">We had problems with newer versions and we have a number of local changes and bug fixed which didn't make in 0.8 branch because the buildbot team considers them "too risky". The changes are pending for 0.9.</font></div>
<div><font face="arial, sans-serif">The production is stable and working well, and I'm not aware of any cool feature we are missing on master. None of this changes is relevant for the "new builder development" case, only fr the production build master.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Slaves are a different story. As far as I know, we work with any recent version of slaves.</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif">Bounding the "dev/test setup" to any specific version could be easily avoided by choosing a right builder. So, this should not be a problem for someone who would wont to develop and test a build factory.</font></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-family:arial,sans-serif;font-size:13px">* llvmlab, osuosl, smooshlab?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Reorganizing this currently is a work in progress. osuosl is in use; </span><font face="arial, sans-serif">llvmlab is in use but will be decommissioned; </font><span style="font-family:arial,sans-serif;font-size:13px">smooshlab</span><span style="font-family:arial,sans-serif;font-size:13px"> is used internally and is pending to be removed.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">In general, if you don't feel comfortable developing and debugging a build factory for the buildbot, you can always use the scripted builder. This is why we added it in the first place.</font></div>
<div><font face="arial, sans-serif">It provides a way to have an internal script which would integrate in to the buildbot and look "native" as well as could be used by itself. It was used for cross builds and for the </font><span style="font-family:arial,sans-serif;font-size:13px">Dragonegg scripts.</span></div>
<div class="gmail_extra"><br>Thanks</div><div class="gmail_extra"><br></div><div class="gmail_extra">Galina</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">
On Thu, Aug 7, 2014 at 4:57 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">My $.02<br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Wed, Aug 6, 2014 at 3:52 PM, Dan Liew <span dir="ltr"><<a href="mailto:dan@su-root.co.uk" target="_blank">dan@su-root.co.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
Recent conversations [1][2] would suggest we need to rethink zorg or<br>
at the very least improve the documentation.<br>
<br>
I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because it<br>
seemed that they have contributed the most code to Zorg<br>
<br>
Organisation<br>
=========<br>
<br>
The current organisation of the Zorg repository doesn't make a huge<br>
amount of sense from my perspective. There are two things that we<br>
should be able to do with this code<br>
<br>
- Run the currently in use buildbot master.<br>
- Run a builtbot master and slave on a local machine for testing.<br></blockquote><div><br></div></div><div>Realistically, these are pretty challenging goals I think. Running buildbot is very challenging and the tool itself just isn't designed well for this use case. My feeling on this is that if people are motivated enough to actually do this, then figuring out zorg isn't going to be the limited factor. Of course if you have improvements in mind I would encourage you to commit them, I just don't think it is worth making it a priority.</div>
<div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The current project layout doesn't seem to facilitate either of these<br>
needs particularly well. If we take a look at<br>
``/buildbot/osuosl/master`` the ``zorg`` folder isn't in here so the<br>
``master.cfg`` adds a non portable hack to load the zorg code (assumes<br>
zorg is in user's home directory).<br>
<br>
Unless there is a good reason for doing so I think the zorg modules<br>
should be moved into the master buildbot directory so this hack isn't<br>
necessary. If there is a really good reason for doing this we should<br>
document this so people can actually run the buildbot master on their<br>
own machine.<br>
<br>
The ``master.cfg`` file is also full of stuff that is not suited for<br>
testing a master and slaves hosted on the same machine.<br>
<br>
* Buildbot master should only listen on localhost (no out going connections)<br>
* Buildbot master should have no authorisation and show the web<br>
interface so manual builds are easy to trigger<br>
* Buildbot master should not use the large list of slaves because a<br>
locally hosted master cannot connect to these because they shouldn't<br>
be contacted for testing (it doesn't have the passwords for these<br>
buildbot slaves either).<br>
* Buildbot should load slaves from a file not under version control<br>
for local testing.<br></blockquote><div><br></div></div><div>This is all fine with me.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Either we need to make it so that the buildbot master<br>
(/buildbot/osuosl/master) can operate in two modes (normal and<br>
localhost testing) or we need to provide another buildbot master<br>
configuration for localhost testing. I think this is what<br>
``buildbot/smooshlab`` is for but that code has not been touched in<br>
ages and is probably dead (if it is dead, we should delete it).<br></blockquote><div><br></div></div><div>smooshlab was a different configuration, not just one for testing. It can be removed.</div><div class=""><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Other issues<br>
==========<br>
<br>
* Ancient version of buildbot.<br>
<br>
Why do we use buildbot 0.8.5? Newer versions are available in Pypi<br>
which anyone using Python can install. I have issues with 0.8.5 and I<br>
have to patch it before it will actually work. I don't think we should<br>
have in our documentation that you need to patch buildbot, we should<br>
just upgrade to a newer version.<br></blockquote><div><br></div></div><div>I have no opinion on this. In the past I know we have hit issues moving to newer versions of buildbot, so it just means someone taking responsibility for testing and updating.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* reload()<br>
<br>
I see lots of reload() all over the place. Why do we need these?<br>
Surely if you do<br>
<br>
$ buildbot stop master<br>
$ buildbot start master<br>
<br>
This would reload everything making uses of ``reload()`` pointless.<br></blockquote><div><br></div></div><div>These are necessary and useful for when you run "buildbot reconfig", which is a very useful way of working esp. when dealing with a production setup where you don't want builders to stop.</div>

<div><br></div><div>The reloads are necessary because reconfig just reloads the data inside the running instance, so any modules need to be reload()ed, and because of how imports work, there is a dependency issues between every module you want reloaded. There are cleaner ways to solve this problem (like trying to auto reload by inferring the appropriate dependencies and scanning sys.modules).</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* KLEE stuff<br>
<br>
KLEE is no longer actively developed as part of LLVM so all this stuff<br>
should be dropped from Zorg.<br></blockquote><div><br></div></div><div>Sure, I don't know of anyone using this.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
* Lack of documentation<br>
This can be addressed once we fix the other issues.<br>
<br>
* Builders<br>
<br>
There are lots of python modules in ``zorg/zorg/buildbot/builders``.<br>
These are Factories, not builders so why do they have ``Builder`` in<br>
their name and are in the "builders" folder? This is unnecessarily<br>
confusing.<br></blockquote><div><br></div></div><div>Yes, renaming this would make sense.</div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
* llvmlab, osuosl, smooshlab?<br>
<br>
Not sure those names are particularly helpful. I suspect ``smooshlab``<br>
will probably be removed entirely and I suspect osuosl ought to be<br>
renamed. I'm not sure if we need to keep any of the llvmlab stuff.<br></blockquote><div><br></div></div><div>llvmlab -- instance on <a href="http://lab.llvm.org" target="_blank">lab.llvm.org</a></div><div>osuosl -- old place we used to run buildbots</div>

<div>smooshlab -- an internal setup that doesn't need to remain in the zorg repo</div><div class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

This is probably an incomplete list of issues but theses are issues I<br>
have observed in my brief time playing with Zorg and buildbot.<br></blockquote><div><br></div></div><div>Generally speaking, there just isn't anyone who is really owning and maintaining the buildbot setup. If you want to take it over and clean it up, I don't think anyone is going to fight with you over it. :)</div>

<div><br></div><div>My experience after maintaining the buildbot stuff for a long time was that I wasn't particularly happy with buildbot itself and how it all played out. If I had to do it over again, I would probably move more in the direction of having the CI system run build scripts that are checked in to the individual project repositories. If people needed to reproduce a CI build, the recommended advice would then be to run those scripts directly, and those scripts could be written in languages people are comfortable with, not the complicated buildbot scripting-by-instantating-factory-steps-setup. This seems to be the direction Duncan went with the Dragonegg scripts.</div>

<div><br></div><div>HTH,</div><div> - Daniel</div><div class=""><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html</a><br>
[2] <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075348.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075348.html</a><br>
<br>
<br>
Thanks,<br>
Dan.<br>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>