[Nut-upsdev] NUT-NG (was: ideas for a new UPS infrastructure)

[Arnaud Quette]

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