Nut upsdev - Mar 2006 - NUT-NG (was: ideas for a new UPS infrastructure)

some notes:
- for this kind of discussion, please cc upsdev list (I've added it),
- I've fwded the full thread to upsdev,
- this subject is part of what I call NUT-NG (next gen.), aka nut 3.0...
- I'll study in depth the thread this week end, and complete with my
thoughts,
- thanks to Stan to have put us all in touch

Arnaud

2006/3/10, Stanislav Brabec <sbrabec@suse.cz>:
> Hallo NUT developers.
>
> In last days, I have learned a much about UPSes, NUT, udev, HAL and
> D-BUS, powermanager and found some ideas for a new design of NUT.
>
> My original question was: How to inform desktop users about failing
> power.
>
> The research shows, that there are two disconnected infrastructures -
> one is NUT, second is powermanager. One was originally designed for UPS
> management, second was originally designed for power management of
> notebooks, but later was extended with a basic UPS support.
>
> There is a short summary, what is the current status (it can be
> inaccurate). At the end I will show my idea of future NUT and
> powermanager improvements.
>
> Don't ask me for details, I don't know more. But I am Ccing this
mail to
> the gnome-power-manager developer, who can say you more about
> powermanager.
>
> Duplicated parts of code:
> - shutdown policy
> - battery policy
> - USB HID UPS support
> - udev stuff
> - user alerts
>
> Only in NUT:
> - network UPS support
> - more UPSes, more machines policy
> - advanced UPS manipulation (temperature, voltage, EEPROM programming?)
> http://www.networkupstools.org/features/
>
> Only in power manager:
> - integration with power management (ACPI, processor speed, suspend on
> idle...)
> - desktop power management (client applications can initiate shutdown)
>
>
> NUT does:
>
> upsdrvctl starts drivers for current UPS
>
> upsd listens to drivers started by upsdrvctl and provides network
> interface
>
> upsmon listens to local an network UPS devices
>
> third party clients listen to upsd and display information
>
>
> Powermanager does:
>
> udev detects nev USB HID device
>
> HAL analyzes it, recognizes it as HID UPS, starts hald-addon-hid-ups,
> adds UPS to list of know devices
>
> hald-addon-hid-ups send signals to HAL
>
> HAL sends signals to D-BUS
>
> Desktop client listen and sends signals to D-BUS and display messages
>
> Power manager listens and sends signals to D-BUS and decides about ACPI
> changes, suspending, alerts or shutting down.
>
>
> Proposal for NUT:
>
> udev provides info about autodetectable UPSes and HAL starts enhanced
> hald-addon-hid-ups (which will contain all features of hidups)
>
> upsdrvctl-hald-addon reads configuration and starts not detectable
> drivers for current UPS and provides HAL device
>
> upsd-network-hald-addon listens to network UPSes and provides HAL device
>
> upsmon listens to D-BUS and provides interface for grafical old
> fashioned NUT clients
>
>
> Proposal for powermanager:
>
> Desktop clients must support more UPSes
>
> Power manager must implement advanced UPS logic from upsmon (how many
> UPSes must be running, signalling networked computers to shutdown,...)
>
>
*********************************************************************

2006/3/10, Richard Hughes <hughsient@gmail.com>:
> On Fri, 2006-03-10 at 01:11 +0100, Stanislav Brabec wrote:
> > Hallo NUT developers.
>
> adding in g-p-m devel as a cc.
>
> > In last days, I have learned a much about UPSes, NUT, udev, HAL and
> > D-BUS, powermanager and found some ideas for a new design of NUT.
> >
> > My original question was: How to inform desktop users about failing
> > power.
> >
> > The research shows, that there are two disconnected infrastructures -
> > one is NUT, second is powermanager. One was originally designed for
UPS
> > management, second was originally designed for power management of
> > notebooks, but later was extended with a basic UPS support.
>
> Well, to be strictly true, gnome-power-manager supports classes of
> devices of type battery, so we can apply user policy on power state and
> power events.
>
> > There is a short summary, what is the current status (it can be
> > inaccurate). At the end I will show my idea of future NUT and
> > powermanager improvements.
>
> I think this is very required, and thanks for bringing this to issue.
>
> > Don't ask me for details, I don't know more. But I am Ccing
this mail to
> > the gnome-power-manager developer, who can say you more about
> > powermanager.
> >
> > Duplicated parts of code:
> > - shutdown policy
> > - battery policy
> > - USB HID UPS support
> > - udev stuff
> > - user alerts
> >
> > Only in NUT:
> > - network UPS support
> > - more UPSes, more machines policy
> > - advanced UPS manipulation (temperature, voltage, EEPROM
programming?)
> > http://www.networkupstools.org/features/
>
> Yes, this can be trivially added to HAL as device properties, such as
> ups.temperature (int) and battery.voltage (int) and as methods such as
> TurnOffTheBeepySound(bool) :-)
>
> > Only in power manager:
> > - integration with power management (ACPI, processor speed, suspend on
> > idle...)
> > - desktop power management (client applications can initiate shutdown)
>
> Yes, it integrates all the power infrastructure so that it's cross
> desktop, and "just works" out of the box.
>
> > Powermanager does:
> >
> > udev detects nev USB HID device
> >
> > HAL analyzes it, recognizes it as HID UPS, starts hald-addon-hid-ups,
> > adds UPS to list of know devices
> >
> > hald-addon-hid-ups send signals to HAL
> >
> > HAL sends signals to D-BUS
> >
> > Desktop client listen and sends signals to D-BUS and display messages
>
> And apply policy....
>
> > Power manager listens and sends signals to D-BUS and decides about
ACPI
> > changes, suspending, alerts or shutting down.
> >
> >
> > Proposal for NUT:
> >
> > udev provides info about autodetectable UPSes and HAL starts enhanced
> > hald-addon-hid-ups (which will contain all features of hidups)
>
> Yes, there was talk of this some time back to add methods such as
> TurnOffTheBeepySound() and add advanced properties like temperature.
> This is pretty trivial to do in the existing addon.
>
> > upsdrvctl-hald-addon reads configuration and starts not detectable
> > drivers for current UPS and provides HAL device
>
> Yes, using FDI files you can launch addons. Thats how the existing addon
> is launched.
>
> > upsd-network-hald-addon listens to network UPSes and provides HAL
device
> >
> > upsmon listens to D-BUS and provides interface for grafical old
> > fashioned NUT clients
>
> I'm not sure how to integrate network UPS's into the current HAL
> framework, as hardware not attached to the computer is sort of anti-HAL.
>
> > Proposal for powermanager:
> >
> > Desktop clients must support more UPSes
> >
> > Power manager must implement advanced UPS logic from upsmon (how many
> > UPSes must be running, signalling networked computers to shutdown,...)
>
> Yes, g-p-m needs to do more for UPS. I'm considering a "Running on
UPS"
> tab in the preferences so we can assign things like emailing the admin,
> and running arbitrary scripts, having options such as:
>
> [x] Beep when on UPS.
>
> But I guess other people might have better ideas.
>
> Richard.
>
*********************************************************************

