[Swift-devel] manual coasters

[Mihael Hategan]

On Thu, 2010-07-01 at 11:29 -0500, wilde at mcs.anl.gov wrote:
> Very cool - thanks, Mihael!
> 
> For the sites entry, do we still use the current format to indicate where the server should start?

Yes. That should work. But "queue=fast" there doesn't do anything.

> Eg:
> 
>   <pool handle="coasterpool01">
>     <execution provider="coaster" url="none" jobManager="pbs"/>
>     <profile namespace="globus"> key="workerManager">passive</profile>
>     <profile namespace="globus" key="queue">fast</profile>
>     <profile namespace="karajan" key="initialScore">10000</profile>
>     <profile namespace="karajan" key="jobThrottle">.07</profile>
>     <gridftp  url="local://localhost" />
>     <workdirectory >/home/wilde/swiftwork</workdirectory>
>   </pool>
> 
> Is the full range of provider options available to start the server in passive mode?
> 
> Will throttling settings be honored?
> 
> Can we start multiple coaster servers in different places?
> 
> 
> - Mike
> 
> 
> ----- "Mihael Hategan" <hategan at mcs.anl.gov> wrote:
> 
> > Manual coasters are in trunk. I did some limited testing on
> > localhost.
> > 
> > The basic idea is that you say <profile namespace="globus"
> > key="workerManager">passive</profile> in sites.xml. Other than that
> > you
> > may want to set workersPerNode, but the other options are useless.
> > 
> > Then, when swift starts the coaster service, it will print the URL of
> > that on stderr.
> > 
> > You carefully dig for worker.pl and then launch it in whatever way
> > you
> > like:
> > 
> > worker.pl <ServiceURL> <blockid> <logdir>
> > 
> > The blockid can be whatever you want, but it can be used to group
> > workers in the traditional blocks. The logdir is where you want the
> > worker logs to go. They are all mandatory.
> > 
> > When workers connect to the service, the service should start
> > shipping
> > jobs to them. When the service is shut down, it will also try to shut
> > down the workers (they are useless anyway at that point), but it
> > cannot
> > control the LRM jobs, so it may fail to do so (or rather said, it is
> > more likely to fail to do so).
> > 
> > Mihael
> > 
> > _______________________________________________
> > Swift-devel mailing list
> > Swift-devel at ci.uchicago.edu
> > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>