A Proposal to deal with groups

[Scott James Remnant]

On Wed, 2009-07-22 at 23:36 -0700, Saravanan Shanmugham (sarvi) wrote:

> I have been struggling with what it means to have groups in Upstart
> and what the expectd behaviour would be.
>  
> Here is what I have come up. I went through several iterations over
> the last few months thinking about what it should look like.
> This is the one that feels good so far or anywhere close to it.
>  
> Here is a proposal to support groups in Upstart.
> 
Hi Sarvi,

Thanks for your work on this!

One thing I've found that has helped figuring out features and designs
for Upstart is to set down the use cases first.  Your presentation
focuses on the details of how you'd implement groups, without putting
them into a context of how they would be used.

It'd certainly help people reading it (including me!) to understand
where you're coming from.

Another useful reason for having use cases is when you have two possible
implementations, and want to find out which works best.


I'm not quite sure whether Groups are the same thing as States or a
separate first-class object.  It's probably a good idea for me to write
down the direction I've been vaguely heading, so we can figure out
whether I've got this wrong ;-)

The use cases for states are:

 * define system states ("networking"), ("multi-user") based on the
   availability of a set of services or completion of a set of tasks

 * define more advanced states based on things like hardware
   ("on ac power"), ("docked") and have services included or excluded
   from these states

 * define groups of jobs together as a single set ("LAMP stack") where
   the set is automatically marked active when its components are active

   thus a sysadmin can use "status lamp" to see whether the LAMP stack
   is active, rather than checking the individual pieces

 * combine with "while" to allow a sysadmin to start a state


The implementation is simply to have process-less jobs.  This has been
permitted in Upstart since 0.3, a process-less job remains in the
running state until it is stopped.

Thus a state is simply a file containing a "while" clause, multi-user
could be (in a sysv-compatible system):

   while runlevel RUNLEVEL=[2345]

Things like ac power, docked, would use different events/states as a
base.

LAMP might look like:

   while apache and mysql


When apache and mysql are started, the LAMP state would be started too
(while condition met) so show as running; if either apache or mysql were
stopped, the LAMP state would be stopped too (while condition no longer
met) and show as stopped.

Other services can then use "while lamp", etc.


The "start" and "stop" sysadmin commands have a special behaviour, if
the while condition is not true, but the members that are false are
Upstart jobs, it will pre-start those.  So a sysadmin may use "start
lamp"


This merging is why 0.6 uses a single directory of *.conf files, each
file specifies a task, service or state and the difference is just the
content.

If I've got this wrong, we'll probably want multiple directories again
or multiple extensions.

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/20090723/0674b7ef/attachment.pgp