SLS introduction

[Jacob Peddicord]

Hello,

On Tue, Aug 17, 2010 at 4:32 AM, David Henningsson
<david.henningsson at canonical.com> wrote:
> First, I think it is a very good idea to have some consistency on how
> different services are configured. I think it will help newcoming users
> to have a consistent configuration GUI. In addition, integrate it with
> ConsoleKit, and you might a secure way of letting different users
> configure different services.

Haven't looked into ConsoleKit yet, but I'll put it on the radar.
Additionally, for maverick+1 I'm going to try and come up with a
ncurses UI to make this more accessible on the server as well.

> It doesn't feel really ready to take on much more than the very simplest
> programs at this point, however. And there is, or will probably be, a
> scalability problem as the number of programs require their setting
> types, and this probably requires additional thought.

I agree completely, and am looking for ways to expand to accommodate
more applications.

> One missing feature, I believe, is to be able to handle sections in
> ini-style files. In simplest form, this just means being able to specify
> a section name in the "parse" tag, but if you look at e g samba, you
> want to be able to add and remove entire sections, and then configure
> those sections.

This is somewhat possible, though it looks like I missed it in the
documentation. A <parse> tag can have an "after" attribute that tells
it to not start looking for a string until a certain section is
reached. In this way you can change multiple lines in different
sections of a file. There is no sane way to add or remove sections,
however, and currently the amount of settings presented is fixed based
on the XML content.

> Later, you'll find that one service wants you to add a list of icons
> instead of strings, another needs a grid, yet another wants you to order
> strings a specific order (i e the strings are fixed but the order
> configurable), yet another wants you to be able to add and remove sets
> of settings, someone wants a color box, another wants advanced grouping
> of settings, etc etc. You might end up having a very bloated SLS schema,
> trying to cover every case in the world.

This is very true, and is what I'd like to avoid. When creating the
system, I wanted to emphasize the fact that SLS is for basic, one-off
settings. Each service is different and requires a plethora of
different settings that can be configured, some depending on others.

Take Cherokee in the video, for example: while SLS makes it easy to
change a server port or global setting, you can't configure the
infinite number of document roots that it allows for. Cherokee has its
own settings interface, cherokee-admin, that is much more complex in
what it configure, purely because it was designed for Cherokee. Having
all of these settings configurable in SLS would duplicate a lot of
effort, and that's also why for some services the UI recommends
launching an external program.

> There is also the update mechanism, is there any way in SLS to specify
> what to do when committing settings to make them take effect in the
> configured service?

That's undefined in the SLS spec at the moment, and is up to the
client program (ie, jobs-admin) to act on. Currently, jobs-admin
prompts to restart the service when a setting is changed. However, it
would be a good idea to add this to the SLS spec for other cases such
as sending a SIGHUP or running reload.

> Also, it would be nice with thought through help, i e probably a pointer
> to some help file, and/or additional hints available when selecting the
> actual setting.

I thought about adding "extended descriptions" that could be used as
tooltips or other extra text, but decided against it since it would
add another tag to set up which might not be useful everywhere.
Alternatively, it is possible to add a simple "label"-type setting
before/after other settings to provide information or context. The
reason you don't see these in some of the default services is because
I just didn't write them in. :P I'll look into what can be done to be
more informative in this regard.

> So to sum up - good job so far, but you are probably just getting
> started :-)

Thanks, and you're right -- there's a lot I'd like to accomplish for
m+1. The SLS backend, while stable, needs a lot of changes before I'd
like to call it 1.0, including object-oriented types, validators, and
being more efficient when writing to files. jobservice backends will
need to be written for Upstart 0.10 and even systemd.

Cheers

-- 
Jacob Peddicord
http://jacob.peddicord.net/
https://launchpad.net/~jpeddicord