Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: > It's funny that you mention MGE PSP here, since except for the > shutdown timer (reason explained in the FAQ), NUT already provides > *all* functionality it has (including shutdown based on charge and > runtime). What you may be missing is the fact that this requires > setting values on the UPS through the 'upsrw' command to control the > level when the UPS will decide the battery is low. As far as I remember in PSP there are two different regulations, battery charge level that triggers system shutdown and battery charge level that set the "low battery" state. I suppose it uses the first one that occurs. If I'm not wrong. > What we currently > don't have, is multiple decision levels, but this is something that > will be dealt with through the use of virtual UPS devices that are > accessible through the regular interface. Ok, I've understood now, sorry for not understanding before. It's definitely a good idea, the best one, that solves all these aspects. I think you answered all my questions, thank you. And sorry for being boring. Regards, Marco Chiappero ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero : >> Please elaborate here, because as far as I know we already have this >> (the 'upsd' server). > Please read the last mail from Gabor, his idea it's really close to > mine. To me clients have to be as "stupid" as possible (requiring almost > no configuration) and simply obey to commands issued by the server. This > means that clients shutdown configuration has to be done on the machine > controlling the UPS(es). This way it is the server (connected to the > UPS) that allows someone to use the UPS it owns for the time it > considers fine, it is not a client that tells the server how much it > wants to stay up (a slave upsmon works this way, right?). If you run the upsmon master on the same box as the upsd server, all upsmon slaves connected to the same UPS will shutdown at the same time as the upsmon master. So effectively, you already have a centralized setup if you configure things properly. There is absolutely no need to run 'upssched' on every client if they should all go down at the same time, just run it on the master and you'll be fine. The only thing that remains is that we need different 'virtual' UPSes that can be shutdown at different battery.(charge|runtime) levels and you have pretty much exactly what Gabor describes. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Marco Chiappero : > This would be useful too, but I would be happy enough just having > different shutdown moments based on timer|charge|runtime as apcupsd and > MGE's psp[1] do natively (and as it should be)! It's funny that you mention MGE PSP here, since except for the shutdown timer (reason explained in the FAQ), NUT already provides *all* functionality it has (including shutdown based on charge and runtime). What you may be missing is the fact that this requires setting values on the UPS through the 'upsrw' command to control the level when the UPS will decide the battery is low. What we currently don't have, is multiple decision levels, but this is something that will be dealt with through the use of virtual UPS devices that are accessible through the regular interface. >> In that case, put these scripts on a network drive. They don't have to >> live in /etc/ups (or whatever is compiled in). > Obviously you can do it, but it's not a much better solution. Having to > set up a file server to accomplish what, in my opinion, NUT should do > natively it's certainly not a solution. That depends a lot on your configuration. If you already have many more or less identical clients on your system, chances are that this file server will already source the configuration for these systems. I know of quite a couple of large installations where NUT is used where this is the case and this is quite a workable setup. [...] > 1) different shutdown criteria We already have that if the UPS supports it. If it doesn't support it, we don't and won't do that. There is far too much crappy UPS hardware around to add this for units that don't support this natively. > 2) different shutdown time points This will be added but is currently lacking development time and attention. > 3) automatic restart management / automatic programmable outlet power on We won't add #2 without #3. > The third is not required for implementing points 1 and 2. Not at all. Without this, unattended shutdowns are just not an option, which is the base of NUT. > The first one is absolutely the most important and already present in any UPS > tool I've seen. See above. For devices that support this, NUT already has this. If I remember correctly you have a MGE Evolution 650 and I know that this is supported (for a couple of releases already). What is much more important than the issues you raise, is the fact that configuration of NUT is much too complicated at the moment. Many people simply give up because of the overwhelming amount of configuration required to setup simple monitoring of their UPS. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Citeren Gabor Gombas : > The first step would be to have a _central_ way to manage when to shut a > specific class of clients down. Having to muck with upssched scripts on > every client just does not scale. IMHO the clients should just say > "hello, I'm of class X" when logging into the UPS, and it should be > upsd's job to say "clients of class X start to shut down NOW, everyone > else wait". This would still require configuration on the part of the clients to set the class. But I agree with the fact that this should be managed in a centralized way. I intend to do this by adding 'virtual' UPS devices that clients can connect to in the usual manner. By doing so, the interface to existing client applications (not only the ones we provide) remains intact. So something like big-...@example.com (actual UPS) @example.com (virtual UPS) In this case, clients can connect to either of the above (or more than one), which will look to them as a 'real' UPS. All the power sequencing would be handled on the server, including the decision to shutdown a certain virtual UPS. Doing so effectively means that from the moment this is added, all existing clients can start using this. > Being able to turn clients that were logged in to the UPS when their > shutdown was ordered back on is the next logical step after the above, > but for a start I'd be happy with the shutdown part. Noted. If you're not already subscribed to the nut-upsdev mailinglist, please do so, since usually changes like the above will be announced there first. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: > Citeren Marco Chiappero : > >>> And "centralized" is a very important keyword here; having >>> to modify upssched scripts on dozens of machines when the plan changes >>> is a real PITA. >> I agree, and that's the reason why I said there is a need for a >> director. It takes care about settings and actions, clients should only >> obey and possibly show UPS informations. It's also a metter of role: the >> system managing the UPS is the only one that should decide and control >> who can keep running and for how long, not the server administrator (and >> maybe you're not even the server owner or admin)! >> This should also make the powershare feature easier to implement since >> the computer controlling the UPS knows everything. > > Please elaborate here, because as far as I know we already have this > (the 'upsd' server). Please read the last mail from Gabor, his idea it's really close to mine. To me clients have to be as "stupid" as possible (requiring almost no configuration) and simply obey to commands issued by the server. This means that clients shutdown configuration has to be done on the machine controlling the UPS(es). This way it is the server (connected to the UPS) that allows someone to use the UPS it owns for the time it considers fine, it is not a client that tells the server how much it wants to stay up (a slave upsmon works this way, right?). Ok, how to achive this? Writing two different programs, client and server, is an idea, but we can think of something more modular: an hardware layer (eg. nutupsdrv), a communication and "action maker"/execution layer, and a decision layer managing shutdown orders. So, on the client side just the second layer is needed, it takes care of speaking with the server (for UPS readings too [1]) and executing shutdown and/or notify commands received by the server. Note that on this side you have to configure just a few settings. On the server side we need all the stack of components, the decision maker on top of the communication and execution layer, in turn on top of the hardware layer. The decision layer reads the configuration file(s) containing shutdown policies for all the machines (or group of machines) it can assume to control, and then, when needed, it passes orders to the lower layer. Again on the server side, the communication and execution layer dispatches informations between the hardware, the "brainless" clients and the "brain" itself. Note that this layer can be the same on both clients and server. Let's suppose we already powered down some clients and power is back, the mean layer (which is on top of the hardware) notify the event to the upper decision layer, this one orders to start an action such as executing script or restoring power on a specific programmable outlet, maybe after some time or when enough charge is reached. If "low battery" level is reached, then we trigger shutdown for everyone is still up. Well, I'm not experienced and maybe it's not a good approach, but I like it. You can think it's better to have clever clients as it is now, but at this moment upsmon is lacking the features already discussed. However, just considerations and comments are welcome. Regards, Marco Chiappero [1] The server can offer some services or information to the clients. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ordered shutdown
Arjen de Korte ha scritto: [waking up from shutdown before battery exhaustion] > With whatever strategy you use, you need to be able to send some kind > of command (power on, WOL magic, whatever) at the right time. Yeah, but I can't see any real difficulty. What does NOTIFTCMD stand for? Maybe the server (if client aware) could let the user choose some more options or predefined actions, shouldn't be difficult to implement. I can't see why this solution is worse than having to deal with upssched and its script, which I consider much a dirty hack. > Shutting > down is 'easy' when there is one point in time where you can decide to > shutdown whatever is connected (what we have now) possibly with some > kind of sequencing and then power cycle the UPS. What people are > asking now, is to have multiple decision moments Exactely > and for each one you > must guarantee that you're able to return to the normal state with as > little impact on other systems. This would be useful too, but I would be happy enough just having different shutdown moments based on timer|charge|runtime as apcupsd and MGE's psp[1] do natively (and as it should be)! Maybe there is a person in front of the computer you powered down, that can switch it on. Why not to let the people choose the strategy they prefer? > In that case, put these scripts on a network drive. They don't have to > live in /etc/ups (or whatever is compiled in). Obviously you can do it, but it's not a much better solution. Having to set up a file server to accomplish what, in my opinion, NUT should do natively it's certainly not a solution. To sum up, in priority order: 1) different shutdown criteria 2) different shutdown time points 3) automatic restart management / automatic programmable outlet power on The third is not required for implementing points 1 and 2. The first one is absolutely the most important and already present in any UPS tool I've seen. Beyond these requests, I believe a better design is required to address some other needs, discussed in the previous mails, but I know that it is something that, first of all, you should feel it's right, and it's not always possible to modify a project. However I like to discuss about these ideas. Just my opinion. Regards, Marco Chiappero [1] Yes, a normal user can choose pointing and clicking, while upssched is considered a complicated option for nerds. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
