Date: Thu, 20 Mar 2014 15:29:17 -0700 From: Craig Rodrigues <rodrigc@FreeBSD.org> To: "Wojciech A. Koszek" <wkoszek@freebsd.org> Cc: "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Subject: Re: Google Summer of Code 2014 question Message-ID: <CAG=rPVcLVkcnAXy1KnATagvCdqPpOd6NDq5=KRWXMp%2B4BO7UpQ@mail.gmail.com> In-Reply-To: <20140320213848.GU37327@FreeBSD.org> References: <532A0DE6.2020801@pitt.edu> <201403201124.07472.jhb@freebsd.org> <CAG=rPVeD835zD=1aiL0i%2BTr2hqiM0kRQWLi%2Bx3dZd7P0Cgk6hQ@mail.gmail.com> <20140320213848.GU37327@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 20, 2014 at 2:38 PM, Wojciech A. Koszek <wkoszek@freebsd.org> wrote:
> DSL isn't a must here, I agree, but you'll be limited in testing otherwise.
> Unless some technology already has what I want, I suggested getting this
> functionality:
>
> vm0.cmd("ifconfig .....");
> vm1.cmd("ifconfig ....");
>
> vm0.cmd("ping vm1");
>
> vm0.register(function(data) {
> if (data =~ /*Not*/) {
> error();
> }
> });
For the above pseudo-code which you listed,
you've pretty much got that functionality in
existing automation tools like Puppet, SaltStack, Chef, etc.
For unit testing, Kyua is quite good, and people are writing lots of unit
tests for it, and even committing some of them directly to FreeBSD.
> Once this would work for VMs, I'd be interesting in proposing the creation
> of the physical infrastructure for continuous FreeBSD testing.
For the above item, we've already started putting that together. See:
http://wiki.freebsd.org/Jenkins and the presentation I gave on March 13.
At the next Devsummit in Ottawa, we want to talk about this further
and get people
who are interested in this topic to participate in the conversation:
https://wiki.freebsd.org/201405DevSummit/Jenkins
It would be interesting to get Raspberry PI hardware being tested
regularly as part of
continuous integration. We don't have Raspberry PI hardware available
in the FreeBSD
cluster, so someone who is interested would have to take the action item
to acquire the hardware and set things up so the hardware is integrated with
continuous integration/testing.
Looking at the SummerOfCode2014 ideas page, my opinion is that for this item:
https://wiki.freebsd.org/SummerOfCode2014#TEST-o-steron_for_FreeBSD_.28node.js.2FLua.29
-> has already been done with things like libvirt, which is being
ported to FreeBSD
by Roman Bogorodskiy. See:
http://empt1e.blogspot.com/2014/03/bhyve-in-libvirt.html
-> existing automation frameworks can already be used to send
remote commands to VM's
and for this item:
https://wiki.freebsd.org/SummerOfCode2014#CON-tinuous_INtegration_for_FreeBSD_aka_improved_TinderBox_.28node.js.2FLua.29
-> better Tinderbox systems already exist. Jenkins and Buildbot
are two commonly
available open source implementations.
-> the jenkins-admin team set up Jenkins (
http://jenkins.freebsd.org ) because we were familiar
it, and so far it seems to work well
My focus is to get existing software that people in the non-FreeBSD world have
developed to solve these types of problems, and get them up and
running in FreeBSD.
--
Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG=rPVcLVkcnAXy1KnATagvCdqPpOd6NDq5=KRWXMp%2B4BO7UpQ>