Meinberg Syncbox Agent

[davidvng]

Description

Adds new agent to receive data from the Meinberg syncbox via SNMP.

Motivation and Context

Resolves #518 .

How Has This Been Tested?

Tested on daq-dev with syncboxes available on site.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[davidvng]

@mhasself putting this on your radar as it seems relevant again. this had worked last year and I'm wondering if it'd be useful to update this and push for review?

[mhasself]

Yes, I think we should probably have this running.

Find a couple of comments inline from reading the code quickly.

It would be good to demonstrate that these variables do tell us something ... e.g. if we disconnect the PTP grandmaster, does the value of mbgSyncboxN2XPtpPortState change in a way that we would detect with this?

With the SNMP stuff it always bothers me that most of the fields will, like, never change. While for others you might want to sample them a little more often than every ~60s, but only report the value if it has changed (or if a long time has elapsed). Let's consider that a little more.

[mhasself]

Thanks for the quick fixes -- still some issues with error handling I think.

I think the only way forward here is to make a list of expected fields (you have done that); then to query those on each iteration, and if any fields are missing, don't publish them and mark self as degraded.

If the "outputs" list is actually dynamic (depends on syncbox config), then you can have each output assigned to a different ocs feed -- that way it won't be an error for those to go in and out depending on syncbox configuration.

A better way, given that we want our syncbox to be in a particular configuration, would be to have command line args that specify which outputs should be configured. Then the syncbox can only monitor those, and become degraded if the status is not available.

[davidvng]

I think the only way forward here is to make a list of expected fields (you have done that); then to query those on each iteration, and if any fields are missing, don't publish them and mark self as degraded.

@mhasself Should I not update session.data as well as not publish to feed when this happens? And if so, do I need to do something like session.set_status('degraded')?

[mhasself]

Latest version looks good.

To mark the session as degraded, just set session.degraded = True; then clear that when connection is re-established.

[BrianJKoopman]

Latest version looks good.

This seems good to merge, yeah? @davidvng any other changes incoming?

[davidvng]

Latest version looks good.

This seems good to merge, yeah? @davidvng any other changes incoming?

@BrianJKoopman no other changes from me, I think it's good to merge

Clearing request for changes, approval provided in comment above.