Hi,<br><br>this is the 2nd part of the PowerChain RFC.<br><br><div class="gmail_quote">
2011/6/13 Arnaud Quette <span dir="ltr"><<a href="mailto:aquette.dev@gmail.com" target="_blank">aquette.dev@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


As already presented, the links below will describe in details the PowerChain notion:<br><br><a href="https://wiki.ubuntu.com/ServerOneiricInfraPower" target="_blank">https://wiki.ubuntu.com/ServerOneiricInfraPower</a><br>



<a href="https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20design" target="_blank">https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20design</a><br>
<a href="https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20implementation" target="_blank">https://wiki.ubuntu.com/ServerOneiricInfraPower#PowerChain%20implementation</a><br><br>The idea here is to add a new variable, named 'device.parent', so that every device can reference its parent.<br>




<br>I propose to add a new entry in docs/nut-names.txt, with the following content:<br><br>| device.parent  | Reference to the parent node in the PowerChain (NUT host format)         | ups1@localhost<br><br>A new chapter will be created in the user manual, to describe the usage of this feature.<br>




<br>Note that there will be a separate mail to discuss implementation details.<font color="#888888"><br></font></blockquote><div> </div></div><br>I've been thinking a bit more on PowerChain design and implementation.<br>
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.<br><br>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.<br>

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

<br>I thus propose to add the 2 following network protocol commands:<br><br>8<----------------------------------------------------------------------------------------------------<br><br>(GET) POWERCHAIN<br>~~~~~~~~~~~~~~~~~~<br>
<br>Form:<br><br>    GET POWERCHAIN <device name><br>    GET POWERCHAIN ups1<br><br>Response:<br>
<br>    POWERCHAIN <device name> ; ... ; <device name><br>    POWERCHAIN psu1 ; ups1<br><br>This returns the full PowerChain list that contains '<device name>'.<br>If this device is not part of a PowerChain, '<device name>' is returned.<br>
<br>(LIST) POWERCHAIN<br>~~~~~~~~~~~~~~~~~~<br><br>Form:<br><br>    LIST POWERCHAIN<br><br>Response:<br>
<br>    BEGIN LIST POWERCHAIN<br>    POWERCHAIN <device name> ; ... ; <device name><br>    ...<br>    END LIST POWERCHAIN<br><br>    BEGIN LIST POWERCHAIN<br>    POWERCHAIN psu1 ; outlet.1:pdu1 ; ups1<br>    POWERCHAIN psu2 ; outlet.1:pdu2 ; ups2<br>

    END LIST POWERCHAIN<br><br>'<device name>' are names from ups.conf.<br><br>This can be used to determine whether PowerChain is supported<br>or not on this host.  This is also the way to obtain the list of all<br>
 powerchains for the given host.<br><br>Clients which perform a PowerChain discovery process may find this useful.<br><br clear="all">8<----------------------------------------------------------------------------------------------------<br>
<br>The above is more coherent and efficient, doesn't impact compatibility (even in libupsclient) while proposing this new feature.<br>
<br>Note that I will submit a 3rd RFC for PowerChain, to deal with monitoring (upsmon) integration.<br>But since this one has a lower priority (PowerChain step 2), it won't be before some time.<br>
<br>Comments, questions and ideas welcome, as usual.<br><br>cheers,<br>Arnaud<br><br>