-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add transceiver status to wicket #7562
Conversation
bnaecker
commented
Feb 19, 2025
- Make the current inventory specific to MGS
- Add per-switch transceiver list to the inventory as well
- Fetch transceiver state periodically in wicketd
- Draw transceiver details in the wicket inventory panel
- Fixes Wicket could show basic transceiver status during rack setup #6710
- Make the current inventory specific to MGS - Add per-switch transceiver list to the inventory as well - Fetch transceiver state periodically in wicketd - Draw transceiver details in the wicket inventory panel - Fixes #6710
Here is a screenshot showing the normal, expected contents when a transceiver is all working correctly. There are a few ways the transceivers can go off the rails, but the most common is that we simply have no light on one side or the other. Below is a screenshot of what that will look like if we have transmit power below some minimum threshold. (I simulated this by disabling the link via Dendrite.) We'll have similarly-colored warnings for all the monitors, if they're outside some expected range. This last part isn't perfect. One could argue that we shouldn't consider it unusual if there's no Tx power when the link is disabled entirely -- we shouldn't be transmitting anything. There are also some other flags and warnings we can print, such as whether we have a Tx fault, or if the module can recover a clock from the Rx signal. I'm open to adding these in later PRs if we think they'll be useful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Just a few questions.
- Make transceiver data optional, so we report what we can. Handle optional values when printing in `wicket` UI. - Add comments about how we're addressing transceiver modules when collecting all the data and how that fails. - Add comment around transceiver interface naming. - Add comment and clarify `wicket` UI text around software override of the module hardware power signal
Rename `inventory_or_unavail` to `mgs_inventory_or_unavail`
- Update OpenAPI for new optional transceiver bits - Simplify nested options with a result, making it clearer when we have failed to read transceiver information and when we read it, but the module doesn't support it.
I'd like to test this one more time on a system with actual transceivers, since 1d87e93 updated the logic around UI formatting quite a bit. Will take this for another lap when a system opens up in the lab. |
So funny enough, the temp and voltage being unsupported uncovered a bug, thanks to @rmustacc. See oxidecomputer/transceiver-control#339, which is fixed in oxidecomputer/transceiver-control#341. That will get picked up by this code automatically next time we update the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, thank you so much for working through the comments!