Nut upsdev - Jul 2011 - [RFC] PowerChain: add LIST POWERCHAIN and GET POWERCHAIN to the client (network) protocol

Hi,

this is the 2nd part of the PowerChain RFC.

2011/6/13 Arnaud Quette <aquette.dev at gmail.com>
> As already presented, the links below will describe in details the
> PowerChain notion:
>
> https://wiki.ubuntu.com/ServerOneiricInfraPower
> https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20design
> https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20implementation
>
> The idea here is to add a new variable, named 'device.parent', so
that
> every device can reference its parent.
>
> I propose to add a new entry in docs/nut-names.txt, with the following
> content:
>
> | device.parent  | Reference to the parent node in the PowerChain (NUT host
> format)         | ups1 at localhost
>
> A new chapter will be created in the user manual, to describe the usage of
> this feature.
>
> Note that there will be a separate mail to discuss implementation details.
>

I've been thinking a bit more on PowerChain design and implementation.
it appeared that it was better to have upsd managing this, since this notion
is linked to an ups.conf parameter (device.parent, from the previous RFC),
consolidated at a higher level.

The idea is to have upsd reading ups.conf (as it already does), and creating
the powerchain(s) structure from the existing 'device.parent', to then
serve
this upon request from the client layer.

The other possibility would have been a pure client side implementation,
that uses 'LIST UPS', along with queries to get device.parent from the
various devices found. But it's really sub-optimal in terms of performance,
and not well placed for the above (upsd related) reasons.

I thus propose to add the 2 following network protocol commands:

8<----------------------------------------------------------------------------------------------------

(GET) POWERCHAIN
~~~~~~~~~~~~~~~~~~

Form:

    GET POWERCHAIN <device name>
    GET POWERCHAIN ups1

Response:

    POWERCHAIN <device name> ; ... ; <device name>
    POWERCHAIN psu1 ; ups1

This returns the full PowerChain list that contains '<device
name>'.
If this device is not part of a PowerChain, '<device name>' is
returned.

(LIST) POWERCHAIN
~~~~~~~~~~~~~~~~~~

Form:

    LIST POWERCHAIN

Response:

    BEGIN LIST POWERCHAIN
    POWERCHAIN <device name> ; ... ; <device name>
    ...
    END LIST POWERCHAIN

    BEGIN LIST POWERCHAIN
    POWERCHAIN psu1 ; outlet.1:pdu1 ; ups1
    POWERCHAIN psu2 ; outlet.1:pdu2 ; ups2
    END LIST POWERCHAIN

'<device name>' are names from ups.conf.

This can be used to determine whether PowerChain is supported
or not on this host.  This is also the way to obtain the list of all
powerchains for the given host.

Clients which perform a PowerChain discovery process may find this useful.

8<----------------------------------------------------------------------------------------------------

The above is more coherent and efficient, doesn't impact compatibility (even
in libupsclient) while proposing this new feature.

Note that I will submit a 3rd RFC for PowerChain, to deal with monitoring
(upsmon) integration.
But since this one has a lower priority (PowerChain step 2), it won't be
before some time.

Comments, questions and ideas welcome, as usual.

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110726/6a702021/attachment.html>