[Swift-devel] changes

[Tim Armstrong]

> 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 or modify other settings - 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.  Are there any Coasters settings where
there's some other reason the client needs to set it?

- Tim



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

> On Sun, 2014-07-06 at 15:01 -0500, Tim Armstrong wrote:
> > I think the goal would be to allow the same sites files to be used for
> > Swift/K and Swift/T+coasters, right? Currently Swift/T is mainly
> configured
> > through environment variables.
> >
> > It seems like it might make the most sense architecturally in Swift/T for
> > the Coaster service to load the config file directly, given that the
> config
> > file will probably just be slurped up and sent to the service anyway.  If
> > this was possible it might avoid the issue entirely.
>
> 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.
>
> >
> > The main issue with using a parser that accepts a superset of the
> official
> > config file syntax is that config files with syntax that "officially" is
> > invalid will probably crop up.  In practice this might be a relatively
> > small problem but I can see users being confused by it.
>
> The choice is not that. The choice at the moment is between an in-house
> format that isn't well documented, does not specify how special
> characters are handled (or expressed), does not escape much (try & in an
> environment variable) etc. and a variant of a standard that isn't
> completely in-house and that handles the corner cases. Well, that or
> back to XML.
>
> >
> > I do think a custom format would need more documentation than is
> currently
> > in the user guide - there's no mention of how whitespace is handled, for
> > example.
>
> I think everybody agrees that the current documentation isn't quite
> right. Fixing that would be part of the change.
>
> >
> > My two cents is that just parsing it directly from Java will save effort
> in
> > the long run and improve the user experience with better error reporting
> > etc.  Having multiple stages of processing also makes it harder to ensure
> > that special characters, whitespace, etc is correctly preserved, and
> makes
> > it hard to e.g. provide line numbers in error messages if desired.
>
> Right. Hence my choice of doing this. An additional difficulty was that
> it seemed hard to convince the current translator to accommodate a
> more-than-one-nesting-level hierarchical structure.
>
> There are more benefits, in that there would now be a unified validation
> place that checks all configuration values and fails early. This was
> previously either missing (for tc.data) or scattered in different places
> (providers for sites.xml, the perl code for the sites translator, custom
> java code for the other swift properties).
>
> Mihael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20140706/6be02a19/attachment.html>