 I'm going to present this short talk building asynchronous SNMP agents. My name is Ilya Itungov. I work for Red Hat. I'm on the OpenStack team, but besides that, I have this long-term hobby, all things SNMP. In this talk, I'm going to argue that SNMP is still relevant and present a new tool called SNMP Responder aimed at simplifying the integration of custom data sources with SNMP agents. And I will try to conclude this talk with a simple workflow, example workflow. Despite many attempts to displace and successful attempts to displace SNMP from the role of the single network management protocol, SNMP is still quite popular in monitoring applications. Perhaps because people understand it well, because the protocol has been around for a long time. The other reason may be because we have so many MIBs, so many sources of structured information to reuse. Imagine this use case. You have a network monitored by SNMP. And everything is in SNMP. NMS, for instance, is SNMP-based. And you've got new hardware. This new hardware doesn't contain SNMP agents, so you can't monitor it with SNMP. But it offers a rest API. So what can you possibly do about this? The solution I'm trying to propose is to stand up some sort of mediation proxy, which works as an SNMP agent on one side and which can feed on your custom data sources. The workflow of setting up this mediation proxy would be like this. You take a MIB file, you compile it into Python code with hooks. You populate these hooks with your custom code to get data from your data source. And then you feed this Pythonized MIB to this SNMP responder tool and you get it on SNMP, on the network. Now, the workflow, so you have this rest API. Let's say it's a bare metal server serving redfish protocol. You can get rest call, you can have this rest call and it returns lots of data. Let's focus on this hostname field. Hostname stands for hostname, so SNMP already offers something similar for that. She's named managed object from the SNMP to MIB. This is how it looks like in the MIB. Now, we can use the PySMAP project to compile the MIB file into Python snippet. This Python snippet would look like this. Then you basically just add the rest API call into this quote and preferably do it from a thread so that the whole thing would be non-blocking and it could work asynchronously and highly concurrently. Next, you just pre-console the tool as SNMP responder and feed this Pythonized MIB, this MIB implementation to it by just copying the Python file. Once you have it started, you can just SNMP get it and you get the result from the rest API call. To summarize, SNMP is still quite widely used but getting it hooked on the custom data sources seems to be a pain. This SNMP responder tool is hopefully could help integrating these custom data sources with standard SNMP agents. Once you have it up and running, you can use all SNMP features, all SNMP versus strong encryption for SNMP management. And this SNMP responder tool is designed as a synchronous engine. Therefore, it's highly concurrent and hopefully would be able to serve high load. So that's probably it. Questions? There's no time, sorry. All right. All right.