FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 05-22-2008, 08:04 PM
Bill Nottingham
 
Default upstart plans for F10+

Since I've been asked in various places what we're planning to
do with upstart now that Fedora 9 has shipped, I figured I'd
lay out the basic plan.

To do any large-scale conversion of SysV init scripts to upstart,
we need some features that are not in the current (0.3.9) version.
Hence, the first thing is to get upstart 0.5 ready for inclusion.
For example, we need support for the following:

- Depending on multiple events

I.e., have something start only if two separate events have
both completed successfully. For a disturbing example of how
we work around this now, read /etc/event.d/serial.

- Ability to enable/disable events in a way other than removing
the file

(The reasoning for this should be fairly obvious)

- Ability to group events into sets, or profiles

This allows us to handle the sort of behaviors that runlevels are
used for sanely.

- Ability to easily have upstart events depend on SysV scripts, and
vice-versa

If one of a SysV scripts' dependencies is started by upstart, we
need to be able to still handle that sanely.

This isn't meant to be an exhaustive list, but it is meant to
illustrate why we can't just move services right now.

Once we get upstart 0.5 in, we can then look at potentially moving
some subset of things that are now handled elsewhere to upstart.
Examples would be:

- Always-on services such as dbus, syslog, and audit
- Reworking things like netfs to be more sane, when
it comes to networks coming and going, network block devices being
attached and detached, and so on
- Potentially splitting some of rc.sysinit into multiple events.
Not sure this buys us much, as right now the flow is *extremely*
sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)
- Coming up with a sane network notification strategy
Right now, we have events kicked off on network changes:
- via netreport
- via NetworkManagerDispatcher
- conceivably, via upstart (after all, spawning commands/etc based
on events is its raison d'etre)
Having a coherent strategy for apps to only need to worry about
dropping things in one place would make sense.
- (possibly) having either upstart 'handle' sysv services more natively
or wrap tools such as chkconfig, /sbin/service so they handle both
SysV and upstart.

All clear as mud?

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:10 PM
Konrad Meyer
 
Default upstart plans for F10+

Quoth Bill Nottingham:
> Since I've been asked in various places what we're planning to
> do with upstart now that Fedora 9 has shipped, I figured I'd
> lay out the basic plan.
>
> To do any large-scale conversion of SysV init scripts to upstart,
> we need some features that are not in the current (0.3.9) version.
> Hence, the first thing is to get upstart 0.5 ready for inclusion.
> For example, we need support for the following:
>
> - Depending on multiple events
>
> I.e., have something start only if two separate events have
> both completed successfully. For a disturbing example of how
> we work around this now, read /etc/event.d/serial.
>
> - Ability to enable/disable events in a way other than removing
> the file
>
> (The reasoning for this should be fairly obvious)
>
> - Ability to group events into sets, or profiles
>
> This allows us to handle the sort of behaviors that runlevels are
> used for sanely.
>
> - Ability to easily have upstart events depend on SysV scripts, and
> vice-versa
>
> If one of a SysV scripts' dependencies is started by upstart, we
> need to be able to still handle that sanely.
>
> This isn't meant to be an exhaustive list, but it is meant to
> illustrate why we can't just move services right now.
>
> Once we get upstart 0.5 in, we can then look at potentially moving
> some subset of things that are now handled elsewhere to upstart.
> Examples would be:
>
> - Always-on services such as dbus, syslog, and audit
> - Reworking things like netfs to be more sane, when
> it comes to networks coming and going, network block devices being
> attached and detached, and so on
> - Potentially splitting some of rc.sysinit into multiple events.
> Not sure this buys us much, as right now the flow is *extremely*
> sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)
> - Coming up with a sane network notification strategy
> Right now, we have events kicked off on network changes:
> - via netreport
> - via NetworkManagerDispatcher
> - conceivably, via upstart (after all, spawning commands/etc based
> on events is its raison d'etre)
> Having a coherent strategy for apps to only need to worry about
> dropping things in one place would make sense.
> - (possibly) having either upstart 'handle' sysv services more natively
> or wrap tools such as chkconfig, /sbin/service so they handle both
> SysV and upstart.
>
> All clear as mud?
>
> Bill


Thanks for keeping us informed of the current state of (upstart) affairs.

--
Conrad Meyer <konrad@tylerc.org>
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:24 PM
M
 
Default upstart plans for F10+

Hi,

2008/5/22 Bill Nottingham <notting@redhat.com>:
> Since I've been asked in various places what we're planning to
> do with upstart now that Fedora 9 has shipped, I figured I'd
> lay out the basic plan.
>
> To do any large-scale conversion of SysV init scripts to upstart,
> we need some features that are not in the current (0.3.9) version.
> Hence, the first thing is to get upstart 0.5 ready for inclusion.
> For example, we need support for the following:
>
> - Depending on multiple events

AFAIK it's already in Upstart trunk

>
> I.e., have something start only if two separate events have
> both completed successfully. For a disturbing example of how
> we work around this now, read /etc/event.d/serial.

FYI /etc/event.d was changed to /etc/init/jobs.d

>
> - Ability to enable/disable events in a way other than removing
> the file
>
> (The reasoning for this should be fairly obvious)
>
> - Ability to group events into sets, or profiles
>
> This allows us to handle the sort of behaviors that runlevels are
> used for sanely.
>
> - Ability to easily have upstart events depend on SysV scripts, and
> vice-versa
>
> If one of a SysV scripts' dependencies is started by upstart, we
> need to be able to still handle that sanely.
>
> This isn't meant to be an exhaustive list, but it is meant to
> illustrate why we can't just move services right now.
>
> Once we get upstart 0.5 in, we can then look at potentially moving
> some subset of things that are now handled elsewhere to upstart.
> Examples would be:
>
> - Always-on services such as dbus, syslog, and audit
> - Reworking things like netfs to be more sane, when
> it comes to networks coming and going, network block devices being
> attached and detached, and so on
> - Potentially splitting some of rc.sysinit into multiple events.
> Not sure this buys us much, as right now the flow is *extremely*
> sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)

