Proposed 1.0 semantics specification

[Scott James Remnant]

On Tue, 2009-06-16 at 21:45 +0200, Kees Jongenburger wrote:

> Thanks Casey for starting this disc
> 
> On Sun, Jun 14, 2009 at 9:57 PM, Casey Dahlin<cdahlin at redhat.com> wrote:
> > This is my attempt to record and formalize Scott's description to me of
> > the way Upstart 1.0 should behave. Its not complete and need some
> > review, but there's a critical mass there now and I think its time to
> > draw attention to it.
> >
> > http://upstart.ubuntu.com/wiki/CaseyDahlin/NewInternalSemantics
> 
> Here are my first notes:
> Events:
> >An event in Upstart is simply a particular point in time. It can be
> "3pm Thursday" or "The moment we first found out a network card >was
> plugged in." In the case of the first example, Upstart can detect that
> "3pm Thursday" has arrived by watching the system time. >In the case
> of the second, some external application (in this case likely device
> kit) would have to notify Upstart that the event >occurred.
> 
> The current upstart is strictly event driven. there might be some
> timeouts in the code to handle process states and such but I don't
> think upstart should monitor time or anything.
> 
It actually makes a lot of sense to merge crond and atd functionality
into Upstart, especially when you consider the event-driven nature.

You can then express conditions such as:

 * 30 seconds after apache is started

 * every 5 minutes while apache is running

 * run daily, but only if the system is on AC power

With sub-job support, such tasks for a service can be expressed inside
the /etc/init/*.conf for that service.  This contains everything related
together, which is nice.

Cron obviously has some interesting features with regard to mailing
standard error of tasks out to the user who ran them if they fail -
wouldn't it be nice if Upstart did that for its jobs?

> I event think that the current events already have to much
> information /variable in them
> 
Yes, I'd like to move away from "generic" events to more specific ones.

> This does sound nice but the can not be true. in case of things like
> network card what one want to to might be to create an instance using
> the "network card name" as instance indicator. to me this sound like a
> factory but this concept doesn't exit in upstart
> 
This is very much the intent of the 1.0-style instance creation.

> > Classes
> There as probably much more required methods "on_start on_event
> on_starting on_failed_dependency ..."
> 
"Failed dependency" is an interesting one; Upstart doesn't really
process jobs in that way - a job simply stays dormant all the time its
while condition isn't satisfied.

The only time you'd get a "failed to start due to a while condition" is
if, as a sysadmin, you ran "start JOB" manually -- this is communicated
back as an error to the start command, other jobs on the system don't
need to know about it.

> > States
> I find this part very confusing and I see many "Waiting" and I don't get it :p
> Anyway:
> Within the upstart code there is a concept called the "goal" it
> determines where a job is heading I think it is a confortable
> way of telling "what the goal is" and the states to get there are easy
> to follow.
> 
Right, the goal is still very much important.

When the job is created, it will be at stop/waiting.

When the start condition occurs, it will be at start/waiting and thus
progress through the states.

When the stop condition occurs, it will be switched to stop/running and
thus progress back down through the states.

> > Operations on instances
> you mention restart being a stop and start
> This is in general not true. when a service is stopped the services
> that depend on that service should stop(sometimes at least)
> while a restart can be as simple as sending a HUP to the process
> requesting is to reinitialize
> 
> I think signal or "bus_message" might be other things you want to send
> to the instance.
> 
That's reload, not restart.

Restart is a hard, forced, restart of the service.  You'd expect other
services that use it to be restarted as well.

We definitely want to support custom actions for a service, which should
be exec, script or signal I think.

> >The Queue
> >When an event occurs or something attempts to call a method on one of
> Upstart's objects, this action is placed at the tail of a >Queue.
> Upstart processes actions from the head of the queue, one at a time.
> This has an effect of serialization; we do not have to >consider the
> idea of two events or method calls happening at once. During
> operation, Upstart may occasionally add one or more >events to the
> head of the queue to be processed immediately.
> 
> Like Scott mentioned the events are not  serialized a such. This is
> because one single event generates new events
> so they are not handled in a synchronous manner. The event can be
> started to be consumed and then parked again to handle other events.
> This is one part for the code that requires a little more thinking.
> 
Yeah, I kinda like the idea that a command is placed on the event queue
though - it'd make the following happen in the expected order:

  # initctl emit foo
  # initctl start bar

Right now, it's possible that bar will be started before foo is
processed.


Events are processed in series, you're right that they do stay on the
queue, but this is for blocking and pointer reference reasons rather
than out-of-order processing.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20090617/8bc68afa/attachment.pgp