[Qemu-devel] Buildbot for qemu.git/master

[Qemu-devel] Buildbot for qemu.git/master

[Stefan Hajnoczi]

Occassionally a commit that breaks the build gets merged into
qemu.git/master.  Build testing manually across all host platforms is
not feasible for most developers.  Remember we cover 32- and 64-bit
x86 Linux, Windows, and other host platforms.  There are factors like
compile time but the main problem is that few have access to all host
platforms.

This can be solved with automated builds.  If a build fails, the
mailing list or maintainers are notified.  This doesn't excuse
developers from build testing on platforms they have access to, but it
helps reduce the window of time between a broken commit going in and
it being noticed.

Buildbot is a continuous integration system that can be used to guard
qemu.git/master.  For details see
http://trac.buildbot.net/wiki/AboutBuildbot.

If there is a host platform you care about, please consider running a
buildslave.  A buildslave is a machine capable of performing automated
builds and reporting results.  Buildslaves do not require public IP
addresses and it's up to you whether you want to run it all the time
or not.

I'm volunteering to set up and maintain a buildbot for
qemu.git/master.  I will send out a link to the build status page once
it has been set up.

Daniel: I believe you run a buildbot for KVM.  Are you willing to
extend that setup to qemu.git/master?  I wanted to ask in case it
makes sense to combine the two.

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

Here is the buildbot.  It currently has a debian-x86_64 slave building
qemu.git/master every 24 hours:
http://buildbot.vmsplice.net/

Failure notification emails are not being sent to qemu-devel yet.  I
will do that in a few days unless there are objections.

How to add buildslaves for the platforms you care about
=======================================================

I have CCed folks who may be interested in adding buildslaves (Linux
i386, Windows, Mac OS X, etc).

You can add buildslaves to guard host platforms you care about.  The
buildslave can be a physical machine or VM.  It does not need a static
IP address or public incoming TCP ports.  It doesn't need to run all
day either.  If you have an old machine sitting around or capacity to
host a VM, it can probably be used as a buildslave.

It must be capable of compiling QEMU and you are encouraged to install
optional build dependencies to maximize code coverage.

Security: Buildslaves receive their commands from the buildmaster
server.  By running a buildslave you are trusting the buildmaster
administrator with executing shell commands on the buildslave.
Consider running buildslaves in VMs, containers/jails, or dedicated
machines for isolation.

1. Email the details of your buildslave's host platform to
stefanha@gmail.com.  You will receive a response with the buildmaster
connection details.
2. Create an unprivileged user account for the buildslave and switch
to that account.
3. Test that QEMU builds:
 git clone git://git.qemu.org/qemu.git
 cd qemu
 ./configure && make
4. Install buildbot and run "buildbot create-slave qemu $master $name
$passwd" using your $master, $name, and $passwd connection details.
5. Edit qemu/info/host and qemu/info/admin.
6. Start the buildslave with "twistd --no_save -y buildbot.tac".
Consider running this automatically after reboot so your buildslave
comes back up.
7. Check to see that your buildslave has appeared:
http://buildbot.vmsplice.net/buildslaves

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Daniel Gollub]

