Skip to content

[sfputilbase] Extend get_transceiver_change_event return event #50

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.

Sign up for GitHub

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

Merged
jleveque merged 5 commits into from
Aug 6, 2019
Merged

[sfputilbase] Extend get_transceiver_change_event return event #50

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
6904fad
Merge pull request #1 from Azure/master
keboliu Jan 24, 2019
82e21fb
Merge branch 'master' of https://github.com/Azure/sonic-platform-common
keboliu Feb 19, 2019
8527ed9
Merge pull request #3 from Azure/master
keboliu Apr 11, 2019
83d3a6a
Merge branch 'master' of https://github.com/Azure/sonic-platform-common
keboliu Jul 31, 2019
ce01408
add more error code to get_transceiver_change_event
keboliu Jul 31, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions sonic_platform_base/sonic_sfp/sfputilbase.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1253,8 +1253,12 @@ def get_transceiver_change_event(self, timeout=0):
event. When timeout is non-zero, the function can also return when the timer expires.
When timer expires, the return status is True and events is empty.
:returns: (status, events)
:status: Boolean, True if call successful, False if not;
:events: dictionary for pysical port index and the SFP status,
status='1' represent plug in, '0' represent plug out like {'0': '1', '31':'0'}
:status: Boolean, True if call successful and no system level event/error occurred,
False if call not success or system level event/error occurred.
:events: dictionary for physical port index and the SFP status,
status='1' represent plug in, '0' represent plug out like {'0': '1', '31':'0'}
when it comes to system level event/error, the index will be '-1',
and status can be 'system_not_ready', 'system_become_ready', 'system_fail',
Copy link

@qiluo-msft qiluo-msft Aug 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

system_become_ready [](start = 48, length = 19)

From design perspective, system_become_ready is not necessary. If this event is really happen, the logic could continue run as a normal successful case or a timeout case. Then all the system level events are actually errors in concept.

Copy link
Collaborator

@stephenxs stephenxs Aug 2, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Qi,
I admit that in terms of state machine any normal event, like sfp module insertion or removal, can indicate the xcvrd has entered a normal state. However, an explicit notification can make the flow more clear. Without system_bdcom_ready we can hardly tell whether the xcvrd is in a normal state, monitoring the sfp modules' state, or waiting for ready.
In this sense, I suggest keeping this state.

like {'-1':'system_not_ready'}.
"""
return