Buildfarm build_test script on an embedded device.

Andrew Bartlett abartlet at samba.org
Tue Oct 4 20:54:54 MDT 2011


On Tue, 2011-10-04 at 21:37 -0500, Christopher R. Hertel wrote:
> Matthieu Patou wrote:
> > Hello Chris,
> > 
> > 
> >> Dan Shearer wrote:
> >>> On Sun, Oct 02, 2011 at 11:06:50AM -0500, Christopher R. Hertel wrote:
> >>>
> >>>> The device is a Seagate Dockstar.  It has 128MB of RAM soldered onto
> >>>> the
> >>>> mainboard, and I have a 2GB swap partition allocated on the
> >>>> USB-attached
> >>>> 2.5" SATA drive (less than 512M of which is in use).  Yes, that'll
> >>>> be slow.
> >>>>   I expect that.
> >>> I see your point, it's good to try all tests on a resource-constrained
> >>> machine no matter how slow. Embedded is an important target for S4.
> >>>
> >>> build.samba.org doesn't give an indication of the size of the hosts: I
> >>> wonder what the smallest machine is. ( I just started 'make test' on a
> >>> tiny x86 machine to see what will happen.)
> >> Almost 18 hours now...
> > I think we need to taillor a script for such platforms as make test
> > starts something like 6 or 7 samba DC in order to test different forest
> > level and things like 2nd DC ...
> > This takes a lot of memory so you are basically swapping all the time.
> > 
> > Try the following patch, it should try to only do tests for 1 DC
> > environment.
> 
> Matthieu,
> 
> The patch you provided for build_test.fns did not quite match the file, but
> I think I have applied it correctly manually.
> 
> I am running your modified script now (just started it).  I will let you
> know how long it takes.  I can also provide the logs, if you are interested.

Chris,

I'm going to cut this off now, to save you spending any more time on
this.

I'm not going to accept this machine into the build farm.  There are
other ways we can help ensure that this class of device works well with
Samba, but the build farm isn't one of them.

For a device to be a useful member of the build farm, it must:
 - return results in a reasonable period of time
 - not suffer serious resource constraints
 - be different enough to other platforms or a popular target.

I think we should support devices this small, for small workloads, but
the Samba build process is not one of these, and the test process is
certainly not one of these.  

To get better support for Samba on your dockstar, we should instead
ensure that an Arch Linux x64 machine is in the build farm, and if a
sufficiently fast and well-resourced host can be found, that an emulated
Arch Linux ARM machine is in the build farm.  The will help return
errors that developers can reproduce in a local VM (eg their python
insanity) and look at ARM portability issues.  

Developers already face a minimum 1.5 hour wait to get changes into
master, and then the clock starts on all the build farm hosts.  The fast
hosts pick up the compile and test job, and return it in around 2 hours,
leaving at most 2 'try and fix $random_os' attempts per day.  If your
box takes 14 hours to run, then fixing it without local access is just
completely impractical.  

We have had slow or 'only once per day' machines in the build farm
before, and fixing them even for simple errors has proved incredibly
tedious.  

I do apologise for encouraging you to take this on, and for the time you
have spent.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list