llvm dev - Aug 2014 - [LLVMdev] [Zorg] Reorganisation, documentation and other issues

Hi All,

Recent conversations [1][2] would suggest we need to rethink zorg or
at the very least improve the documentation.

I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because it
seemed that they have contributed the most code to Zorg

Organisation
========
The current organisation of the Zorg repository doesn't make a huge
amount of sense from my perspective. There are two things that we
should be able to do with this code

- Run the currently in use buildbot master.
- Run a builtbot master and slave on a local machine for testing.

The current project layout doesn't seem to facilitate either of these
needs particularly well. If we take a look at
``/buildbot/osuosl/master`` the ``zorg`` folder isn't in here so the
``master.cfg`` adds a non portable hack to load the zorg code (assumes
zorg is in user's home directory).

Unless there is a good reason for doing so I think the zorg modules
should be moved into the master buildbot directory so this hack isn't
necessary. If there is a really good reason for doing this we should
document this so people can actually run the buildbot master on their
own machine.

The ``master.cfg`` file is also full of stuff that is not suited for
testing a master and slaves hosted on the same machine.

* Buildbot master should only listen on localhost (no out going connections)
* Buildbot master should have no authorisation and show the web
interface so manual builds are easy to trigger
* Buildbot master should not use the large list of slaves because a
locally hosted master cannot connect to these because they shouldn't
be contacted for testing (it doesn't have the passwords for these
buildbot slaves either).
* Buildbot should load slaves from a file not under version control
for local testing.

Either we need to make it so that the buildbot master
(/buildbot/osuosl/master) can operate in two modes (normal and
localhost testing) or we need to provide another buildbot master
configuration for localhost testing. I think this is what
``buildbot/smooshlab`` is for but that code has not been touched in
ages and is probably dead (if it is dead, we should delete it).


Other issues
=========
* Ancient version of buildbot.

Why do we use buildbot 0.8.5? Newer versions are available in Pypi
which anyone using Python can install. I have issues with 0.8.5 and I
have to patch it before it will actually work. I don't think we should
have in our documentation that you need to patch buildbot, we should
just upgrade to a newer version.

* reload()

I see lots of reload() all over the place. Why do we need these?
Surely if you do

$ buildbot stop master
$ buildbot start master

This would reload everything making uses of ``reload()`` pointless.

* KLEE stuff

KLEE is no longer actively developed as part of LLVM so all this stuff
should be dropped from Zorg.

* Lack of documentation
This can be addressed once we fix the other issues.

* Builders

There are lots of python modules in ``zorg/zorg/buildbot/builders``.
These are Factories, not builders so why do they have ``Builder`` in
their name and are in the "builders" folder? This is unnecessarily
confusing.

* llvmlab, osuosl, smooshlab?

Not sure those names are particularly helpful. I suspect ``smooshlab``
will probably be removed entirely and I suspect osuosl ought to be
renamed. I'm not sure if we need to keep any of the llvmlab stuff.

This is probably an incomplete list of issues but theses are issues I
have observed in my brief time playing with Zorg and buildbot.

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html
[2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075348.html


Thanks,
Dan.

This is a great idea!

Lots of questions: I’m just going to dump what I know.

There are many (at least 3) buildmasters that use zorg package, so it makes
sense to keep it common.   I think smooshlab was an actual cluster that ran for
a while.  llvmlab is the cluster that is happy running here:

http://lab.llvm.org:8013/builders

We also run a parivate build cluster using zorg.

On our internal bots I wrote something that adjusts the python path, which I use
to wrap the master config. That just looks up the zorg path relative from the
master.cfg file. I don’t know how portable that is, but at least it is not a
hard coded path to the users home dir...

It would be really handy to have a simple single master/slave config template
for prototyping.  What might make sense is another config next to smooshlab,
llvmlab etc, that has a simple local config.  Everything on localhost, no emails
etc.  Then you could work on the one or two zorg builders you want to muck with,
then finally add your builder to the production configs.

We use buildbot 0.8.8 internally with zorg, and have no problems.  It might just
be that no one has volunteered to upgrade us.

The buildbot stop/start kills all the running builds, so they have to restart.
On big clusters that super annoying if it happens regularly. I think we use the
reloads where possible to make sure buildbot reconfig works as expected.
> On Aug 6, 2014, at 3:52 PM, Dan Liew <dan at su-root.co.uk> wrote:
> 
> Hi All,
> 
> Recent conversations [1][2] would suggest we need to rethink zorg or
> at the very least improve the documentation.
> 
> I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because
it
> seemed that they have contributed the most code to Zorg
> 
> Organisation
> ========> 
> The current organisation of the Zorg repository doesn't make a huge
> amount of sense from my perspective. There are two things that we
> should be able to do with this code
> 
> - Run the currently in use buildbot master.
> - Run a builtbot master and slave on a local machine for testing.
> 
> The current project layout doesn't seem to facilitate either of these
> needs particularly well. If we take a look at
> ``/buildbot/osuosl/master`` the ``zorg`` folder isn't in here so the
> ``master.cfg`` adds a non portable hack to load the zorg code (assumes
> zorg is in user's home directory).
> 
> Unless there is a good reason for doing so I think the zorg modules
> should be moved into the master buildbot directory so this hack isn't
> necessary. If there is a really good reason for doing this we should
> document this so people can actually run the buildbot master on their
> own machine.
> 
> The ``master.cfg`` file is also full of stuff that is not suited for
> testing a master and slaves hosted on the same machine.
> 
> * Buildbot master should only listen on localhost (no out going
connections)
> * Buildbot master should have no authorisation and show the web
> interface so manual builds are easy to trigger
> * Buildbot master should not use the large list of slaves because a
> locally hosted master cannot connect to these because they shouldn't
> be contacted for testing (it doesn't have the passwords for these
> buildbot slaves either).
> * Buildbot should load slaves from a file not under version control
> for local testing.
> 
> Either we need to make it so that the buildbot master
> (/buildbot/osuosl/master) can operate in two modes (normal and
> localhost testing) or we need to provide another buildbot master
> configuration for localhost testing. I think this is what
> ``buildbot/smooshlab`` is for but that code has not been touched in
> ages and is probably dead (if it is dead, we should delete it).
> 
> 
> Other issues
> =========> 
> * Ancient version of buildbot.
> 
> Why do we use buildbot 0.8.5? Newer versions are available in Pypi
> which anyone using Python can install. I have issues with 0.8.5 and I
> have to patch it before it will actually work. I don't think we should
> have in our documentation that you need to patch buildbot, we should
> just upgrade to a newer version.
> 
> * reload()
> 
> I see lots of reload() all over the place. Why do we need these?
> Surely if you do
> 
> $ buildbot stop master
> $ buildbot start master
> 
> This would reload everything making uses of ``reload()`` pointless.
> 
> * KLEE stuff
> 
> KLEE is no longer actively developed as part of LLVM so all this stuff
> should be dropped from Zorg.
> 
> * Lack of documentation
> This can be addressed once we fix the other issues.
> 
> * Builders
> 
> There are lots of python modules in ``zorg/zorg/buildbot/builders``.
> These are Factories, not builders so why do they have ``Builder`` in
> their name and are in the "builders" folder? This is
unnecessarily
> confusing.
> 
> * llvmlab, osuosl, smooshlab?
> 
> Not sure those names are particularly helpful. I suspect ``smooshlab``
> will probably be removed entirely and I suspect osuosl ought to be
> renamed. I'm not sure if we need to keep any of the llvmlab stuff.
> 
> This is probably an incomplete list of issues but theses are issues I
> have observed in my brief time playing with Zorg and buildbot.
> 
> [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html
> [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075348.html
> 
> 
> Thanks,
> Dan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

My $.02


On Wed, Aug 6, 2014 at 3:52 PM, Dan Liew <dan at su-root.co.uk> wrote:
> Hi All,
>
> Recent conversations [1][2] would suggest we need to rethink zorg or
> at the very least improve the documentation.
>
> I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because
it
> seemed that they have contributed the most code to Zorg
>
> Organisation
> ========>
> The current organisation of the Zorg repository doesn't make a huge
> amount of sense from my perspective. There are two things that we
> should be able to do with this code
>
> - Run the currently in use buildbot master.
> - Run a builtbot master and slave on a local machine for testing.
>
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.
>
> The current project layout doesn't seem to facilitate either of these
> needs particularly well. If we take a look at
> ``/buildbot/osuosl/master`` the ``zorg`` folder isn't in here so the
> ``master.cfg`` adds a non portable hack to load the zorg code (assumes
> zorg is in user's home directory).
>
> Unless there is a good reason for doing so I think the zorg modules
> should be moved into the master buildbot directory so this hack isn't
> necessary. If there is a really good reason for doing this we should
> document this so people can actually run the buildbot master on their
> own machine.
>
> The ``master.cfg`` file is also full of stuff that is not suited for
> testing a master and slaves hosted on the same machine.
>
> * Buildbot master should only listen on localhost (no out going
> connections)
> * Buildbot master should have no authorisation and show the web
> interface so manual builds are easy to trigger
> * Buildbot master should not use the large list of slaves because a
> locally hosted master cannot connect to these because they shouldn't
> be contacted for testing (it doesn't have the passwords for these
> buildbot slaves either).
> * Buildbot should load slaves from a file not under version control
> for local testing.
>
This is all fine with me.

> Either we need to make it so that the buildbot master
> (/buildbot/osuosl/master) can operate in two modes (normal and
> localhost testing) or we need to provide another buildbot master
> configuration for localhost testing. I think this is what
> ``buildbot/smooshlab`` is for but that code has not been touched in
> ages and is probably dead (if it is dead, we should delete it).
>
smooshlab was a different configuration, not just one for testing. It can
be removed.

>
> Other issues
> =========>
> * Ancient version of buildbot.
>
> Why do we use buildbot 0.8.5? Newer versions are available in Pypi
> which anyone using Python can install. I have issues with 0.8.5 and I
> have to patch it before it will actually work. I don't think we should
> have in our documentation that you need to patch buildbot, we should
> just upgrade to a newer version.
>
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.

>
> * reload()
>
> I see lots of reload() all over the place. Why do we need these?
> Surely if you do
>
> $ buildbot stop master
> $ buildbot start master
>
> This would reload everything making uses of ``reload()`` pointless.
>
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.

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).

>
> * KLEE stuff
>
> KLEE is no longer actively developed as part of LLVM so all this stuff
> should be dropped from Zorg.
>
Sure, I don't know of anyone using this.

>
> * Lack of documentation
> This can be addressed once we fix the other issues.
>
> * Builders
>
> There are lots of python modules in ``zorg/zorg/buildbot/builders``.
> These are Factories, not builders so why do they have ``Builder`` in
> their name and are in the "builders" folder? This is
unnecessarily
> confusing.
>
Yes, renaming this would make sense.

> * llvmlab, osuosl, smooshlab?
>
> Not sure those names are particularly helpful. I suspect ``smooshlab``
> will probably be removed entirely and I suspect osuosl ought to be
> renamed. I'm not sure if we need to keep any of the llvmlab stuff.
>
llvmlab -- instance on lab.llvm.org
osuosl -- old place we used to run buildbots
smooshlab -- an internal setup that doesn't need to remain in the zorg repo


> This is probably an incomplete list of issues but theses are issues I
> have observed in my brief time playing with Zorg and buildbot.
>
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. :)

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.

HTH,
 - Daniel



> [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html
> [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075348.html
>
>
> Thanks,
> Dan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140807/2f1aab6a/attachment.html>

>
> 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.
>
There's no reason we couldn't test the water with some other CI setup
while
also keeping buildbot up and running until we find something that we like
better. We'd want to avoid a situation where we end up with *two* CI setups
permanently (especially two we don't like), but as long as we keep buildbot
as the primary until we find something better that shouldn't be an issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140811/060191a4/attachment.html>

Hello everyone,

Zorg is a common code for multiple different buildbot setups. This is why
it sits in its own subtree.
The only tricky thing there is that it assumes some relative position of
zorg and master setup. Documenting this would save somebody some time.

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.
> * Buildbot should load slaves from a file not under version control for
local testing.

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.

The rest is fine with me.
> * reload()
As Daniel mentioned, we are trying to apply as much changes as practical
without restarting the production buildbot. Each restart is a disturbance.
> * Ancient version of buildbot.
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.
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.

Slaves are a different story. As far as I know, we work with any recent
version of slaves.

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.
> * llvmlab, osuosl, smooshlab?
Reorganizing this currently is a work in progress. osuosl is in use; llvmlab
is in use but will be decommissioned; smooshlab is used internally and is
pending to be removed.

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.
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 Dragonegg scripts.

Thanks

Galina



On Thu, Aug 7, 2014 at 4:57 PM, Daniel Dunbar <daniel at zuster.org>
wrote:
> My $.02
>
>
> On Wed, Aug 6, 2014 at 3:52 PM, Dan Liew <dan at su-root.co.uk>
wrote:
>
>> Hi All,
>>
>> Recent conversations [1][2] would suggest we need to rethink zorg or
>> at the very least improve the documentation.
>>
>> I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands
because it
>> seemed that they have contributed the most code to Zorg
>>
>> Organisation
>> ========>>
>> The current organisation of the Zorg repository doesn't make a huge
>> amount of sense from my perspective. There are two things that we
>> should be able to do with this code
>>
>> - Run the currently in use buildbot master.
>> - Run a builtbot master and slave on a local machine for testing.
>>
>
> 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.
>
>>
>> The current project layout doesn't seem to facilitate either of
these
>> needs particularly well. If we take a look at
>> ``/buildbot/osuosl/master`` the ``zorg`` folder isn't in here so
the
>> ``master.cfg`` adds a non portable hack to load the zorg code (assumes
>> zorg is in user's home directory).
>>
>> Unless there is a good reason for doing so I think the zorg modules
>> should be moved into the master buildbot directory so this hack
isn't
>> necessary. If there is a really good reason for doing this we should
>> document this so people can actually run the buildbot master on their
>> own machine.
>>
>> The ``master.cfg`` file is also full of stuff that is not suited for
>> testing a master and slaves hosted on the same machine.
>>
>> * Buildbot master should only listen on localhost (no out going
>> connections)
>> * Buildbot master should have no authorisation and show the web
>> interface so manual builds are easy to trigger
>> * Buildbot master should not use the large list of slaves because a
>> locally hosted master cannot connect to these because they
shouldn't
>> be contacted for testing (it doesn't have the passwords for these
>> buildbot slaves either).
>> * Buildbot should load slaves from a file not under version control
>> for local testing.
>>
>
> This is all fine with me.
>
>
>> Either we need to make it so that the buildbot master
>> (/buildbot/osuosl/master) can operate in two modes (normal and
>> localhost testing) or we need to provide another buildbot master
>> configuration for localhost testing. I think this is what
>> ``buildbot/smooshlab`` is for but that code has not been touched in
>> ages and is probably dead (if it is dead, we should delete it).
>>
>
> smooshlab was a different configuration, not just one for testing. It can
> be removed.
>
>
>>
>> Other issues
>> =========>>
>> * Ancient version of buildbot.
>>
>> Why do we use buildbot 0.8.5? Newer versions are available in Pypi
>> which anyone using Python can install. I have issues with 0.8.5 and I
>> have to patch it before it will actually work. I don't think we
should
>> have in our documentation that you need to patch buildbot, we should
>> just upgrade to a newer version.
>>
>
> 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.
>
>
>>
>> * reload()
>>
>> I see lots of reload() all over the place. Why do we need these?
>> Surely if you do
>>
>> $ buildbot stop master
>> $ buildbot start master
>>
>> This would reload everything making uses of ``reload()`` pointless.
>>
>
> 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.
>
> 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).
>
>
>>
>> * KLEE stuff
>>
>> KLEE is no longer actively developed as part of LLVM so all this stuff
>> should be dropped from Zorg.
>>
>
> Sure, I don't know of anyone using this.
>
>
>>
>> * Lack of documentation
>> This can be addressed once we fix the other issues.
>>
>> * Builders
>>
>> There are lots of python modules in ``zorg/zorg/buildbot/builders``.
>> These are Factories, not builders so why do they have ``Builder`` in
>> their name and are in the "builders" folder? This is
unnecessarily
>> confusing.
>>
>
> Yes, renaming this would make sense.
>
>
>> * llvmlab, osuosl, smooshlab?
>>
>> Not sure those names are particularly helpful. I suspect ``smooshlab``
>> will probably be removed entirely and I suspect osuosl ought to be
>> renamed. I'm not sure if we need to keep any of the llvmlab stuff.
>>
>
> llvmlab -- instance on lab.llvm.org
> osuosl -- old place we used to run buildbots
> smooshlab -- an internal setup that doesn't need to remain in the zorg
repo
>
>
>
>> This is probably an incomplete list of issues but theses are issues I
>> have observed in my brief time playing with Zorg and buildbot.
>>
>
> 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. :)
>
> 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.
>
> HTH,
>  - Daniel
>
>
>
>
>> [1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075287.html
>> [2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075348.html
>>
>>
>> Thanks,
>> Dan.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140811/10507cbe/attachment.html>

On 7 August 2014 04:05, Chris Matthews <chris.matthews at apple.com>
wrote:
> This is a great idea!
>
> Lots of questions: I’m just going to dump what I know.
>
> There are many (at least 3) buildmasters that use zorg package, so it makes
sense to keep it common.   I think smooshlab was an actual cluster that ran for
a while.  llvmlab is the cluster that is happy running here:
Okay I didn't realise anyone was using zorg outside of the tree. In
that case it definitely makes sense to leave the zorg python packages
where they are.
> http://lab.llvm.org:8013/builders
>
> We also run a parivate build cluster using zorg.
>
> On our internal bots I wrote something that adjusts the python path, which
I use to wrap the master config. That just looks up the zorg path relative from
the master.cfg file. I don’t know how portable that is, but at least it is not a
hard coded path to the users home dir...
Yes that does sound like a better option. If I find time I'll write a
patch for this.
> It would be really handy to have a simple single master/slave config
template for prototyping.  What might make sense is another config next to
smooshlab, llvmlab etc, that has a simple local config.  Everything on
localhost, no emails etc.  Then you could work on the one or two zorg builders
you want to muck with, then finally add your builder to the production configs.
It would be nice if the build master in osuosl could be easily run on
localhost but that probably would greatly over complicate things so
it's probably best not to do that. So a separate master config
template for localhost is probably the better option.

Thanks,
Dan.

On 8 August 2014 00:57, Daniel Dunbar <daniel at zuster.org>
wrote:
> My $.02
>
>
> On Wed, Aug 6, 2014 at 3:52 PM, Dan Liew <dan at su-root.co.uk>
wrote:
>>
>> Hi All,
>>
>> Recent conversations [1][2] would suggest we need to rethink zorg or
>> at the very least improve the documentation.
>>
>> I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands
because it
>> seemed that they have contributed the most code to Zorg
>>
>> Organisation
>> ========>>
>> The current organisation of the Zorg repository doesn't make a huge
>> amount of sense from my perspective. There are two things that we
>> should be able to do with this code
>>
>> - Run the currently in use buildbot master.
>> - Run a builtbot master and slave on a local machine for testing.
>
>
> 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.
As was already suggested by Chris Matthews. A template master config
for running everything on localhost is probably the best solution. If
I find time I'll start working on it.

<snip>
>
>>
>> Either we need to make it so that the buildbot master
>> (/buildbot/osuosl/master) can operate in two modes (normal and
>> localhost testing) or we need to provide another buildbot master
>> configuration for localhost testing. I think this is what
>> ``buildbot/smooshlab`` is for but that code has not been touched in
>> ages and is probably dead (if it is dead, we should delete it).
>
>
> smooshlab was a different configuration, not just one for testing. It can
be
> removed.
Okay I'll remove this soon if Galina approves.

<snip>
>>
>>
>> * reload()
>>
>> I see lots of reload() all over the place. Why do we need these?
>> Surely if you do
>>
>> $ buildbot stop master
>> $ buildbot start master
>>
>> This would reload everything making uses of ``reload()`` pointless.
>
>
> 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.
>
> 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).
There already seems to be code for this in zorg (reload_all in
zorg/buildbot/util/reloading.py) but the osuosl isn't using it which
is a little weird.

The reload_all() implementation does seem a little bit over engineered
though. It has a cache and the ability to ignore certain modules. I'm
not convinced that it's really necessary.

I guess I could modify the osuosl configuration to use this function
and then I could clean up the code to remove all the reloads.
>>
>>
>> * KLEE stuff
>>
>> KLEE is no longer actively developed as part of LLVM so all this stuff
>> should be dropped from Zorg.
>
>
> Sure, I don't know of anyone using this.
Okay I'll remove this.

>> * Builders
>>
>> There are lots of python modules in ``zorg/zorg/buildbot/builders``.
>> These are Factories, not builders so why do they have ``Builder`` in
>> their name and are in the "builders" folder? This is
unnecessarily
>> confusing.
>
>
> Yes, renaming this would make sense.
Okay I'll write a patch for this.
>>
>> * llvmlab, osuosl, smooshlab?
>>
>> Not sure those names are particularly helpful. I suspect ``smooshlab``
>> will probably be removed entirely and I suspect osuosl ought to be
>> renamed. I'm not sure if we need to keep any of the llvmlab stuff.
>
>
> llvmlab -- instance on lab.llvm.org
> osuosl -- old place we used to run buildbots
> smooshlab -- an internal setup that doesn't need to remain in the zorg
repo
>
The naming for llvmlab and osuosl seems a little messed up. AFAICT the
osuosl folder contain the config used by http://lab.llvm.org:8011/

Thanks,
Dan.