Re: [nox-dev] 'Monitoring' component status
Hi Joe, That's right, monitoring periodically queries switches for statistics and exposes that info. The interface is probably not going to chance any time soon. It has been used and tested to some extent, and has been proven ok for what it used so far. It exposes information like table_stats, port_stats, aggregate_stats I'm not aware of scripts that demonstrate its usage, but the GUI interacts with monitoring to display some switch statistics etc. So if you wanted to delve into the code there you could find an example of how to use the API. (It's probably more complicated than you need since, 'messenger' is used between the GUI and monitoring for their communication. You probably don't care about interfacing with an external program like that) On Tue, Jan 17, 2012 at 5:58 PM, Joe Stringer wrote: > Hi all, > > I'm currently writing an SNMP subagent to interface with NOX to fetch > openflow statistics from NOX. To this end, I was thinking of fetching > the statistics via JSON messages. I noticed that netapps/monitoring in > the destiny branch caches stats about connected datapaths, and it > looks like it could be useful for my project. > > What is the current status of the monitoring component in the destiny > branch? > - Is the interface likely to change much? > - What information does it expose? > - Are there any scripts like src/scripts/nox-console.py that have > examples of how to structure messages to get certain types of replies? > > Cheers, > Joe > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] attribute '_handleSigchld'
Commenting that line out from pyoxidereactor worked. Thanks, Murphy! -/\/ On Mon, Jan 16, 2012 at 4:30 PM, Murphy McCauley wrote: > I believe you can safely just remove the offending line from > pyoxidereactor (the signal.signal(signal.SIGCHLD, self._handleSigchld) > one). If not, the current version of pyoxidereactor (from the destiny > branch) should fix this in a way which doesn't require you to modify your > system's Twisted installation. > > -- Murphy > > On Jan 16, 2012, at 1:38 PM, Nikhil Handigol wrote: > > Hi Vjeko, > > I'm facing a similar issue. I recently upgraded twisted to 11.0 and found > that an older (customized) version of nox crashes with the same error. Can > you tell me to which class > in '/usr/lib/python2.6/dist-packages/twisted/internet/base.py' should I add > the _handleSigchld function? > > Thanks, > -- Nikhil > > > On Fri, Aug 6, 2010 at 1:58 PM, Vjekoslav Brajkovic < > bal...@cs.washington.edu> wrote: > >> Hi Tim! >> >> You are correct. After adding the following function definition to >> '/usr/lib/python2.6/dist-packages/twisted/internet/base.py', the >> problem seems to be gone. >> >> >> >>def _handleSigchld(self, signum, frame, >> _threadSupport=platform.supportsThreads()): >>from twisted.internet.process import reapAllProcesses >>if _threadSupport: >>self.callFromThread(reapAllProcesses) >>else: >>self.callLater(0, reapAllProcesses) >> >> >> >> Thanks a bunch! >> Vjeko >> >> >> On Fri, Aug 06, 2010 at 04:30:28PM -0400, tim.upthegrove@gatech.eduwrote: >> > Hi Vjekoslav, >> > >> > I had this issue before after doing a fresh install on a Debian sid >> machine using the openflow-1.0 branch. >> > >> > What I found is, the function _handleSigchld has been >> moved-around/removed from more recent versions of TwistedPython. The fix I >> found was to go grab Twisted 8.0 and install it. I haven't tested the >> controller in a production setup yet, but the source compiles and I can run >> a simple switch without getting any error messages. >> > >> > Give that a shot and see if it works. >> > >> > Best of luck, >> > >> > Tim Upthegrove >> > Georgia Institute of Technology >> > College of Computing >> > (406)-437-1493 >> > >> > - "Vjekoslav Brajkovic" wrote: >> > >> > > Hello. >> > > >> > > After I upgraded my system, I've been having trouble starting NOX. >> > > This is the error message: >> > > >> > > >> >> > > 2|nox|ERR:Cannot change the state of 'python' to INSTALLED: >> > > 'python' ran into an error: >> > > Unable to construct a Python component: >> > > Traceback (most recent call last): >> > > File "./nox/coreapps/pyrt/pyoxidereactor.py", line 364, in >> > > instance >> > > return pyoxidereactor(ctxt) >> > > File "./nox/coreapps/pyrt/pyoxidereactor.py", line 133, in >> > > __init__ >> > > signal.signal(signal.SIGCHLD, self._handleSigchld) >> > > AttributeError: 'pyoxidereactor' object has no attribute >> > > '_handleSigchld' >> > > >> >> > > >> > > Any clues to why this might be happening? >> > > >> > > Thanks! >> > > Vjeko >> > > >> > > ___ >> > > nox-dev mailing list >> > > nox-dev@noxrepo.org >> > > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev > > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] NOX on IRC
The nox-dev mailing list is still the best way discuss NOX or ask for help, but there is now also a IRC channel where NOX users and developers can hangout for a more real-time type of interaction. Join us on #noxcontroller on "freenode" servers. (For instant web-based access: http://webchat.freenode.net/ ) ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] 'Monitoring' component status
Hi all, I'm currently writing an SNMP subagent to interface with NOX to fetch openflow statistics from NOX. To this end, I was thinking of fetching the statistics via JSON messages. I noticed that netapps/monitoring in the destiny branch caches stats about connected datapaths, and it looks like it could be useful for my project. What is the current status of the monitoring component in the destiny branch? - Is the interface likely to change much? - What information does it expose? - Are there any scripts like src/scripts/nox-console.py that have examples of how to structure messages to get certain types of replies? Cheers, Joe ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Python API buffer_id None problems
Hi Murphy, thanks a lot, packet.arr helped. But the documentation could be improved and at least hint that "packet" argument is actually packet.arr Best wishes Peter On Tue, Jan 17, 2012 at 3:30 PM, Murphy McCauley wrote: > You're right about the documentation and the implementation being > mismatched. The implementation is correct, the documentation is outdated. > > The error you see when you pass None as the buffer ID is almost certainly > in your code and not in NOX. The error message is not that clear, but it's > telling you that the "packet" argument must be a str, and you are passing > an ethernet object from the packet library. You need to either convert > this to a string (packet.tostring()), or try to use the original buffer > (packet.arr or packet.arr.tostring(); I can't remember). > > Hope that helps. > > -- Murphy > > On Jan 17, 2012, at 5:31 AM, Peter Peresini wrote: > > I can reproduce it with following simple command, packet is the packet > received in packet_in_callback, actions is a combination of setting ToS and > forwarding to a single port. > > self.send_openflow(datapath_id, None, packet, actions, inport=inport) > > Kind regards > Peter > > > On Tue, Jan 17, 2012 at 11:42 AM, Murphy McCauley wrote: > >> Can you please show us the code you are using to call send_openflow()? >> >> -- Murphy >> >> On Jan 17, 2012, at 1:40 AM, Peter Peresini wrote: >> >> Hi developers. >> It seems that there is an inconsistency in python API (destiny branch) >> for using buffer_id. Namely, "send_openflow" documentation states that >> buffer_id -1 should be used to indicate no buffer but in the fact it tests >> for None. >> But apart from that, if you supply None to this function the call will >> fail with the following error: >> >> (openflow typemap) py argument to Buffer must be of type str, instead >> received >> >> >> as far as I can tell, the problem occurs inside the call >>self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions, >> inport) >> in the send_openflow_packet() function. >> >> Any idea what might be the problem? I can debug it even more if you tell >> me where to find the implementation of context. >> >> Kind regards >> Peter Peresini >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev >> >> >> > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Python API buffer_id None problems
You're right about the documentation and the implementation being mismatched. The implementation is correct, the documentation is outdated. The error you see when you pass None as the buffer ID is almost certainly in your code and not in NOX. The error message is not that clear, but it's telling you that the "packet" argument must be a str, and you are passing an ethernet object from the packet library. You need to either convert this to a string (packet.tostring()), or try to use the original buffer (packet.arr or packet.arr.tostring(); I can't remember). Hope that helps. -- Murphy On Jan 17, 2012, at 5:31 AM, Peter Peresini wrote: > I can reproduce it with following simple command, packet is the packet > received in packet_in_callback, actions is a combination of setting ToS and > forwarding to a single port. > > self.send_openflow(datapath_id, None, packet, actions, inport=inport) > > Kind regards > Peter > > > On Tue, Jan 17, 2012 at 11:42 AM, Murphy McCauley wrote: > Can you please show us the code you are using to call send_openflow()? > > -- Murphy > > On Jan 17, 2012, at 1:40 AM, Peter Peresini wrote: > >> Hi developers. >> It seems that there is an inconsistency in python API (destiny branch) for >> using buffer_id. Namely, "send_openflow" documentation states that buffer_id >> -1 should be used to indicate no buffer but in the fact it tests for None. >> But apart from that, if you supply None to this function the call will fail >> with the following error: >> >> (openflow typemap) py argument to Buffer must be of type str, instead >> received >> >> >> as far as I can tell, the problem occurs inside the call >>self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions, >> inport) >> in the send_openflow_packet() function. >> >> Any idea what might be the problem? I can debug it even more if you tell me >> where to find the implementation of context. >> >> Kind regards >> Peter Peresini >> >> ___ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev > > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
Re: [nox-dev] Python API buffer_id None problems
Can you please show us the code you are using to call send_openflow()? -- Murphy On Jan 17, 2012, at 1:40 AM, Peter Peresini wrote: > Hi developers. > It seems that there is an inconsistency in python API (destiny branch) for > using buffer_id. Namely, "send_openflow" documentation states that buffer_id > -1 should be used to indicate no buffer but in the fact it tests for None. > But apart from that, if you supply None to this function the call will fail > with the following error: > > (openflow typemap) py argument to Buffer must be of type str, instead > received > > > as far as I can tell, the problem occurs inside the call >self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions, > inport) > in the send_openflow_packet() function. > > Any idea what might be the problem? I can debug it even more if you tell me > where to find the implementation of context. > > Kind regards > Peter Peresini > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
[nox-dev] Python API buffer_id None problems
Hi developers. It seems that there is an inconsistency in python API (destiny branch) for using buffer_id. Namely, "send_openflow" documentation states that buffer_id -1 should be used to indicate no buffer but in the fact it tests for None. But apart from that, if you supply None to this function the call will fail with the following error: (openflow typemap) py argument to Buffer must be of type str, instead received as far as I can tell, the problem occurs inside the call self.ctxt.send_openflow_packet_acts(dp_id, packet, oactions, inport) in the send_openflow_packet() function. Any idea what might be the problem? I can debug it even more if you tell me where to find the implementation of context. Kind regards Peter Peresini ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
