[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Plan for tomorrows (20080124) FESCO meeting



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]