[-- Attachment #1: Type: Text/Plain, Size: 849 bytes --]

On Saturday, February 05, 2011 05:36:11 pm Stefan Hajnoczi wrote:
> Daniel: I believe you run a buildbot for KVM.  


Thats correct.


> Are you willing to
> extend that setup to qemu.git/master?  I wanted to ask in case it
> makes sense to combine the two.

Sure. I also planned to provide this service in future.

How do you want to combine this service?
Share buildslave and merge the build-master?

Actually the buildbot configuration for qemu-kvm.git and qemu.git should be 
quite similar. We could also provide testing different qemu branches if you 
like.





-- 
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970 
Mail: gollub@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 8:30 AM, Daniel Gollub <gollub@b1-systems.de> wrote:
> How do you want to combine this service?
> Share buildslave and merge the build-master?
>
> Actually the buildbot configuration for qemu-kvm.git and qemu.git should be
> quite similar. We could also provide testing different qemu branches if you
> like.

I have a buildmaster at buildbot.vmsplice.net.  I could share my
master.cfg with you so that you can take over and merge it into your
KVM buildmaster.  Then I would take my buildmaster offline.

The following builders are interesting:
 * Host platforms: 32- and 64-bit x86 Linux, Windows, *BSD, Mac OS X and others
 * Tests: qemu-iotests and other automated test suites

This depends on volunteers contributing buildslaves.  So far there are
debian-x86_64 and debian-i386 builders.  Automated test suites are not
yet running.

Both the qemu.git and qemu-stable-0.14.git master branches are interesting.

If this sounds good to you then I'll send over the master.cfg and can
add a debian-x86_64 buildslave to your buildmaster.  If this is more
effort than you have time for, no worries, I'm also happy to maintain
the QEMU buildbot.

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 05.02.2011, at 21:32, Stefan Hajnoczi wrote:

> Here is the buildbot.  It currently has a debian-x86_64 slave building
> qemu.git/master every 24 hours:
> http://buildbot.vmsplice.net/

This is great - thank you! I'll try to get some ppc and s390x VMs set up to run this. Do you have any plans to also integrate actual testing of the compiled code?


Alex

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 1:00 PM, Alexander Graf <agraf@suse.de> wrote:
>
> On 05.02.2011, at 21:32, Stefan Hajnoczi wrote:
>
>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>> qemu.git/master every 24 hours:
>> http://buildbot.vmsplice.net/
>
> This is great - thank you! I'll try to get some ppc and s390x VMs set up to run this. Do you have any plans to also integrate actual testing of the compiled code?

Cool :).  Yes testing can be added after build.  Are there specific
automated tests you're thinking of?

I plan to add qemu-iotests.

Perhaps the kvm-autotest folks want to contribute a buildslave?  I
have CCed Lucas Meneghel Rodrigues.

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 07.02.2011, at 15:36, Stefan Hajnoczi wrote:

> On Mon, Feb 7, 2011 at 1:00 PM, Alexander Graf <agraf@suse.de> wrote:
>> 
>> On 05.02.2011, at 21:32, Stefan Hajnoczi wrote:
>> 
>>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>>> qemu.git/master every 24 hours:
>>> http://buildbot.vmsplice.net/
>> 
>> This is great - thank you! I'll try to get some ppc and s390x VMs set up to run this. Do you have any plans to also integrate actual testing of the compiled code?
> 
> Cool :).  Yes testing can be added after build.  Are there specific
> automated tests you're thinking of?

Nothing specific, just making sure that basic device emulation works and maybe try to run some linux-user binaries too.

> I plan to add qemu-iotests.

That's certainly useful too, yes :).


Alex

Re: [Qemu-devel] Buildbot for qemu.git/master

[Richard W.M. Jones]

On Sat, Feb 05, 2011 at 04:36:11PM +0000, Stefan Hajnoczi wrote:
> Occassionally a commit that breaks the build gets merged into
> qemu.git/master.  Build testing manually across all host platforms is
> not feasible for most developers.  Remember we cover 32- and 64-bit
> x86 Linux, Windows, and other host platforms.  There are factors like
> compile time but the main problem is that few have access to all host
> platforms.

Is there a plan to test that the build minimally functions as well?
Could be as simple as running:

./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
  -kernel /boot/vmlinuz -nodefconfig -nographic -nodefaults -no-reboot \
  -m 500 -device virtio-serial -serial stdio -append 'panic=1 console=ttyS0'

