[Swift-devel] changes

[Tim Armstrong]

Right, I get that it's more flexible: I was mainly trying to understand how
important that flexibility was in practice.

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.

Anyway, this is fairly academic at the moment :)

- Tim


On Sun, Jul 6, 2014 at 5:47 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Sun, 2014-07-06 at 17:20 -0500, Tim Armstrong wrote:
> > > Currently the configuration comes from the client. There is a plan to
> > > have a version of the coaster service where the service is started with
> > > an immutable configuration. This is a relatively different issue. It
> > > does not need a hierarchical configuration format, and it will most
> > > likely be a flat properties file. So if that addresses the problem
> > > from /T's perspective, then things should be fine.
> >
> > I don't think I understand well enough what the pros/cons are here.  With
> > the static configuration, we'd lose the ability for the client to
> > dynamically add new sites
>
> Adding a site, in the sense of a new machine, won't affect services on
> other machines. So this would be a separate issue. Think of coasters as
> a faster GRAM. There is no provision for automatically managing a pool
> of clusters in there.
>
> >  or modify other settings
>
> Right. You would lose the ability to modify settings at will from the
> client.
>
> >  - is that the only
> > difference?  I understand that it maybe buys you some flexibility in that
> > you can stand up a coasters service ahead of time, or reuse the same
> > service for Swift runs with different configurations. I don't know if
> those
> > are likely use cases for Swift/T.
>
> I think standing up services ahead of time is the only possibility right
> now, since the C client does not automatically start services.
>
> >   Are there any Coasters settings where
> > there's some other reason the client needs to set it?
>
> Not that I can think of.
>
> To summarize why I replied previously. You mentioned the coaster service
> parsing its configuration. I'm stating that it's impossible to get both
> flexibility and service-side parsing.
>
> If the service is to load the configuration, then he client only
> controls configuration to the extent that it could make a choices
> between a number of pre-set configurations.
>
> So if the service loads the configuration, that is less flexible than
> when the client is able to tweak all the knobs. And for the client to be
> able to do that based on some user specification, it needs to be able to
> read that user specification.
>
> The bottom line is either server side parsing with the client having
> limited control or client side parsing and that needs the client to be
> able parse.
>
> Mihael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20140706/94c28188/attachment.html>