[Swift-devel] Status of coasters

Michael Wilde wilde at mcs.anl.gov
Fri Feb 13 10:05:18 CST 2009


Stu, this would be a good thing to discuss through the UChicago OSG 
group. I can start that, and am cc'ing Rob Gardner to get it on the list 
of Globus-OSG things to track.

- Mike


 > But also, we want to have GRAM2 sites to start to use the SEG to remove
 > a significant portion of the GRAM2 scalability problem.  I think that
 > would be best and simplest solution to focus on.  Maybe we can start
 > with a site where you need more scalability and the admin would want to
 > work with us on that?

- Mike


On 2/13/09 9:58 AM, Stuart Martin wrote:
> On Feb 13, 2009, at Feb 13, 9:40 AM, Tim Freeman wrote:
> 
>> On Fri, 13 Feb 2009 09:32:43 -0600
>> Mihael Hategan <hategan at mcs.anl.gov> wrote:
>>
>>> On Fri, 2009-02-13 at 09:23 -0600, Michael Wilde wrote:
>>>>
>>>> On 2/13/09 9:17 AM, Mihael Hategan wrote:
>>>>> On Fri, 2009-02-13 at 08:59 -0600, Michael Wilde wrote:
>>>>>> -- Service submits via WS-GRAM. This should be tested, on sites 
>>>>>> whereWS-GRAM is working.
>>>>>> This woild use jobmanager=gt2:gt4:{pbs/condor/sge}, and needs to be
>>>>>> tested. For sites where WS-GRAM is not functional, I suggested we
>>>>>> consider configuring our own non-root WS-GRAM, ideally using
>>>>>> already-installed GT4 software, eg, from the OSG package on OSG 
>>>>>> and TG
>>>>>> sites where its installed. Mihael thought this would be considerable
>>>>>> work.
>>>>>
>>>>> Not as much the amount of work, but:
>>>>> 1. getting root on sites (if installed for multiple users)
>>>>
>>>> I was thinking/hoping we could have a single setup script, which we'd
>>>> pre-install where required, that would configure and start a personal
>>>> WSRF container for the user. Which would be work for us to create,
>>>> install and maintain, but, if successful, would be transparent to 
>>>> the user.
>>>
>>> You need root to configure sudo.
>>
>> Why would you need sudo for gram if it mapped to the same account?
> 
> You wouldn't.  sudo is not needed if the DN of the requester is the same 
> as the DN used to start the container.
> 
>>>
>>> I also don't think you can easily automate the gt4 installation process.
>>> There's manual configuration that needs to be done. I suggest installing
>>> your own gt4 once to which I can submit jobs to get an idea of what's
>>> involved.
>>
>> For non-gram, there's an auto script here:
>>
>>    
>> http://workspace.globus.org/vm/TP2.2/admin/quickstart.html#auto-container
>>
>> The questions it asks users (is this the right hostname? etc) could 
>> also be
>> scripted.
>>
>> Getting from there to GRAM4 auto-configuration should not be too much 
>> of a step
>> (the nimbus contextualization scripts have done it for gram4).
> 
> You could do this and if you avoid staging, then this may work fine for 
> GRAM4.
> 
> But also, we want to have GRAM2 sites to start to use the SEG to remove 
> a significant portion of the GRAM2 scalability problem.  I think that 
> would be best and simplest solution to focus on.  Maybe we can start 
> with a site where you need more scalability and the admin would want to 
> work with us on that?
> 
>>
>> Tim
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel



More information about the Swift-devel mailing list