Plan for tomorrows (20080124) FESCO meeting

[Brian Pepple]

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC
in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting -- jds2001 --
http://fedoraproject.org/wiki/JonStanley/BugWorkflow 

/topic FESCo-Meeting -- New Features -
http://fedoraproject.org/wiki/Features/Dashboard - poelcat
      * http://fedoraproject.org/wiki/Features/Upstart

/topic FESCo meeting -- Free discussion around Fedora

You want something to be discussed? Send a note to the list in reply to
this mail and I'll add it to the schedule (I can't promise we will get
to it tomorrow, since we have a pretty full schedule).  You can also
propose topics in the meeting while it is in the "Free discussion around
Fedora" phase.

If your name/nick is on above list please update the status on the
Extras schedule pages in the wiki ahead of the meeting. That way all the
other FESCo members and interested contributors know what up ahead of
the meeting. And we will avoid long delays in the meeting -- those often
arise if someone describes the recent happenings on a topic directly in
the meeting while all the others have to wait for his slow typing...

Later,
/B
-- 
Brian Pepple <bpepple(a)fedoraproject.org&gt;

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E

[Jochen Schmitt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 23 Jan 2008 11:26:18 -0500, you wrote:

> /topic FESCo-Meeting -- New Features -
> http://fedoraproject.org/wiki/Features/Dashboard - poelcat
>       * http://fedoraproject.org/wiki/Features/Upstart
>  
I think you schould change the topic to "Which initscript
replacement should we used for upcomming versions of Fedora"

- From my point of view approving of this feature sound like make a
dicission for use upstart as the new initscript replacement in
Fedora.

But when I read the article "Call To Choose An Initscript
Replacement" on http://fedoraproject.org/wiki/FWN/Issue115
upstart will no be the canidate tor this task.

Best Regards:

Jochen Schmitt

> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.6.3 (Build 3017)
> Charset: us-ascii
>
> wj8DBQFHl3J6T2AHK6txfgwRAv73AKCN4YKlzR/AISRS+OgRGdsKHi+69gCgll8V
> hOoB1tYHJP/eRe6MepeiuZw=
> =sT8g
> -----END PGP SIGNATURE-----

[Toshio Kuratomi]

Jochen Schmitt wrote:
>  On Wed, 23 Jan 2008 11:26:18 -0500, you wrote:
>  
> > /topic FESCo-Meeting -- New Features -
> > http://fedoraproject.org/wiki/Features/Dashboard - poelcat
> >      * http://fedoraproject.org/wiki/Features/Upstart
>  
>  
>  I think you schould change the topic to "Which initscript
>  replacement should we used for upcomming versions of Fedora"
>  
>  - From my point of view approving of this feature sound like make a
>  dicission for use upstart as the new initscript replacement in
>  Fedora.
>   
It's not a feature unless a decision has been made and initscripts are 
replaced with something specific.

>  But when I read the article "Call To Choose An Initscript
>  Replacement" on http://fedoraproject.org/wiki/FWN/Issue115
>  upstart will no be the canidate tor this task.
>   
There is one thing lacking from that writeup and one additional point of 
information:
1) Looking into InitKit, people found that it is a specification for 
event-driven init systems and that upstart would be the main driver's 
implementation ground for that specification.  So using upstart isn't as 
out-there as the writeup leaves it.

2) Casey Dahlin held a FUDCon session to discuss how to replace our 
current initsystem and is the driver of the feature.  Perhaps Casey 
needs to tell us what was discussed at FUDCon so we are on the same page 
WRT where the discussion has gone.

Casey?

-Toshio

[Casey Dahlin]

Toshio Kuratomi wrote:
>  Jochen Schmitt wrote:
> > On Wed, 23 Jan 2008 11:26:18 -0500, you wrote:
> >
> >> /topic FESCo-Meeting -- New Features -
> >> http://fedoraproject.org/wiki/Features/Dashboard - poelcat
> >>      * http://fedoraproject.org/wiki/Features/Upstart
> >
> >
> > I think you schould change the topic to "Which initscript
> > replacement should we used for upcomming versions of Fedora"
> >
> > - From my point of view approving of this feature sound like make a
> > dicission for use upstart as the new initscript replacement in
> > Fedora.
> >
>  It's not a feature unless a decision has been made and initscripts are 
>  replaced with something specific.
>
> > But when I read the article "Call To Choose An Initscript
> > Replacement" on http://fedoraproject.org/wiki/FWN/Issue115
> > upstart will no be the canidate tor this task.
> >
>  There is one thing lacking from that writeup and one additional point 
>  of information:
>  1) Looking into InitKit, people found that it is a specification for 
>  event-driven init systems and that upstart would be the main driver's 
>  implementation ground for that specification.  So using upstart isn't 
>  as out-there as the writeup leaves it.
>
>  2) Casey Dahlin held a FUDCon session to discuss how to replace our 
>  current initsystem and is the driver of the feature.  Perhaps Casey 
>  needs to tell us what was discussed at FUDCon so we are on the same 
>  page WRT where the discussion has gone.
>
>  Casey?
>
>  -Toshio
>  
I was hoping the video tape of the session would be out before now (if 
anyone has it, haaalp!), but here's roughly what happened:

