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

Tue May 29 20:46:52 UTC 2007

Hey,

2007/5/29, Eric S. Raymond <esr at thyrsus.com>:
> 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.

Carlos has perfectly answer. you tend to be too "esr centric" ;-)
I mean, MGE (and others) still sells RS232 UPSs (and is the 2nd ww
mfr, now merging with APC !), many people still uses dumb/smart serial
units. Why should we leave them in the dark?!

focusing on the future doesn't mean erasing the past. We (the NUT
team) are focused on our _users_ and _all_ their needs, whatever
complex / exotic / legacy it is.
You should be in a good position to know that one force of linux /
FLOSS is its ability to support both the legacy _and_ the newest
hardware, in a uniform way.

BTW, get a look on our (soon incomplete) features list:
http://eu1.networkupstools.org/features/

follow up on the future below ...

> 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).

several points you've missed since you came too recently here and not
have digged enough:

1) HAL

Considering that HAL is becoming the de facto standard on our beloved
and main focus systems (linux, *bsd, solaris, maybe others later on),
good efforts have been put there.

A basic implementation (read "something that is as good as on windows
/ OS X") will be shipped with the upcoming 2.2 "Sophie Mina" release.

More features are coming, like DBus methods (to poweroff the UPS,
change its HW settings, ...), along with HAL support for legacy
devices (serial ; discussed with Dave Zeuthen on HAL and NUT), network
support through avahi, ...

And I've already proposed you (feisty) packages that ships only HAL
support (read the four NUT USB driver compiled with HAL bridging, so
not requiering ups{d,mon})
You can otherwise build your own (ln -s packaging/debian debian &&
debuild ... ; I'm sure you're now fluent with this ;-)

I feel like you really have fallen into a time warp, and not have seen
the major updates in NUT since 2 years ;-)

Using MacFly <http://software.inl.fr/trac/trac.cgi/wiki/Macfly> would
btw be a good QA test for NUT!

2) Legacy support

This both includes non HAL enabled systems, and serial (smart / dumb) UPSs

Parts have already been exposed above (user focused, HAL legacy
support) and below (packaging).

NUT's configuration complexity (along with NUT's architecture) allows
to address _any_ kind of setup!

Since we have addressed the mass market with hal support, we can focus
on the remainder : that is to say legacy system and complex / exotic
... systems.

The point on which we're ok is that the configuration is really a mess.
I've add an intern last year to work on creating a lib and a tool to
configure nut easilly and allow the creation of NUT Config GUIs. Note
that the tool can be called by hotplug / udev on non HAL systems.

http://opensource.mgeups.com/projects/nut-config.htm
http://svn.debian.org/wsvn/nut/branches/JD-NewConf/?rev=0&sc=0

This branch still has to be reworked, completed and merged.

> 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.

the plan is now to lobby for including the nut-hal-drivers (providing
hal-ups-support and conflicting with nut) in the base system, without
depending on it. This way, the system will allow out of the box
support for USB devices, while allowing users to install the "classic"
nut

I'm currently building a packagers task force, composed by members of
CentOS, Debian, RedHat, SuSE, *BSD, ... to prepare / apply several
changes to the existing packages, including the above.

welcome to our wonderful UPS world Eric ;-)
as you can see, we don't lack ideas, innovations, nor user focus, but
we really miss time, and manpower for coding, documenting, and
marketing (lobbying, website, ...)

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/