[Nut-upsdev] some fixes, improvements, and new features (EPO and DYING) for NUT

[Greg A. Woods]

At Sat, 10 Mar 2012 19:12:48 -0500, Charles Lepple <clepple at gmail.com> wrote:
Subject: Re: [Nut-upsdev] some fixes, improvements, and new features (EPO and DYING) for NUT
> 
> 
> I think you made a good point elsewhere, though, that developing
> control software to cover all of these cases is an organic process,
> and in that sort of development model, you sometimes have to borrow
> certain features for a little backwards compatibility.
> 
> At the moment, the only two flag combinations which will cause a
> released version of NUT's upsmon to shut down are "FSD" and "OB
> LB". Considering how many distributions still carry NUT 2.2.x and
> 2.4.x, it may be a while before they catch up to these newer shutdown
> flags. Hence my suggestion of FSD plus something more specific
> (possibly including ups.alarm values) to indicate what is going on,
> while still sending an unambiguous shutdown signal to both old and new
> upsmon clients.

I think you have things backwards.

If you drop a in new driver, which includes my new features, on an older
install, then all will be fine.  Even if the user then mistakenly tries
to make use of the new "maxtemp" feature, for example, nothing bad will
happen, but of course the older system will not be able to respond to
the "DYING" status from the driver -- it will simply ignore it.

On the other hand if you upgrade all the infrastructure programs then
presumaly you'll upgrade all the drivers too.  In theory you don't have
to upgrade all the drivers, so long as you don't try to make use of the
new "EPO" command, but not upgrading the driver programs in sync with
the rest of the infrastructure programs must be declared as an
unsupported and unsupportable scenario.

That's exactly why I didn't fiddle with the meaning of "FSD" in any way.

I added two new independent features to meet new unique requirements.

Note that I personally would NEVER EVER want to actively declare support
of the scenario where a driver program can be independently upgraded
from the rest of the system, especially not for a volunteer managed
open-source product.  I'd want to be making a serious profit before I
promised that kind of extra work and overhead to support a customer.

The kinds of backwards compatability I was refering to had only to do
with external interfaces to the system, especially command-line
interfaces which operators may have become familiar with.

As far as evlolving internal protocols, the reasons for wanting to be
careful are not to explicitly support mis-matched installs, but rather
to prevent catastrophic failures in case admins accidentally create
mis-matched installs.

I don't ever want to support mis-matched installs -- I just want to make
sure the system will fail to a safe state in the case where there is an
accidental mis-matched install.

In order to do that though we should first discuss how to put explicit
version identifiers into the internal protocols.  I didn't expect I
would be able to do that all in the span of adding support to meet my
new unique requirements, so I designed changes to the internal protocols
in such a way that they would be independent of existing features.

Note that what I've just said here is to be added to what I've already
said about the need to avoid overloading identifiers in protocols and to
avoid removing or usurping useful features.  Overloading "OB+LB" with
strange new meanings is bad. Overloading "FSD" with new meanings is
bad.  Allowing drivers to set "FSD" instead of inventing a new state
that communicates a new meaning from the device is bad.  Never try to be
too conservative in designing a protocol, and especially not when
extending the design of an existing protocol.  If a driver is to report
an impending shutdown that was initiated out-of-band (e.g. by SNMP or
SSH or telnet or whatever) then a new "being administratively shut down"
status needs to be invented for that purpose so that it's clearly
distinct from the current meaning of "FSD" initiated from upsmon.

-- 
						Greg A. Woods
						Planix, Inc.

<woods at planix.com>       +1 250 762-7675        http://www.planix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120311/7b4a79b5/attachment.pgp>