[Swift-devel] testing

[Michael Wilde]

On 3/18/09 5:29 AM, Ben Clifford wrote:
> On Tue, 17 Mar 2009, Mihael Hategan wrote:
> 
>> 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.
> 
> Mats can probably make comment on what people in OSG are going to say.
> 
> My sense is:
>  i) coasters as a general concept is fine - the big VOs do stuff like that.
>  ii) running anything on the head nodes is bad
I agree in principle. The immediate issue is whether the load we place 
on head nodes will be light and not cause trouble, or whether it will be 
yet another obstacle for us. We need to cope with managed head nodes and 
their time limiter. I dont know that thats been tested yet.

Can coasters architecturally cope with no head node access, if we use a 
worker node for this function and it connects back to the submitting 
swift process? On the assumption that outbound connectivity from workers 
will be more commonly found than inbound?

>  iii) running anything through gram2 is bad - any base job submissions 
>   need to be through condor-g using its hybrid gram2+gridmanager system.

I agree, and was assuming that on OSG we would only use the new Condor 
provider, and run jobs in this manner.