[Nut-upsdev] Asking hard questions about the NUT architecture

[Eric S. Raymond]

I've spent the better part of two working days reading the NUT code and 
documentation and thinking about typical modern use cases for the software.  
I'm now questioning whether I want to get any further involved with this 
project, because it seems to me that the codebase is a huge and complicated
pile of machinery mainly aimed at solving problems that no longer matter.

I could be wrong about this, and I'm posting to nut-dev rather than simply
folding up my tent and stealing off into the night because I count on the
people here to demonstrate my error if I am wrong.  But the more I look at 
the architecture, the more I feel like I've dropped through a time-warp
back to 1997, or even 1987.

TROUBLING QUESTIONS:

Let's start with a simple question that strikes at the root of my discontent: 

1. In an era when file systems are normally journaled and hardened so they 
recover clean from power failures, what point is there in having your UPS
initiate a controlled shutdown N seconds beforehand?

I sure don't see enough of one to justify a multi-layer architecture
involving three concurrent processes, four configuration files, and a
partridge in a pear tree.  NUT, as it is now, seems to me to be a
textbook case of massive overengineering and overkill based on
outdated assumptions.

One possible reply is that filesystem hardening sometimes fails.  But
that objection implies the right solution, which is to fix the
filesystem hardening rather than messing around with compensatory
kludges in userspace.  At modern disk-write speeds there is plenty
of time for journaling OS buffers between SIGPWR and when the heads 
no longer get juice.

Now I'll anticipate another possible reply: even if modern OS/filesystem
layers have made UPS-controlled shutdowns rather pointless, there's
still some case for NUT as a tool for logging the state history of
your powerlines and the UPS itself. Under this assumption, upsmon and
its config files would go away but there would still be a role for
upsd and the drivers.

The rest of this note will be founded on this assumption, because
without it NUT would be *entirely* pointless.

Which brings me to my next question: 

2. Why should we care about contact-closure UPSes any more?  

NUT carries around a huge load of tools and documentation designed
for a class of UPSes that can't be health-monitored.  All they can
do is initiate shutdown before the actual power drop, which as I've 
argued above is nowadays unnecessary.

It follows that NUT could drop all support for contact-closure and
"dumb" UPSes tomorrow and it wouldn't make a damn bit of difference
to anybody, at least nobody in the Linux world.  Ext3 is everywhere
now, and the odds that Linux distros will drop back to a non-hardened
filesystem in the future are nil.

And that brings me to my third question:

3.  Why should we care about 'smart' serial UPSes any more?

I've already shown that supporting dumb UPSes is silly under modern
conditions.  Supporting anything RS232, in particular smart serial
UPSes, seems almost as pointless in 2007.  USB UPSes are ubiquitous
and cheap; when I recently went shopping for a UPS I found a
USB-capable unit for $29.99.  Belkin no longer manufactures any
RS232-only units at all and APC hasn't shipped a new RS232-only design
since at least 2004.

And there are good reasons to drop RS232 if it's only a legacy feature.
Supporting RS232 greatly complicates the NUT codebase, documentation,
and installation procedure, because those ports are hard to configure
and don't announce themselves at device-connection time.

Concentrating on USB devices would implications that are user-visible.
In particular, it should mean the entire manual-configuration
apparatus of NUT (everything in /etc/nut) could be made to go away.

WHAT SHOULD BE DONE:

I was originally going to recommend the following steps:

1. Drop continuing support for everything but smart USB UPSes.

2. Flush upsd/upsmon and replace them with a simple, single-process
   monitor driven by hotplug requests and with zero configuration.
   (I have this mentally labeled 'nutless'.)

Then Arnaud Quette explained to me about the HAL abstraction work.
That seems to be heading in the right direction, which is zero
configuration and simply making the status messages from the
UPS available in a well-known place.

So I'm now thinking that. for distribution-packaging purposes anyway, NUT
should break up into three pieces:

1. A drivers kit (ups-drivers).

2. A HAL interface for the drivers (ups-hal, depending on ups-drivers).

3. For non-HAL environments, the aforementioned zero-configuration monitor
   driven by hotplug requests (nutless, depending on ups-driver).

A good first step would be to at least package the drivers separately 
from upsd and above, and to warn all NUT users that the upper layer
will be going away in the future.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The people of the various provinces are strictly forbidden to have in their
possession any swords, short swords, bows, spears, firearms, or other types
of arms. The possession of unnecessary implements makes difficult the
collection of taxes and dues and tends to foment uprisings.
        -- Toyotomi Hideyoshi, dictator of Japan, August 1588