[Swift-devel] testing

[Mihael Hategan]

On Tue, 2009-03-17 at 12:04 -0500, Michael Wilde wrote:
> On 3/17/09 11:30 AM, Mihael Hategan wrote:
> > So I think that, at this point, if we're serious about running things
> > production-style on teragrid or osg, an appropriate testing effort is
> > required.
> 
> I agree.
> > 
> > In the past our hands were tied due to our inability to fix and deploy
> > gram issues on both those places. With the shift towards coasters and
> > local providers, we have, at least in theory, overcome the issue.
> 
> I think your new Condor provider provides the hopefully final missing piece.

There are the LSF and SGE providers still to be done ;)

> 
> > However, in order for it to also be in practice, we need to make sure
> > that things actually work, and that can only be done with testing or a
> > magic wand. I don't have the latter, so we'll have to do testing.
> 
> yes.
> 
> > There are probably a few issues still left to address, one of which is
> > to make sure that coasters are an acceptable way of running things on
> > OSG. I suspect this would require some negotiation with the right people
> > from OSG, and I don't know who those people are.
> 
> I do: Its Ruth, and several people in various working groups whose names 
> I can gather and send out. I'll make the initial contacts.

Ok.

> 
> What I need are test data from various scale runs that prove Swift is 
> fast, scalable, and "safe" (ie doesnt harm things).

This isn't in particular a swift issue, but a coaster issue. There is no
proof of safety, and swift being fast, scalable, and safe comes after
this testing, not before. But I would like to "negotiate" the ability
to:

- have one process on the head node, hopefully one that doesn't hog it.
- the ability to submit from the head node to the queuing system
directly (as if running qsub manually - something that isn't exactly
"the way" on OSG).