Plan for tomorrows (20080124) FESCO meeting

[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