SNMP query

Ed Tanous ed.tanous at intel.com
Wed Jan 30 05:38:49 AEDT 2019


On 1/29/19 9:31 AM, susan jasinski wrote:
> 
> I am looking for feedback on whether we _should_ implement something
> similar?
It sounds like a pretty reasonable thing, and something that other types
of systems (non BMC) do today.

> 
> - If we do not get a response, then we would provide a validation
> message like "Invalid host name or IP address, or the device did not
> respond to the SNMP query"
> 

What would the backend of this look like?  I don't think we have any
example of anything that "tests" a given settings change without
actually applying it.  Would you make the settings change, then roll it
back if it didn't work?  If that's your flow, you could likely just do
it with the apply button, and drop the "test" button altogether.

The flow could look something like:
1. User clicks apply
2. Webui requests the change from the backend, then subscribes to the
log events.
3. Backend tests the new settings by "querying" the SNMP device
4. Backend logs a signal if the SNMP device didn't respond to a ping.
5. Javascript sees signal, and gives the user the appropriate message
(possibly through Rebeccas new "toast" messages, possibly through the
form validation if the page is still up.

The above flow likely saves you as lot of complexity in implementation,
as most of the infrastructure is already there, there's only a minor
interface change needed (to add the new signal type) and you don't have
to handle the rollback case.

Coming back to the test button idea, if that's the path you're looking
to follow, how would you overcome the HTTP timeout limits?  I believe
our http timeouts are set at 15 seconds, very similar to what the SNMP
timeouts are.  Would you do a "double" request and request the change,
then a second requests to see if it applied?  Would you use the
subscribe API?  How would settings be rolled back?

PS, This list tends to prefer text emails over HTML emails.  I'm not
sure how to configure that in gmail, but it must be doable.

Thanks,

-Ed


More information about the openbmc mailing list