[sldev] Summarizing AWG/LL Open Grid Test Harness discussion & request for further discussion

[Lawson English]

Christian Scholz / Tao Takashi (SL) wrote:
> Hi!
>
> On Wed, May 7, 2008 at 9:11 AM, Enus Linden <enus at lindenlab.com> wrote:
>   
>> posted to https://wiki.secondlife.com/wiki/AWG_Test_Harness
>>
>>
>>  At the AWG meeting held April 29, we discussed what a test harness could
>> look like that would be used to test the agent-domain, rez-avatar, and
>> overall work being done implementing the open grid protocols. I'd like to
>> summarize, and continue the discussion on the mailing list, in-world, and on
>> the wiki. Chat log here:
>> http://wiki.secondlife.com/wiki/AWGroupies-2008-04-29
>>
>>  The goal wrt testing, is to build a test harness that enables testing of
>> published Open Grid protocols (see
>> http://wiki.secondlife.com/wiki/SLGOGP_Draft_1). The intent is not to test
>> SL or OpenSim (or gridX) themselves. Rather, the desire is to create a
>> framework where the implementations of the protocols can be tested
>> independent of environment. We plan to be able to test at the smallest
>> functional level possible, akin to unit testing, and to have the ability to
>> use the framework to sequence steps to enable state specific tests to be
>> run.
>>
>>  The longer term vision is essentially a client library, capable of
>> navigating the grid and interacting with the various hosts, sitting next to
>> a testing framework, happily running along telling us what works where, and
>> where something needs a little attention to work according to
>> specification...
>>
>>  Shorter term, how do we start?
>>
>>  Let's work on defining the test harness components (from the meeting):
>>  1. Login
>>  2. Caps (and while it's around the UDP pipe)
>>  3. Message Handlers (see chttp)
>>  4. Basic web server parts for the Agent, Region and grid bits (ideally a
>> snap in framework)
>>  5. Test framework
>>  6. Test data (I put this here, not really as a component of the harness,
>> more as a "i'm not telling you my test account's password and what are we
>> gonna do about it" thing)
>>     
>
> add reverse HTTP to it now ;-)
>
>   
>>  Python seems to be the flavor of choice here, with a requirement that it
>> accommodate non-python components as needed. The repository for the code is
>> proposed to be maintained by Linden Lab, distributed as an open source
>> export, under the Apache v2 License (see
>> http://opensource.org/licenses/apache2.0.php). The process and details here
>> are tentative, and need more attention...
>>     
>
> Open Source Export means that there is no direct SVN access possible?
> Because for regulat contributors
> I would find that easier.
>
> As for the framework itself I would propose to create a pluggable one
> where people might even be able
> to plugin test components without having access to the main source. I
> would propose the Zope Component
> Architecture here and can also quickly make an example of how it could
> work. It's basically a global registry.
> I would also encourage people to directly lay everything out as eggs.
> Using buildout would make sense here
> as well as people can then very easily setup their test sandbox. I can
> also demo/document all that.
> Plugins/tests could then also be made available through the cheeseshop.
>
>   
>>  There is plenty to be figured out obviously. How to start, who wants to
>> play, details are all tbd. My role is primarily intended as one who will
>> facilitate dialogue and contribute as much as possible, but this is intended
>> as a joint effort.
>>
>>  So, who wants to play?
>>     
>
> Apparently me, as I wanted to work on some agent domain stuff anyway
> and tests make sense then.
> (depending on time constraints though as alyways)
>
> cheers,
>
> Christian
>
>
>   
The login presence script on the wiki contains a generic UDP packet 
handler, though only a handful of packets are fully supported beyond 
being able to evaluate the packet header (just those needed to keep a 
"presence" on the grid).

The chat bot I've been working on since forever, handles even less 
robustly the EventQueueGet but that's mostly because I'm not sure what 
long-poll events need handling in the first place. Any UDP packet might 
need to be handled via the EventQueueGet handler, which functionality 
wold be trivial to extend via a generic packet assembler ala the LL 
viewer or libsl, but the less/ill/un-defined EventQUeueGet-only messages 
are a different story. There's no real documentation anywhere that I 
know of save in the source code of the LL viewer and the libsl. 
Regardless,  UDP and EventQueueGet handlers are trivial to implement. 
Functionality might be another story, of course.


On the topic of scale, I tested 300 separate Python scripts running a 
simple http faux-POST server as an avie remote command processor last 
night, just to see if the idea would be viable under a heavy load. Seems 
that it is since all 300 were able to process a few messages in less 
than a minute on a single dual G5 PowerMac purchased over 3 years ago, 
including startup/initialization/respond-to-POST/print-to-file/quit 
time. If we adopt the Zope control mechanism and use the test 
harness(es) as distributed Zope objects that might exist on any number 
of remote machines, we could, in theory, do a full stress test of any 
beta grid with as few as 10 to as many as one hundredK test harnesses 
running simultaneously on a few thousand machines, controlled by one or 
more servers dedicated to that control...

That last may seem a bit pie-in-the-sky-ish, but if we're serious about 
Zero's "scary numbers" of the open grid that's actually a rather minimal 
number  to get a feel for scaling of things like group IM, inventory 
management and even login.


Lawson