Nut upsdev - Oct 2009 - MGE NMC and NutShutdownModule (and other stuff)

Hi all,

some time ago I bought at discount price a NMC for managing a few
computers using the programmable outlets features available on my MGE
Evolution, unuseful otherwise (ATM). However, expecially for my server
machine, I don't like very much the NSM client provided by MGE/Eaton and 
I'd rather use only NUT from my distribution. So, looking at the 
netxml-ups driver, I started adding some code into the mge-xml 
subdriver, to power off the system whenever the NMC tells it's time to 
go down. Although the code is still a stub and incomplete, it seems to 
work fairly well with my own setup. However I'd like to know, first of 
all, the best way to integrate this functionality in NUT, and, after, 
whether there is some interest in including this feature in the upstream 
package.
Currently I added a management struct containing (almost) all management
data, including three (start/update/stop) callbacks called from
upsdrv_initinfo(), upsdrv_updateinfo() and upsdrv_cleanup(). Once the
subdriver is subscribed and connected with the NMC (currently using the
connected/tcp protocol only), it periodically reads xml alarm messages,
mainly the ones that indicate mains loss and low battery state for that
specific outlet (obviously a few driver specific parameters are needed).
However including the NSM functionality in this way some questions came
into my mind... so let's talk about them separately.


Topic #1: right place for NSM

As already said the temporary solution I adopted seems to work fine, it
is small and easy; at the moment the netxml-ups.c file looks a bit MGE
specific but it's not a big issue right now. The real downside is the
single UPS configuration support, there is no way to support redundant
configurations. How to deal with them? I see mainly one solution (above
writing something over upsd), a new driver for a "virtual" UPS as
result
of one or more UPSes connected in a single or multiple UPSes
configuration. It should work very much like NSM: it should read the
configuration schema from the device_path var, retrieve basic data from
upsprop.xml summary page for every single UPS included in the
configuration file, calculate somehow the total runtime, load and so on,
dealing with NMC communication too, as NSM does. So, upsmon would just
monitor this virtual UPS, while for UPS specific data the netxml-ups
driver can be used. However some more effort and knowledge about the NSM
and NMC protocols is required (Arnaud, maybe you can help somehow?).
Moreover I just own a simple MGE Evolution, I've never dealt with
different scenarios.
Well, I don't expect much interest about a NutShutdownModule, but if I'm
wrong here I am for discussion. Suggestions are welcome. :)


Topic #2: new RunTimeToShutdown variable

Reading both alarm messages from NSM and the summary page I noticed the
System.RunTimeToShutdown/System.Outlet[2].RunTimeToShutdown/
System.Outlet[3].RunTimeToShutdown variables. If I'm not wrong it is
intended to provide the per outlet available runtime before sending the
BelowRemainingCapacityLimit/shutdown indication to the client. It would
not be bad to show this reading too. Do you think is ok to add the
outlet.runtime/outlet.X.runtime variables to cmdvartab, even though is a
MGE NMC specific value?


Topic #3: text messages system

Some alarm messages sent by the NMC contain some human readable text
(currently discarded). In the EATON/MGE NSM client these text strings
are stored for logging. So I asked myself why not to have such behaviour
in NUT as well? I know, it looks a bit strange, but let me explain a
little bit better. The basic idea is that any single UPS comes with
fixed buffer containing MSGs (or a list of MSG), human readable and HW
specific info text only, above the already present VARs and CMDs. So,
any driver can generate these messages, just for informational purpose,
and propagate them "upstairs" like they were VARs. It recalls me the
hard drive SMART, where along with variables and commands you have some
fixed logging text structures to be read by man. Once stored they could
be read through upsd. Let's consider a desktop computer, wouldn't be
good to have such messages shown, for example, by a notification daemon
(such as the one in ubuntu)? Or sent to a mailer, logger, whatever?

I know, neither the NSM idea nor this last one is going to interest you,
but suggestions don't hurt. :)


Regards,
Marco

Citeren Marco Chiappero <marco op absence.it>:
> some time ago I bought at discount price a NMC for managing a few
> computers using the programmable outlets features available on my MGE
> Evolution, unuseful otherwise (ATM). However, expecially for my server
> machine, I don't like very much the NSM client provided by MGE/Eaton  
> and I'd rather use only NUT from my distribution. So, looking at the  
> netxml-ups driver, I started adding some code into the mge-xml  
> subdriver, to power off the system whenever the NMC tells it's time  
> to go down. Although the code is still a stub and incomplete, it  
> seems to work fairly well with my own setup. However I'd like to  
> know, first of all, the best way to integrate this functionality in  
> NUT, and, after, whether there is some interest in including this  
> feature in the upstream package.
Considering the latter, maybe. It all depends how well this fits into  
the existing driver-server-client architecture and from what I  
understand from the above, it looks like you're basically creating an  
integrated driver/client that bypasses the upsd server. I certainly  
see the advantages of this in a homogenous setup (where you only have  
NMC capable MGE units available), but I fear that this will drift far  
from the more or less universal setup we have now and as such I'm not  
too thrilled about including this right now.