2006/3/10, David Zeuthen <david@fubar.dk>:
>
> Hi,
>
> I'm the HAL maintainer.
>
> On Fri, 2006-03-10 at 00:29 +0000, Richard Hughes wrote:
> > > Only in NUT:
> > > - network UPS support
>
> See below
>
> > > - more UPSes, more machines policy
>
> Yes. g-p-m relies on HAL to get this and I don't think this should
> change for UPS's attached via e.g. USB. To give some perspective the
HAL
> support for UPS's is something I wrote in one or two evenings; it's
a
> very simple piece of code
>
> 
http://webcvs.freedesktop.org/hal/hal/hald/linux2/addons/addon-hid-ups.c?rev=1.12&view=markup
>  (yes, this code could need some love.. I know!)
>
> Hence, we only support USB UPS's supporting the HID protocol. I
don't
> really know how many that is (10%, 20%? Only home users?) but I'm
> curious to know :-)
>
> I think it could be really cool to use the code in NUT in HAL since we
> would support a lot more devices. But I'm not really sure how we would
> do that? Does it rely on kernel drivers? Userspace code? etc. I'd love
> to know.
>
> Btw, I'm not sure how we would support UPS on the serial port in HAL.
> One thing about HAL is that we can never have a configuration file
> saying where to look for devices; the whole philosophy about HAL is to
> detect your devices and present the desktop bits with an extremely
> well-defined view. I got some ideas about serial ports if you're
> interested in cooperating; basically I think it's doable the same way
> e.g. Windows lets the user search for a modem on the serial port. I can
> expand on that if you want me too.
>
> > > - advanced UPS manipulation (temperature, voltage, EEPROM
programming?)
> > > http://www.networkupstools.org/features/
>
> I think some of these features may make sense for gnome-power-manager.
> Some of them are probably outside the scope of g-p-m though. That's
> Richard's call I think :-)
>
> > > upsd-network-hald-addon listens to network UPSes and provides HAL
device
> > >
>
> This is indeed possible, but hal-device(1) and the associated D-BUS
> interfaces for creating HalDevice objects in HAL may disappear some day.
>
> > > upsmon listens to D-BUS and provides interface for grafical old
> > > fashioned NUT clients
> >
> > I'm not sure how to integrate network UPS's into the current
HAL
> > framework, as hardware not attached to the computer is sort of
anti-HAL.
>
> I'm not sure HAL should know anything about networked devices... On the
> other hand it does make some sense. But it's a slippery slope.. and how
> would upsd-network-hald-addon even know which UPS's to monitor? Again,
> it can't rely on a configuration file!
>
> Not to flame, but I think it would make sense to take the user
> experience into perspective before discussing technical issues.
>
> How about this instead
>
>  1. gnome-power-manager to include functionality for discovering
>     networked UPS devices. I don't really know how this works but
>     I expect some auth is necessary. Hence, you really want to
>     run this in the desktop session as asking users to edit
>     configuration files is just wrong. If the UPS is discoverable
>     using Zeroconf/Bonjour etc. maybe g-p-m should use Avahi
>     to discover them and prompt the user for auth when it finds
>     an UPS.
>
>  2. Maybe g-p-m should provide UI to share an UPS on the network
>     so other g-p-m instances can monitor it. For this we could
>     indeed use Avahi to publish the information. Then stuff would
>     just work :-) ... Again, I don't know much about how this works,
>     I'm thinking out loud :-)
>
>  3. upsmon to use an interface in g-p-m to get the information
>     about the UPS and provides interface for graphical old
>     fashioned NUT clients. This means g-p-m will have to export
>     some of the info HAL already exports but I think this is
>     cleaner as I don't really want HAL to know about networked
>     UPS's.
>
> > > Power manager must implement advanced UPS logic from upsmon (how
many
> > > UPSes must be running, signalling networked computers to
shutdown,...)
> >
> > Yes, g-p-m needs to do more for UPS. I'm considering a
"Running on UPS"
> > tab in the preferences so we can assign things like emailing the
admin,
> > and running arbitrary scripts, having options such as:
> >
> > [x] Beep when on UPS.
> >
> > But I guess other people might have better ideas.
>
> Richard, that "Running on UPS" tab sounds like a cool idea!
>
> So.. I guess I'm saying that at this point I'm very interested in
the
> driver code from NUT but not so much the other bits. I realize this may
> come across as a bit offensive but I hope you guys are interested in
> cooperating nonetheless. If we need any HAL changes to make this happen
> (for e.g. serial ports) I'm more than happy to do my bit.
>
> We could make UPS support rock with gnome-power-manager [1].
>
> Thanks,
> David
>
> [1] : To be really useful, though, we need to have PolicyManager and
> ConsoleTracker as described here http://blog.fubar.dk/?p=63
> But that will probably happen before GNOME 2.16.
>
*********************************************************************