I wanted to do this, but actually initctl is not finished - it will be
needed to sending variable values i.e. value of SELINUX_STATE from
rcS-check-selinux-state to scripts that depend on SELINUX_STATE.

> - Coming up with a sane network notification strategy
> Right now, we have events kicked off on network changes:
> - via netreport
> - via NetworkManagerDispatcher
> - conceivably, via upstart (after all, spawning commands/etc based
> on events is its raison d'etre)
> Having a coherent strategy for apps to only need to worry about
> dropping things in one place would make sense.
> - (possibly) having either upstart 'handle' sysv services more natively
> or wrap tools such as chkconfig, /sbin/service so they handle both
> SysV and upstart.
>
> All clear as mud?
>
> Bill
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Regards,
Michal

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:31 PM
"Colin Walters"
 
Default upstart plans for F10+

On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham <notting@redhat.com> wrote:
>
> Once we get upstart 0.5 in, we can then look at potentially moving
> some subset of things that are now handled elsewhere to upstart.
> Examples would be:
>
> - Always-on services such as dbus, syslog, and audit

Last time I talked to Scott he had in-progress code to make 0.5 manage
the system bus internally. If the system bus depends on syslog and
audit those may need to be started too.

> - Reworking things like netfs to be more sane, when
> it comes to networks coming and going, network block devices being
> attached and detached, and so on

Aren't pretty much all kernel based network filesystems broken in the
world of dynamic networking?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:32 PM
M
 
Default upstart plans for F10+

BTW. It would be cool if someone created a separate mailing list for
Upstart init script "development" and git repository.

Regards,
M.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:33 PM
"Daniel P. Berrange"
 
Default upstart plans for F10+

On Thu, May 22, 2008 at 04:31:07PM -0400, Colin Walters wrote:
> On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham <notting@redhat.com> wrote:
> >
> > Once we get upstart 0.5 in, we can then look at potentially moving
> > some subset of things that are now handled elsewhere to upstart.
> > Examples would be:
> >
> > - Always-on services such as dbus, syslog, and audit
>
> Last time I talked to Scott he had in-progress code to make 0.5 manage
> the system bus internally. If the system bus depends on syslog and
> audit those may need to be started too.
>
> > - Reworking things like netfs to be more sane, when
> > it comes to networks coming and going, network block devices being
> > attached and detached, and so on
>
> Aren't pretty much all kernel based network filesystems broken in the
> world of dynamic networking?

Not to mention network based block devices too...

Dan
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:40 PM
Casey Dahlin
 
Default upstart plans for F10+

Bill Nottingham wrote:
Since I've been asked in various places what we're planning to
do with upstart now that Fedora 9 has shipped, I figured I'd

lay out the basic plan.

To do any large-scale conversion of SysV init scripts to upstart,
we need some features that are not in the current (0.3.9) version.
Hence, the first thing is to get upstart 0.5 ready for inclusion.
For example, we need support for the following:

- Depending on multiple events

I.e., have something start only if two separate events have
both completed successfully. For a disturbing example of how
we work around this now, read /etc/event.d/serial.




This is in place now.


- Ability to enable/disable events in a way other than removing
the file

(The reasoning for this should be fairly obvious)




Might be a way to do this now with some of the new environment stuff,
but a good solid way of doing it should come in 0.5.1. This is my first
summer project, should be done by FUDCon latest.



- Ability to group events into sets, or profiles

This allows us to handle the sort of behaviors that runlevels are
used for sanely.




Comes with above.


- Ability to easily have upstart events depend on SysV scripts, and
vice-versa

If one of a SysV scripts' dependencies is started by upstart, we
need to be able to still handle that sanely.




We're pretty close to this as of now really. A bit more /etc/rc tweaking
will get this.



This isn't meant to be an exhaustive list, but it is meant to
illustrate why we can't just move services right now.

Once we get upstart 0.5 in, we can then look at potentially moving
some subset of things that are now handled elsewhere to upstart.
Examples would be:

- Always-on services such as dbus, syslog, and audit
- Reworking things like netfs to be more sane, when
it comes to networks coming and going, network block devices being
attached and detached, and so on
- Potentially splitting some of rc.sysinit into multiple events.
Not sure this buys us much, as right now the flow is *extremely*
sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)



