ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Wed, 2013-09-04 at 11:32 -0700, Steve Langasek wrote:

> On Wed, Sep 04, 2013 at 01:16:07PM -0500, Ted Gould wrote:
> > I wasn't intending to say "upstart should do it" more that we should put
> > it in the Upstart job configuration and use that as our basis.  That's
> > what I was trying to say with "upstart-bridge-like" thing in that it'd
> > get the information from Upstart (including dynamic job creation,
> > addition, etc) but still do the tracking and reaction on its own.  I'd
> > expect that then it'd stop/start/restart jobs using Upstart as well.
> 
> Six of one, half a dozen of the other. :-)  The purpose of upstart bridges
> is to generate various events; in some cases the bridges will parse upstart
> job files to decide which events from the set of all possible events they
> should actually generate, but they're still about generating events.  I
> think putting the limit information in the .conf files and having an upstart
> bridge to act on them by generating events is a matter of
> everything-looks-like-a-nail, not something that's a natural fit for upstart
> or upstart bridges.


I see what you're saying, and I agree.  I guess where I'm seeing the
symmetry is the idea of having one place to configure services.  One way
to think about and to manage them.  And one way to see all of their
limits.  I don't have a strong bias to say that this must be Upstart,
but I do feel that Upstart configuration files already have a fair
amount of this data, and that should be leveraged.

It seems that any alternative solution would need to contain a pointer
to the Upstart job anyway... so I don't think extending the job
configuration format to handle that data is unreasonable.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part