2006/3/10, Stanislav Brabec <sbrabec@suse.cz>:
> Richard Hughes writes:
> > On Fri, 2006-03-10 at 01:11 +0100, Stanislav Brabec wrote:
> > > Hallo NUT developers.
>
> > > upsd-network-hald-addon listens to network UPSes and provides HAL
device
> > >
> > > upsmon listens to D-BUS and provides interface for grafical old
> > > fashioned NUT clients
> >
> > I'm not sure how to integrate network UPS's into the current
HAL
> > framework, as hardware not attached to the computer is sort of
anti-HAL.
>
> This remembers again to me my initial discussion with Holger Macht. The
> problem is the fact, that noone else can create HAL events. Second
> problem is, that currently all local HID UPSes are considered as
"power
> critical devices" by powermanager. This may not be true (see the
bottom
> of this mail).
>
>
> Random thoughts on remote UPSes in HAL
>
> We can do:
>
> 1. Define conditions, when it is acceptable to add remote devices to HAL
> in such special cases.
> This remote UPS may be de-facto (but also may not) local device, because
> if it goes down, my machine goes down, too.
>
> 2. Clone HAL UPS interface to another D-BUS domain. All applications
> will have to listen to two D-BUS interfaces with the same syntax. This
> is AFAIK ugly, because it requires change of all applications.
> /org/freedesktop/Hal/devices/usb_device_51d_2_AS0333131933_if0_hiddev
>   battery.type = 'ups'
> /org/freedesktop/UPS/nut_network_ups/myserver/mysmartups
>   battery.type = 'ups'
>
> 3. Do both upper mentioned. Define two UPS categories: "UPSes directly
> affecting my machine" (and announce them via HAL), "random remote
> UPSes" (and annonce them via cloned interface).
>
> This may look ugly, but it is logical - desktop tools, power manager
> etc. will use only "UPSes directly affecting my work" from HAL,
admin
> tools can look to both. Even local HID UPS may not affect me.
>
>
> David Zeuthen writes:
> > So.. I guess I'm saying that at this point I'm very interested
in the
> > driver code from NUT but not so much the other bits.
>
> You should be interested in upsmon logic, too.
>
> Example of "bizzare" UPS configuration from
> http://www.networkupstools.org/features/
>
> This machine can run, if at least two two of these three UPSes has
> enough power: "local UPS Smart UPS 1000 hiddev0", "local UPS
Smart UPS
> 1000 hiddev1", "remote UPS spare1 connected to machine
upsfarm". Ignore
> status of "local UPS Back UPS 500 hiddev2", which powers another
machine
> (but this UPS and machine connected to it must be shot down, before this
> server will go down).
>
>

