[Nut-upsuser] ordered shutdown

[Marco Chiappero]

Arjen de Korte ha scritto:
> Citeren Marco Chiappero <marco at absence.it>:
> 
>>> 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.