Date: Thu, 10 Jul 2014 11:21:54 -0400 From: "George Neville-Neil" <gnn@neville-neil.com> To: "Garrett Cooper" <yanegomi@gmail.com> Cc: "freebsd-testing@freebsd.org" <testing@freebsd.org>, net@freebsd.org Subject: Re: A new way to test systems in multiple machine scenarios... Message-ID: <F470785E-F01E-48D3-BF5C-2C5E38181A1D@neville-neil.com> In-Reply-To: <154F5C90-B0A5-41AD-ABBC-C7ECE1281D7D@gmail.com> References: <B8265086-6875-46A3-BE90-E286CD5066E2@neville-neil.com> <CAG=rPVfREbmv7W465B68HoU8_ig=Y2f_w9_-PL7f2T_bzeAyiQ@mail.gmail.com> <154F5C90-B0A5-41AD-ABBC-C7ECE1281D7D@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Jul 2014, at 4:56, Garrett Cooper wrote: > On Jul 6, 2014, at 9:06 PM, Craig Rodrigues <rodrigc@FreeBSD.org> = > wrote: > >> On Sat, Jul 5, 2014 at 8:04 PM, George Neville-Neil = >> <gnn@neville-neil.com> >> wrote: >> >>> Hi, >>> >>> I've coded up a system to allow you to control multiple other = >>> systems for >>> use in testing. >>> >>> https://github.com/gvnn3/conductor >>> >>> >> Cool! The architecture you have is similar to that of the SPECsfs >> benchmark test ( http://www.spec.org/sfs2008/ ) >> which involves a "coordinator node" and multiple "client nodes" which >> direct NFS network >> traffic towards a System Under Test (SUT). Garrett Cooper actually = >> set up >> the original testbed >> that I am using now at iXsystems. :) >> >> It would be cool to put together tools like Jenkins, Kyua, and = >> conductor to >> do more advanced testing >> of FreeBSD before the project puts out releases. > > Agreed. The only thing that I have some concern about is the = > reinventing of the wheel in python. multiprocessing Managers are one = > viable option that=E2=80=99s existed since python 2.6; there=E2=80=99s = a learning = > curve though, and you=E2=80=99ll run into problems with pickling some = > objects because the pickle protocol is far from complete (example: = > http://stackoverflow.com/questions/1816958/cant-pickle-type-instancemet= hod-when-using-pythons-multiprocessing-pool-ma = > ); you might run into this problems regardless because you=E2=80=99re = > serializing objects using pickle instead of using dill (or using a = > simpler serialization method like JSON). Fabric has a framework = > that=E2=80=99s nice to use if you have ssh capability. There are other = > frameworks that use twisted conch I think too (another library that = > implements ssh access). Yes, I learned quite a bit about pickling in writing this. Conductor = aims to be quite simple so I am hoping to avoid any crazy corner cases to do with pickling. > > Isilon has a framework they use, but it=E2=80=99s very customized to th= eir = > infrastructure and product assumptions and it=E2=80=99s in need of an = > overhaul :(. This, actually, is the problem I found. Lots of folks have partial = solutions that are either proprietary, internal, not read for prime time, not quite what we want, etc. etc. I = did get one private response of another system to look at as well. I basically did this as a stake in the ground around which to build = something we could possibly move forwards with. It's not a 100% solution but it's 80% of the solution to the = problem I run into 80% of the time. Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F470785E-F01E-48D3-BF5C-2C5E38181A1D>