Also note that a setup where multiple clients connect to the NMC  
doesn't scale particularly well. The number of concurrent connections  
to the NMC is limited, depending on the model you have. The  
installation for which the netxml-ups driver was originally written  
has over 2000 clients attached, way beyond what is supported by any  
version of the NMC.

Having said that, I'd still be interested in looking at your changes,  
to see if there are things that we might use in the netxml-ups driver  
we have. Feel free to attach what you made and we can work from there.  
I see no reason why we couldn't create a branch in the SVN tree to see  
if we can work out something that fits in the existing architecture.

Best regards, Arjen

PS  If you want to control multiple outlets of your UPS and want a NUT  
only solution, have a look at the 'clone' UPS driver that is available  
now.
-- 
Please keep list traffic on the list

Citeren Marco Chiappero <marco op absence.it>:
>> 1) Both netxml-ups drivers can't connect at the same time via NSM  
>> to their respective NMC's. We must have two instances of the  
>> netxml-ups driver running (to provide access to all variables in  
>> the UPS) and as far as I can see we can only accommodate one NSM  
>> client (due to the listening socket that is needed for the callback  
>> from the NMC's) per host.
> No. This would be a problem when using the UDP protocol, that I  
> didn't implemented, where there is a single socket reading broadcast  
> messages sent by the UPSes. In such case we would need the driver  
> approach (but that breaks the single_UPS--single_driver_instance  
> design [1]) or the new deamon approach (that shall take care about  
> talking to the NMC directly). Otherwise this is false and you can  
> run every netxml-ups instances you want (or run UDP in a single UPS  
> scenario only).
This is what I misunderstood. I though the driver would have to open a  
socket for listening and wait for a connection *from* the NMC (like  
the NSM client that is provided by Eaton), but apparently this  
mechanism isn't used and instead it opens a connection *to* the NMC.  
In that case, you would indeed be able to run multiple NSM enabled  
drivers in parallel. The only objection that remains then is that  
putting this in the netxml-ups driver is probably not a good idea. It  
would be quite a burden on the little micro controller in the NMC  
66102, since it would also require parsing the full XML data for each  
instance. If you'd make this NSM driver a separate one however, I'd be  
all for it.

A separate (new) driver would also deal with the case where you'd  
define a meta UPS (like the globalups example you wrote about earlier)  
where neither of two (or more) individual UPS devices that would be  
part of this meta UPS could be the sole source of information like  
voltages, currents and battery charge. In such case, you'd only be  
able to tell whether the clients that connect to that meta UPS would  
need to shutdown or not. All remaining info (for logging purposes)  
would need to come from drivers that connect to a single UPS device  
(however, that probably wouldn't be relevant to the clients that  
connect to the meta UPS anyway).

Sorry for being such a PITA, but I prefer to get a clear picture on  
what the pros and cons are before people invest time in writing  
something, only to find out along the way that they have to start over  
again later.

Best regards, Arjen
-- 
Please keep list traffic on the list

Citeren Marco Chiappero <marco at absence.it>:
> I managed to get twice connected at the same time from the same  
> machine to a single UPS using different hostnames, so it's  
> definitely not an IP based check (at least here with 66102 / EC).
Never mind. The alarm messages are not bound to a specific outlet, but  
are sent to all NSM clients that are connected. Which means that a  
single connected driver can handle the alarm messages for all outlets.  
Basically, the NSM subscription allows us to reduce the polling  
interval to 1 minute or so, without risking high latency for alarms  
(since they will be pushed from the NMC when they occur).

It looks like the connected clients need to determine themselves  
(based on the timer values) when to shutdown the host they are running  
on. Apparently, the decision when to shutdown is made by the NSM  
client, this is not signaled directly by the NMC.

This means that we can probably just connect to the main outlet and  
fix the shutdown delay and shutdown timer to the CENTRALIZED  
configuration without losing anything. One can still override these  
settings per outlet, by changing values via the NMC web configuration  
interface. Adding of the NSM alarms can therefor be done without any  
additional configuration settings, which is preferred for ease of  
setting things up.

Best regards, Arjen
-- 
Please keep list traffic on the list