<br><br><div class="gmail_quote">2011/6/29 Arjen de Korte <span dir="ltr"><<a href="mailto:nut%2Bdevel@de-korte.org">nut+devel@de-korte.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Citeren Arnaud Quette <<a href="mailto:aquette.dev@gmail.com" target="_blank">aquette.dev@gmail.com</a>>:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess I see the scanning code as a stopgap way to contact "legacy"<br>
servers (or what would be legacy after some discovery protocol like mDNS is<br>
set up), and either timeouts or non-blocking is just a kludge to make that<br>
work a little better. And isn't opening a non-blocking socket just a way to<br>
split socket connection and protocol initialization?<br>
</blockquote>
indeed.<br>
</blockquote>
<br></div>
This isn't needed. Probing ranges of hosts listening on an arbitrary port doesn't require the upsclient library. For the hits, connect through the usual upscli_connect method, which by then you know will not block.</blockquote>
<div><br>well, though I agree with your POV (a simple connect to check for possible NUT presence, with timeout management), there is an interest in providing the user audience (ie developers here) a tryconnect() method with a common code.<br>
<br>using the simple connect method, you're also still open to false positive, even if we're using a IANA port.<br><br>so I don't see why adding ~ 40 lines on 1000, with a new feature, while keeping the current behavior intact would pose a problem?! we're still in NUT source code, with the same code duplication policies and maintenance optimization quest.<br>
 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
as for the compat, IIRC Fred proposed a a new _tryconnect() method, upon<br>
which the standard _connect() would be mapped, with no behavior change.<br>
</blockquote>
<br></div>
It is still unclear to me what we're trying to accomplish here, since auto-configuration is never going to work in environments where it is most needed (multi-UPS).<br></blockquote></div><br clear="all">Charles already answered partially: it's about making configuration easier, but not automagic!<br>
<br>Now, I have to provide more details since there was not much highlight on this point in:<br><a href="https://wiki.ubuntu.com/ServerOneiricInfraPower">https://wiki.ubuntu.com/ServerOneiricInfraPower</a>.<br><br>All this is mostly related to Cloud, at least it's a point of focus for a first run.<br>
<br>1) the first part is about deployment, with an "infrastructure server" (IS) that does provisioning and act as a PXE server. <br><br>There, nut-scanner on the IS scans the network and presents the user with a list of UPSs, PDUs  and IPMI servers' PSUs. Node deployed through PXE get:<br>
- NUT installed automatically, if needed (ie provisioned)<br>- (pre)configuration pushed from IS through puppet / mcollective<br>- (post)configuration can be appended, in case there are also (or only) local devices, by running post install script that also use nut-scanner.<br>
<br>2) the 2nd is about allowing 3rd party supervision tools and NMS to discover power devices and NUT instances, and track the whole PowerChain, from SW to main.<br><br>in other word, this is just a quicker and lazier way to reach large network monitoring, while waiting for a Power Device MIB that could suit our present and future needs.<br>
(If somebody is still reading this mail and interested in helping there, ping me back)<br><br>cheers,<br>Arnaud<br>