<div dir="ltr"><div>Right, I get that it's more flexible: I was mainly trying to understand how important that flexibility was in practice.  <br><br>The main use case I think would be to start a Coaster service at the same time as the Swift/T run and tear it down once the run was done: e.g. with a launch script that starts both the Coaster service and the Swift run.  It sounds like starting a Coaster service pointed at a configuration file would achieve exactly the same thing as starting a Coaster service then configuring it via the client in this scenario.  I don't know the config mechanism and settings well enough to be confident about that assessment is my problem.<br>
<br></div><div>Anyway, this is fairly academic at the moment :)<br><br></div><div>- Tim<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 6, 2014 at 5:47 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Sun, 2014-07-06 at 17:20 -0500, Tim Armstrong wrote:<br>
> > Currently the configuration comes from the client. There is a plan to<br>
> > have a version of the coaster service where the service is started with<br>
> > an immutable configuration. This is a relatively different issue. It<br>
> > does not need a hierarchical configuration format, and it will most<br>
> > likely be a flat properties file. So if that addresses the problem<br>
> > from /T's perspective, then things should be fine.<br>
><br>
> I don't think I understand well enough what the pros/cons are here.  With<br>
> the static configuration, we'd lose the ability for the client to<br>
> dynamically add new sites<br>
<br>
</div>Adding a site, in the sense of a new machine, won't affect services on<br>
other machines. So this would be a separate issue. Think of coasters as<br>
a faster GRAM. There is no provision for automatically managing a pool<br>
of clusters in there.<br>
<br>
>  or modify other settings<br>
<br>
Right. You would lose the ability to modify settings at will from the<br>
client.<br>
<div class=""><br>
>  - is that the only<br>
> difference?  I understand that it maybe buys you some flexibility in that<br>
> you can stand up a coasters service ahead of time, or reuse the same<br>
> service for Swift runs with different configurations. I don't know if those<br>
> are likely use cases for Swift/T.<br>
<br>
</div>I think standing up services ahead of time is the only possibility right<br>
now, since the C client does not automatically start services.<br>
<div class=""><br>
>   Are there any Coasters settings where<br>
> there's some other reason the client needs to set it?<br>
<br>
</div>Not that I can think of.<br>
<br>
To summarize why I replied previously. You mentioned the coaster service<br>
parsing its configuration. I'm stating that it's impossible to get both<br>
flexibility and service-side parsing.<br>
<br>
If the service is to load the configuration, then he client only<br>
controls configuration to the extent that it could make a choices<br>
between a number of pre-set configurations.<br>
<br>
So if the service loads the configuration, that is less flexible than<br>
when the client is able to tweak all the knobs. And for the client to be<br>
able to do that based on some user specification, it needs to be able to<br>
read that user specification.<br>
<br>
The bottom line is either server side parsing with the client having<br>
limited control or client side parsing and that needs the client to be<br>
able parse.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
<br>
</font></span></blockquote></div><br></div>