[Opensim-dev] Performance issue :S

Charles Krinke cfk at pacbell.net
Wed Aug 27 19:20:37 UTC 2008


Be it alpha, beta or zeta, OSGrid desires to facilitate testing in a number of different scenarios. So, without getting too hung up on the greek letters, I would say that I generally agree with you Mo.

As I look at it, the UGAIM on OSGrid has the greatest impact. So updating the UGAIM in a conservative manner more analogous to your item 4 is to our mutual advantage.

The plazas, both Windows and Linux are next. In general, we have it within our power to declare plazas updated either conservatively like the UGAIM or more aggessively to svn trunk at our perception of the desires and needs of the core developers.

So, the plazas can be considered either item 3 or 4 at times and this changes depending on the momentum of the project on a daily basis.

Individual regions that are not plazas then become items 1 and 2. These could be considered as unit tests or mini-acceptance tests to determine if a plaza (or plazas) should be updated depending on whether the current issues are windows-centric, linux-centric, or agnostic.

So, I believe that we can get there from here. There are differences in perceptions amongst the various players, but I think we have a good chance with OSGrid to continue blazing a trail and perhaps this is the time to start more formalizing update strategies. Or, at least, making sure that the participants understand and can use the update strategy, which I admit, is a bit dynamic at times.

Charles



----- Original Message ----
From: Mo Hax <imohax at gmail.com>
To: opensim-dev at lists.berlios.de
Sent: Wednesday, August 27, 2008 10:47:36 AM
Subject: Re: [Opensim-dev] Performance issue :S


Well, in the normal software development cycle in most big shops there are different levels of test. They get called different things by different shops but they boil down to the following levels (forgive the obvious):

	1. Testing by the developer of a specific function during development (ex: unit testing)

	2. Testing by the development and/or test team of the new function as it integrates with the overall project (ex: integration, alpha)

	3. Testing by users themselves or a test team focused on user acceptance criteria (ex: beta, user-acceptance)

	4. Post release testing in the 'production environment' (ex: production)

It seems your suggested use of OSGrid fits into either level 3 or level 4. My only point really was that perhaps we want to catch some potentially grid-affecting bugs that only show up in a grid environment before they hit what I am assuming is a 'production environment' in the OSGrid. SL accomplishes this in part with one or more Beta grid releases where people bang on stuff before it goes into SL production. Even then, as we well know, they miss stuff.

So I guess my suggestion is to either 

	* Call out OSGrid clearly as a 'beta' grid for opensim so people do not expect anything close to production stabilityor

	* Actually create a 'beta' OSGrid that is marked as such in any presentation materials leaving OSGrid hopefully at a more production level of stabilityI know this whole conversation might be premature because OpenSim itself is still clearly alpha software. But thinking about the test and release process is a good topic to start now. I share the frustrations of many opensim users when one function is added only to have another break. Concepts like 'regression testing' are still largely absent from what I see of the project mostly due to lack of resources and motivation, the very reason the smart folk at Linden may well have overlooked testing for so long. 

In my spare time (OpenSim is still not a 'day' job for me) I am focused more on creating and organizing stock content submissions at the moment, but I would love to continue help with testing as well. The testers really should not be the developers, so in that sense OSGrid seems like a good start.

Mo


On Wed, Aug 27, 2008 at 11:52 AM, Charles Krinke <cfk at pacbell.net> wrote:

Dear Mo:

Could you amplify and describe what you mean by a "staging testing environment like the SL Beta grid has served" so that we (or perhaps just I if everyone else knows) can understand what you mean.
Charles



----- Original Message ----
From: Mo Hax <imohax at gmail.com>
To: opensim-dev at lists.berlios.de
Sent: Wednesday, August 27, 2008 8:20:04 AM
Subject: Re: [Opensim-dev] Performance issue :S


I would agree that using a grid that is used provides the most motivated testing environment.

On the other hand, I haven't read anything about the need of a staging test environment, like the SL Beta grid has served.


On Wed, Aug 27, 2008 at 10:39 AM, Charles Krinke <cfk at pacbell.net> wrote:

One of the main goals of OSGrid is to provide a consistent testing environment with a variety of known and controlled configurations.

In general, the plazas are the most known and controlled and a number of developers have access to the plaza consoles whenever they wish.

There are regions that I and others have setup that represent various use cases. Things such as:

Yang - One region, one server, reasonable RAM, Linux, DSL from a home
'Moons' - Four regions running on one OpenSim.exe instance in Linux, DSL from a home
Celt - Small VPS (256MByte RAM) in colo in the UK

These just represent a small sample. They all get reasonable traffic and the plazas, both LinuxPlazas (Wright, Lbsa) and the WindowsPlazas (Zaius, Bade, SeaPrior, Teravus) have very significant traffic, if not the most traffic of any existing OpenSim regions on any grids.

In general, we are encouraging folks to test and report with the latest secondlife.com official client, but there are folks testing with a variety of clients.

So, we already have a system testing environment in place.

I would urge us to define via wiki or mantis a few recipes for regression tests and take advantage of the hundreds of folks logging into these and other regions each day. 

Or, one could consider some bot testing using the regions setup for testing Opensim. That certainly is another reasonable action.

Charles

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080827/37b781f3/attachment-0001.html>


More information about the Opensim-dev mailing list