We're shipping a 900-line shell script. That's the reason.


- Coming up with a sane network notification strategy
Right now, we have events kicked off on network changes:
- via netreport
- via NetworkManagerDispatcher
- conceivably, via upstart (after all, spawning commands/etc based
on events is its raison d'etre)
Having a coherent strategy for apps to only need to worry about
dropping things in one place would make sense.



+1. As soon as more of the DBus stuff appears in trunk (Scott seems to
have quite a bit more on his hard drive than he's leaking to launchpad)
I'm going to go chat with the NM people about this.



- (possibly) having either upstart 'handle' sysv services more natively
or wrap tools such as chkconfig, /sbin/service so they handle both
SysV and upstart.




We're going to have a very hard time doing this without effecting the
sysv interface.



All clear as mud?

Bill




As clear as an azure sky of deepest summer. You can rely on me, Fred.

--CJD

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:41 PM
Simo Sorce
 
Default upstart plans for F10+

On Thu, 2008-05-22 at 16:31 -0400, Colin Walters wrote:
> On Thu, May 22, 2008 at 4:04 PM, Bill Nottingham <notting@redhat.com> wrote:
> >
> > Once we get upstart 0.5 in, we can then look at potentially moving
> > some subset of things that are now handled elsewhere to upstart.
> > Examples would be:
> >
> > - Always-on services such as dbus, syslog, and audit
>
> Last time I talked to Scott he had in-progress code to make 0.5 manage
> the system bus internally. If the system bus depends on syslog and
> audit those may need to be started too.
>
> > - Reworking things like netfs to be more sane, when
> > it comes to networks coming and going, network block devices being
> > attached and detached, and so on
>
> Aren't pretty much all kernel based network filesystems broken in the
> world of dynamic networking?

It depends on what you mean by broken, CIFS for example can handle
reconnections ...

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:44 PM
Bill Nottingham
 
Default upstart plans for F10+

Colin Walters (walters@verbum.org) said:
> > - Reworking things like netfs to be more sane, when
> > it comes to networks coming and going, network block devices being
> > attached and detached, and so on
>
> Aren't pretty much all kernel based network filesystems broken in the
> world of dynamic networking?

I mean, right now we have a static init script that runs once
on boot to mount NFS, SMB, etc, and set up network block devices.
It's also (in F9) kicked when NM brings up a new default route.

What would be sane is to have it just mount things when it can
reach the proper network, and lazily unmount them when that
network goes away. Heck, this can be extended to all filesystems -
why should you do mount -a to mount /usr/local - why not just
have anything in fstab automatically mounted when the device with
the proper filesystem signature is found?

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 05-22-2008, 08:45 PM
Bill Nottingham
 
Default upstart plans for F10+

Casey Dahlin (cjdahlin@ncsu.edu) said:
>> - Potentially splitting some of rc.sysinit into multiple events.
>> Not sure this buys us much, as right now the flow is *extremely*
>> sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)
>
> We're shipping a 900-line shell script. That's the reason.

libtool scoffs at you.

Bill

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 01:20 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org