and just checking that it doesn't hang and does print out some
expected message near the end ("Kernel panic - not syncing: VFS:
Unable to mount root fs" might be a good one :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

Re: [Qemu-devel] Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 3:02 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
>
> On Sat, Feb 05, 2011 at 04:36:11PM +0000, Stefan Hajnoczi wrote:
>> Occassionally a commit that breaks the build gets merged into
>> qemu.git/master.  Build testing manually across all host platforms is
>> not feasible for most developers.  Remember we cover 32- and 64-bit
>> x86 Linux, Windows, and other host platforms.  There are factors like
>> compile time but the main problem is that few have access to all host
>> platforms.
>
> Is there a plan to test that the build minimally functions as well?
> Could be as simple as running:
>
> ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
>  -kernel /boot/vmlinuz -nodefconfig -nographic -nodefaults -no-reboot \
>  -m 500 -device virtio-serial -serial stdio -append 'panic=1 console=ttyS0'
>
> and just checking that it doesn't hang and does print out some
> expected message near the end ("Kernel panic - not syncing: VFS:
> Unable to mount root fs" might be a good one :-)

I'm not aware of a plan but if someone steps up with tests and
machines that can serve as buildslaves, then the infrastructure can
support it.

I believe KVM-Autotest does that and much more for KVM x86 but have
never run it myself:
http://www.linux-kvm.org/page/KVM-Autotest

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 2:44 PM, Alexander Graf <agraf@suse.de> wrote:
> On 07.02.2011, at 15:36, Stefan Hajnoczi wrote:
>> On Mon, Feb 7, 2011 at 1:00 PM, Alexander Graf <agraf@suse.de> wrote:
>>> This is great - thank you! I'll try to get some ppc and s390x VMs set up to run this. Do you have any plans to also integrate actual testing of the compiled code?
>>
>> Cool :).  Yes testing can be added after build.  Are there specific
>> automated tests you're thinking of?
>
> Nothing specific, just making sure that basic device emulation works and maybe try to run some linux-user binaries too.

Michael Roth recently posted the "qtest" patchset which begins to
enable device model testing:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg54191.html

It goes in the direction of making emulated devices (like AHCI)
testable without running an actual guest.  Your test code runs in a
native-code vcpu thread and can interact with the device model via
mmio, pio, DMA, and interrupts.

If you are interested please check out Michael's email thread on qtest.

Or if you meant tests that run small guests to check that networking,
disk, etc still work, then I think KVM-Autotest is what exists today.

Stefan

Re: [Qemu-devel] Re: Buildbot for qemu.git/master

[Luiz Capitulino]

On Sat, 5 Feb 2011 20:32:06 +0000
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> Here is the buildbot.  It currently has a debian-x86_64 slave building
> qemu.git/master every 24 hours:
> http://buildbot.vmsplice.net/

Nice, what about also building maintainers' branches, such as the block one?

Re: [Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Mon, Feb 7, 2011 at 7:03 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Sat, 5 Feb 2011 20:32:06 +0000
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>> qemu.git/master every 24 hours:
>> http://buildbot.vmsplice.net/
>
> Nice, what about also building maintainers' branches, such as the block one?

That's a nice idea because it catches broken commits *before* they
reach mainline.

The trade-off is that the number of people you trust to run code on
your buildslave is increased to include subsystem maintainers.  I
think that's acceptable but want to be upfront about it.

The other consequence is that buildslaves have more work to do.
That's great if this is a dedicated machine but not so great if the
buildslave also shares resources with other applications.  If
volunteers find their buildslaves are too busy we can split off
"light" builders that don't run as many builds/tests.

Stefan

Re: [Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 07.02.2011, at 22:18, Stefan Hajnoczi wrote:

> On Mon, Feb 7, 2011 at 7:03 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
>> On Sat, 5 Feb 2011 20:32:06 +0000
>> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> 
>>> Here is the buildbot.  It currently has a debian-x86_64 slave building
>>> qemu.git/master every 24 hours:
>>> http://buildbot.vmsplice.net/
>> 
>> Nice, what about also building maintainers' branches, such as the block one?
> 
> That's a nice idea because it catches broken commits *before* they
> reach mainline.
> 
> The trade-off is that the number of people you trust to run code on
> your buildslave is increased to include subsystem maintainers.  I
> think that's acceptable but want to be upfront about it.

If they're subsystem maintainers that Anthony accepts pull requests from, it's just as good, no?

> The other consequence is that buildslaves have more work to do.
> That's great if this is a dedicated machine but not so great if the
> buildslave also shares resources with other applications.  If
> volunteers find their buildslaves are too busy we can split off
> "light" builders that don't run as many builds/tests.

I wouldn't worry about that too much :).


Alex

[Qemu-devel] Re: Buildbot for qemu.git/master

[Lucas Meneghel Rodrigues]

On Mon, 2011-02-07 at 14:36 +0000, Stefan Hajnoczi wrote:
> On Mon, Feb 7, 2011 at 1:00 PM, Alexander Graf <agraf@suse.de> wrote:
> >
> > On 05.02.2011, at 21:32, Stefan Hajnoczi wrote:
> >
> >> Here is the buildbot.  It currently has a debian-x86_64 slave building
> >> qemu.git/master every 24 hours:
> >> http://buildbot.vmsplice.net/
> >
> > This is great - thank you! I'll try to get some ppc and s390x VMs set up to run this. Do you have any plans to also integrate actual testing of the compiled code?
> 
> Cool :).  Yes testing can be added after build.  Are there specific
> automated tests you're thinking of?
> 
> I plan to add qemu-iotests.
> 
> Perhaps the kvm-autotest folks want to contribute a buildslave?  I
> have CCed Lucas Meneghel Rodrigues.

I am not too familiar with buildbot myself, so I went to the buildbot
page and read some of the documentation. KVM autotest has its own kvm
build code, and we do run jobs that build qemu.git and run some sanity
checking on it (ie, install some guest OSs and boot the vms, as well as
other simple tests).

If I understood correctly, a build slave is a machine where the
compilation happens and then the build master can report appropriately
upon failure/pass. The way the kvm autotest jobs are setup nowadays
provides just that, an environment where the latest qemu-kvm.git and
qemu.git are built on a timely basis (every 48 hours) and then the
actual testing of the compiled code happens.

Of course, maybe there's a way to trigger kvm autotest jobs upon
successful buildbot builds, and if that is possible, I'd be happy to
help setting up a test environment that'd accomplish public automated
testing of qemu.git. Just let me know how I can do it.

Cheers!

Lucas

Re: [Qemu-devel] Buildbot for qemu.git/master

[Lucas Meneghel Rodrigues]

On Mon, 2011-02-07 at 15:15 +0000, Stefan Hajnoczi wrote:
> On Mon, Feb 7, 2011 at 3:02 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
> >
> > On Sat, Feb 05, 2011 at 04:36:11PM +0000, Stefan Hajnoczi wrote:
> >> Occassionally a commit that breaks the build gets merged into
> >> qemu.git/master.  Build testing manually across all host platforms is
> >> not feasible for most developers.  Remember we cover 32- and 64-bit
> >> x86 Linux, Windows, and other host platforms.  There are factors like
> >> compile time but the main problem is that few have access to all host
> >> platforms.
> >
> > Is there a plan to test that the build minimally functions as well?
> > Could be as simple as running:
> >
> > ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
> >  -kernel /boot/vmlinuz -nodefconfig -nographic -nodefaults -no-reboot \
> >  -m 500 -device virtio-serial -serial stdio -append 'panic=1 console=ttyS0'
> >
> > and just checking that it doesn't hang and does print out some
> > expected message near the end ("Kernel panic - not syncing: VFS:
> > Unable to mount root fs" might be a good one :-)
> 
> I'm not aware of a plan but if someone steps up with tests and
> machines that can serve as buildslaves, then the infrastructure can
> support it.
> 
> I believe KVM-Autotest does that and much more for KVM x86 but have
> never run it myself:
> http://www.linux-kvm.org/page/KVM-Autotest

Yes, it is, our current sanity jobs are much more comprehensive than
what was described. They currently:

* Install guests (RHEL6 and Win7 these days) on a number of option
scenarios (virtio, ide, large memory pages, etc)
* Boot them, making sure they are alive by performing remote login on
the guests
* Verify the hardware seen by the guest OS matches what we provided on
the command line
* Shut down the guests

Of course, we have other types of functional jobs, but just illustrating
what the framework can do today. It is possible to:

* Install a specific kernel build on the guest
* Choose what version of qemu user space to use for the testing

And we have some functionality to provision hosts using cobbler, that
will be sent upstream soon. It's a lot of automation infrastructure at
our service.

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Tue, Feb 8, 2011 at 2:29 AM, Lucas Meneghel Rodrigues <lmr@redhat.com> wrote:
> If I understood correctly, a build slave is a machine where the
> compilation happens and then the build master can report appropriately
> upon failure/pass. The way the kvm autotest jobs are setup nowadays
> provides just that, an environment where the latest qemu-kvm.git and
> qemu.git are built on a timely basis (every 48 hours) and then the
> actual testing of the compiled code happens.

Yes, buildslaves are machines that execute builds and tests.  They
report the results back to the buildmaster which provides a public web
interface, breakage notifications, and central administration.

> Of course, maybe there's a way to trigger kvm autotest jobs upon
> successful buildbot builds, and if that is possible, I'd be happy to
> help setting up a test environment that'd accomplish public automated
> testing of qemu.git. Just let me know how I can do it.

Public automated qemu.git autotest would be excellent.  To be honest I
haven't had much visibility of KVM-Autotest myself as a QEMU/KVM
developer.  I suspect many others haven't either but there are big
benefits if we can change this.  By running your automated tests on
qemu.git in public we'll catch bugs earlier.

Do you want to add KVM-Autotest buildslave(s) or are you looking for
something like a HTTP POST notifier that pings you about new qemu.git
HEADs to test?

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Daniel Gollub]

[-- Attachment #1: Type: Text/Plain, Size: 3268 bytes --]

Hi Stefan,

On Monday, February 07, 2011 10:34:03 am Stefan Hajnoczi wrote:
> I have a buildmaster at buildbot.vmsplice.net.  I could share my
> master.cfg with you so that you can take over and merge it into your
> KVM buildmaster.  Then I would take my buildmaster offline.


Ok. This would be very interesting. You can find ours here:
http://people.b1-systems.de/~gollub/buildbot/qemu-master-1297163676.cfg

Quick attempt from porting our qemu-kvm.git buildbot configuration to 
qemu.git. qemu-stable-0.14.git is  currently missing. But should be easy once 
it got added as mirror-branch in qemu.git (in case this is still planned?).


The qemu.git buildbot is running:
http://buildbot.b1-systems.de/qemu/

(The qemu.git repo seems to be slow right now couldn't get a full git-fetch 
without timeout yet)


This buildbot configuration for qemu.git is running build-tests for x86_64 and 
i386. And build-tests out-of-tree builds, as well as build with: --disable-kvm 
and a plain: ./configure; make


We're still running a quite old version of buildbot. But i plan to upgrade 
this one very soon. Since this version doesn't support Git-Poller yet, and 
relys on a git-post-commit hook. (Which cause for qemu-kvm.git and kvm.git 
some trouble due to git.kernel.org syncing issues which were delayed)

> 
> The following builders are interesting:
>  * Host platforms: 32- and 64-bit x86 Linux, Windows, *BSD, Mac OS X and
> others * Tests: qemu-iotests and other automated test suites

The qemu-kvm.git and the qemu.git have currently buildslaves for 32 and 64bit 
x86 Linux.

For kvm.git we added few month ago cross-compiling to provide build-testing 
for different architectures. Do you think this would be helpful for qemu.git 
as well?

http://buildbot.b1-systems.de/kvm/waterfall

One x86_64 builder provies cross-compiling for:
x86_64, i386, s390, ia64, ppc44x, ppc64





> 
> This depends on volunteers contributing buildslaves.

This would be great if you and other would volunteer to contribute some more 
buildslaves. Especially for different platforms which are not covered yet.


> So far there are
> debian-x86_64 and debian-i386 builders.  Automated test suites are not
> yet running.


Should be easy to add. Just let me know which one we should add.
I'll looking into those which got already mentioned on the list.

 
> Both the qemu.git and qemu-stable-0.14.git master branches are interesting.
> 
> If this sounds good to you then I'll send over the master.cfg and can
> add a debian-x86_64 buildslave to your buildmaster.  If this is more
> effort than you have time for, no worries, I'm also happy to maintain
> the QEMU buildbot.

Would be great if we could join our efforts. I'll great later a git repo to 
maintain the different buildbot configuration - so people can easily extended 
the configuration and add more tests or add different buildflags. And we just 
merge those in our buildbot master.


Best Regards,
Daniel


-- 
Daniel Gollub
Linux Consultant & Developer
Mail: gollub@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[Qemu-devel] Re: Buildbot for qemu.git/master

[Lucas Meneghel Rodrigues]

On Tue, 2011-02-08 at 09:23 +0000, Stefan Hajnoczi wrote:
> Public automated qemu.git autotest would be excellent.  To be honest I
> haven't had much visibility of KVM-Autotest myself as a QEMU/KVM
> developer.  I suspect many others haven't either but there are big
> benefits if we can change this.  By running your automated tests on
> qemu.git in public we'll catch bugs earlier.
> 
> Do you want to add KVM-Autotest buildslave(s) or are you looking for
> something like a HTTP POST notifier that pings you about new qemu.git
> HEADs to test?

The biggest challenge is to have machines publicly accessible to perform
testing, right now we use the machines of our internal laboratory to
perform those tests. About notifiers of new git commits, I am unsure
whether we should test every and each git commit, since even sanity test
takes a while (the typical 84 tests of a sanity job take around 3 hours
to execute on fast machines). Of course, we might improve our ability to
perform parallel testing, or perhaps reducing test scope.

Bottom line, the thing here is to have available hardware externally
accessible, just like the buildbot that was setup, mentioned previously
on this thread.

[Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 08.02.2011, at 12:23, Lucas Meneghel Rodrigues wrote:

> On Tue, 2011-02-08 at 09:23 +0000, Stefan Hajnoczi wrote:
>> Public automated qemu.git autotest would be excellent.  To be honest I
>> haven't had much visibility of KVM-Autotest myself as a QEMU/KVM
>> developer.  I suspect many others haven't either but there are big
>> benefits if we can change this.  By running your automated tests on
>> qemu.git in public we'll catch bugs earlier.
>> 
>> Do you want to add KVM-Autotest buildslave(s) or are you looking for
>> something like a HTTP POST notifier that pings you about new qemu.git
>> HEADs to test?
> 
> The biggest challenge is to have machines publicly accessible to perform
> testing, right now we use the machines of our internal laboratory to
> perform those tests. About notifiers of new git commits, I am unsure
> whether we should test every and each git commit, since even sanity test
> takes a while (the typical 84 tests of a sanity job take around 3 hours
> to execute on fast machines). Of course, we might improve our ability to
> perform parallel testing, or perhaps reducing test scope.
> 
> Bottom line, the thing here is to have available hardware externally
> accessible, just like the buildbot that was setup, mentioned previously
> on this thread.

Can you have some machines wired up externally? I could certainly try to get a ppc machine set up on an externally reachable network if that's any help. S390 might be a bit more tricky...


Alex

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Tue, Feb 8, 2011 at 11:23 AM, Lucas Meneghel Rodrigues
<lmr@redhat.com> wrote:
> Bottom line, the thing here is to have available hardware externally
> accessible, just like the buildbot that was setup, mentioned previously
> on this thread.

Remember the buildslaves don't need to have incoming TCP ports open
and they don't need an external IP.  They just need to be able to
connect to git repos and the buildmaster as clients.

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Stefan Hajnoczi]

On Tue, Feb 8, 2011 at 11:14 AM, Daniel Gollub <gollub@b1-systems.de> wrote:
> On Monday, February 07, 2011 10:34:03 am Stefan Hajnoczi wrote:
>> I have a buildmaster at buildbot.vmsplice.net.  I could share my
>> master.cfg with you so that you can take over and merge it into your
>> KVM buildmaster.  Then I would take my buildmaster offline.
>
>
> Ok. This would be very interesting. You can find ours here:
> http://people.b1-systems.de/~gollub/buildbot/qemu-master-1297163676.cfg
[...]
>> Both the qemu.git and qemu-stable-0.14.git master branches are interesting.
>>
>> If this sounds good to you then I'll send over the master.cfg and can
>> add a debian-x86_64 buildslave to your buildmaster.  If this is more
>> effort than you have time for, no worries, I'm also happy to maintain
>> the QEMU buildbot.
>
> Would be great if we could join our efforts. I'll great later a git repo to
> maintain the different buildbot configuration - so people can easily extended
> the configuration and add more tests or add different buildflags. And we just
> merge those in our buildbot master.

Excellent.  I will respond in detail later, but I agree and will send
you my master.cfg so you can take over the buildmaster.

Here's the todo list I've collected from this thread:
 * Send Stefan's master.cfg to Daniel
 * Collect subsystem tree repourls
 * Add Solaris 11 Express buildslave for Palle Lyckegaard
 * Email lmr with steps for setting up KVM-Autotest buildslave

Once the dust has settled I volunteer to write things up on the qemu.org wiki.

Stefan

[Qemu-devel] Re: Buildbot for qemu.git/master

[Alexander Graf]

On 08.02.2011, at 12:28, Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Tue, Feb 8, 2011 at 11:23 AM, Lucas Meneghel Rodrigues
> <lmr@redhat.com> wrote:
>> Bottom line, the thing here is to have available hardware externally
>> accessible, just like the buildbot that was setup, mentioned previously
>> on this thread.
> 
> Remember the buildslaves don't need to have incoming TCP ports open
> and they don't need an external IP.  They just need to be able to
> connect to git repos and the buildmaster as clients.

Yes, but you realy want to make sure that the buildbot code has no access to your company's internal network ;).


Alex

>