*********************************************************************

2006/3/10, Stanislav Brabec <sbrabec@suse.cz>:
> Richard Hughes writes:
> > On Thu, 2006-03-09 at 20:52 -0500, David Zeuthen wrote:
> > > How about this instead
> > >
> > >  1. gnome-power-manager to include functionality for discovering
> > >     networked UPS devices. I don't really know how this works
but
> > >     I expect some auth is necessary. Hence, you really want to
> > >     run this in the desktop session as asking users to edit
> > >     configuration files is just wrong. If the UPS is discoverable
> > >     using Zeroconf/Bonjour etc. maybe g-p-m should use Avahi
> > >     to discover them and prompt the user for auth when it finds
> > >     an UPS.
>
> Discovering is not yet implemented. But NUT developer think about it.
> Avahi is a good way to do it.
> The rest is implemented. Users can either monitor UPS or control it. See
> the nut configuration files.
>
> But as I wrote in previous mail, it would be nice to discriminate
> between "UPSes directly affecting my machine" and "random
remote UPSes"
>
> > > > > Power manager must implement advanced UPS logic from
upsmon (how many
> > > > > UPSes must be running, signalling networked computers
to shutdown,...)
>
> This logic should be part of powermanager. Most servers don't run
GNOME,
> and desktop policy is very probably simple: one local UPS or one remote
> UPS directly affecting me.
>

On Fri, 10 Mar 2006, Arnaud Quette wrote:
>> Proposal for NUT:
>>
>> udev provides info about autodetectable UPSes and HAL starts enhanced
>> hald-addon-hid-ups (which will contain all features of hidups)
>>
>> upsdrvctl-hald-addon reads configuration and starts not detectable
>> drivers for current UPS and provides HAL device
>>
>> upsd-network-hald-addon listens to network UPSes and provides HAL
device
>>
>> upsmon listens to D-BUS and provides interface for grafical old
>> fashioned NUT clients
As long as it's not breaking stuff that works (ie. support for 
non-latestandgreatestlinuxthingie) I don't see any problems.

However, if generic NUT stuff starts to depend on HAL and whatever I'd 
say that we've kissed portability goodbye. Ie, I want to be able to 
speak to SNMP/serial port-equipped upsen using an AIX box in the 
future too.

The above suggestion sounds like a typical "let's solve this the 
non-portable way because my linux-thingie looks nice". People have 
complained a lot about vendors locking applications in hard-to-port 
API:s (Windows for example), this seems to be exactly the same thing.

If NUT wants to prove itself as THE ups monitoring solution we'll have 
to look beyond the desktop. Ie, don't break the good current design. 
Add helpers for desktop-thingies if needed.


/Nikke - who believes in portable code, not stuff locked into a
          specific environment a la Windows.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  Now go away or I shall taunt you a second time.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=