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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
