[RFC] Event prefixing policy

[Steve Langasek]

On Tue, Feb 12, 2013 at 02:42:43PM -0500, Stéphane Graber wrote:

> >>> (1) Require session jobs to specify the ':sys:' prefix to react to system
> >>> events (no prefix or ':user:' would therefore match user events).

> >>>   start on :sys:foo  # start if 'foo' event emitted at PID 1 level.
> >>>   start on foo       # start if 'foo' event emitted at Session Init level.
> >>>   start on :user:foo # start if 'foo' event emitted at Session Init level.

> >> Option 2 is certainly my preference in terms of semantics, though it may
> >> make the implementation hairier than we might like (since the session init
> >> then has to treat the bridged events specially, by *not* adding a prefix to
> >> their names).

> I personally prefer Option 1 as it's actually what we have currently in
> trunk and doesn't require any explicit change to upstart as it's the
> bridge which currently prefixes the events.

> I only worked a bit on user jobs at this point, but I don't expect we'll
> be using :sys: all that much, so having to prefix everything with :user:
> as we'd have to for Option 2 seems like a bit of a pain for no obvious gain.

Ok - it sounds like I'm outnumbered two to one, so I'm happy to go along
with option 1 here.  Indeed, upon reflection I realize that architecturally
this is WAY simpler to implement in upstart (it only requires changing the
bridge, not upstart itself), so gets bonus KISS points.

Indeed, I think lp:~jamesodhunt/upstart/event-prefixes should be tweaked to
not modify the upstart code at all, because there's no reason we need to
have a policy here.  We don't really need to prevent someone using : in
their event names... even if someone wanted to locally emit an event called
':sys:started JOB=[...]', that should be allowed as it's useful for
debugging.  James, what do you think?

> > My current branch does indeed favour option 1 since:

> > - it's less surprising I think that no prefix means 'my current
> >   namespace'.
> > - the ':sys:' prefix is explicit and even if you haven't read the man
> >   pages hints that its referencing something out of the ordinary
> >   (outside the current namespace).

> > To some extent, I think we should consider the relative proportion of
> > user jobs that we envisage would need to reference system events.  As a
> > data point, Stéphanes branch of planned default user jobs currently
> > doesn't (need to) make any mention of system events but certainly makes
> > use of user events.

> Actually, I'll have to for one of the jobs, the event bridge itself
> should only start if the system bus is available, so I'll need a "start
> on started :sys:dbus" and have something that sends me that event as
> it'll have been emitted long before we start the user session.

Somewhat to the side of the topic, but wouldn't it be saner to just assume
dbus is running at the time the user session starts?  I'm not sure it's
possible in practice for this to not be the case, and if it is possible,
maybe we should fix that instead.

> > As an alternative approach, we could introduce a 'match' stanza that would
> > ensure that, if specified, non-prefixed events would actually match those events
> > whose prefix is specified by the match stanza. For example, the following 2 user
> > jobs would be equivalent:

> > job1.conf:
> >   # reference 2 system-level events explicitly
> >   start on :sys:foo and :sys:started bar

> > job2.conf:
> >   # reference 2 system-level events implicitly
> >   match :sys:
> >   start on foo and started bar

> > Pros and Cons of adding a 'match' stanza:

> > + means start/stop on conditions can be identical to system-level
> > + less visual 'noise' in complex conditions
> > + user jobs can be promoted to system jobs without change (since 'match :sys:'
> > would be the default at the system level anyway) [1]

> > - introducing a new stanza has an impact on stateful re-exec (new support code
> > and tests required).

> I don't think it's worth it, adding that stanza means we'll pretty much
> force our users to read the cookbook to figure out exactly what's going
> on. While it's a good idea for our users to go read our documentation, I
> really like the simplicity of most of our jobs, with just a few clear
> stanzas that pretty much anyone can understand without having any
> upstart knowledge.

I agree.  A 'match' stanza would be added complexity for no real gain. 
Simple rules are better.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20130213/fdf1dd28/attachment.pgp>