We began by ennumerating a few init systems that were available. We 
listed (unless I forget):

SysV (our current implementation)
prcsys
rrn (my own rewrite of prcsys)
initng
Upstart
murdur

I mentioned InitKit and pointed out the fact that it was not an actual 
software project, but a specification.

Murdur we eliminated immediately on the grounds that it is tightly 
integrated with the package system of Pardus, and, by upstream's own 
admittance, is not really suited to integration with other distros.

Next up was prcsys. I pointed out that the code was rather inferior and 
ill suited to some of the modifications we had been pondering for this 
style of init system, and that rrn would be more flexible and would 
likely achieve feature parity with prcsys by the following day's 
hackfest. A brief outline of how prcsys worked internally had most 
people in agreement, and prcsys was stricken down.

SysV at this point was put aside. I proposed that we assume we would 
pick a new system, and then once we had selected one, weight that one 
alone against staying where we were.

With the initial culling out of the way, we began to get into the 
benefits of each individual init system. Upstart and its operation got 
the most explanation. Upstart is designed as an event-driven init 
system, where services are spawned in reaction to events rather than en 
masse when runlevel transitions occur (in fact an Upstart system may not 
have any concept of runlevels at all, though it can. More on that 
later). This allows for many advantages (allowing HAL to drive service 
activation, running services only as they are needed, etc). Upstart is 
also a service manager. It keeps track of the processes it spawns, can 
restart them automatically, and keeps the system notified of their 
state. Upstart's roadmap also includes integrating cron functionality, 
and session-level service management (so users' individual login 
services can be handled by the same faculties).

We then took a look at initng. Several points were made against initng's 
code quality, and it came to light that of the two people there who had 
attempted to use initng (myself being one of them) neither had actually 
gotten it to work. The only real advantage to moving to initng at the 
moment was parallelization, which most agreed would not result in a 
large gain in boot time. The room agreed to strike initng from the list 
of options.

We were left with Upstart and rrn. I explained the basic structure of 
rrn, a parallelizing service starter that would drop into the current 
init system somewhere within /etc/rc. One of the design goals had been 
not to replace the original sysvinit daemon, which I had been told was 
desirable in a new init system, but no one in the room really felt 
compelled by this. I also detailed how rrn might plug into dbus to 
notify the system about service activations and respond to activation 
requests by being installed as an on-demand dbus service. I pointed out 
that actual service management was unfortunately impossible from this 
stateless design pattern. The room seemed intrigued by the initkit 
standard, and the fact that Upstart would likely be the first to realize 
new features in it. Being on board with a standard was generally 
preferred to creating another NIH product, and rrn's design, it was 
admitted, would be hard pressed to adopt the full set of upstart's 
features. There was a little amusement when I, rrn's author, was the one 
who pushed to strike it. I pointed out that rrn was coded to meet a spec 
I had been told had been agreed upon by the community, and that I had no 
personal stock in the architecture itself.

With the other new choices gone I put SysV back up on the board, but 
most seemed excited about the new features in Upstart. We talked about 
migration path, and I pointed out that Upstart's ability to behave as a 
sysv compatible init daemon meant things could be done incrementally and 
the initial change could take place easily. We agreed on Upstart, and I 
promised to start packaging it the next day. I went to Spot's talk on 
RPM packaging, then the talk on Func, I had CentOS birthday cake, and 
then I went out and proceeded to get what Jon Stanley described as "very 
drunk."

--CJD

[Paul W. Frields]

On Wed, 2008-01-23 at 18:45 -0500, Casey Dahlin wrote:
>  I was hoping the video tape of the session would be out before now
> (if 
>  anyone has it, haaalp!), but here's roughly what happened: 
Just so everyone knows, I taped this one, and the tape went to Colby.
He has a LOT of video he has been working on at a fast and furious pace.
Sorry for the lateness of this reply.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
           Fedora Project: http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug