[Celestica Seastone2] Build correct platform files

[fyx]

Why I did it

I noticed show interfaces transceiver presence was not showing correct state for our inserted transceivers

How I did it

Redis database was missing TRANSCEIVER_INFO keys and found out that xcvrd process was crashing:

Dec 28 22:54:12.246211 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd Traceback (most recent call last):
Dec 28 22:54:12.246246 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/bin/xcvrd", line 8, in <module>
Dec 28 22:54:12.246280 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     sys.exit(main())
Dec 28 22:54:12.247190 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/lib/python2.7/dist-packages/xcvrd/xcvrd.py", line 1441, in main
Dec 28 22:54:12.247190 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     xcvrd.run()
Dec 28 22:54:12.247190 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/lib/python2.7/dist-packages/xcvrd/xcvrd.py", line 1389, in run
Dec 28 22:54:12.247190 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     self.init()
Dec 28 22:54:12.247255 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/lib/python2.7/dist-packages/xcvrd/xcvrd.py", line 1352, in init
Dec 28 22:54:12.247904 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     post_port_sfp_dom_info_to_db(is_warm_start, self.stop_event)
Dec 28 22:54:12.247904 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/lib/python2.7/dist-packages/xcvrd/xcvrd.py", line 518, in post_port_sfp_dom_info_to_db
Dec 28 22:54:12.247904 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     post_port_sfp_info_to_db(logical_port_name, int_tbl[asic_index], transceiver_dict, stop_event)
Dec 28 22:54:12.247904 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/lib/python2.7/dist-packages/xcvrd/xcvrd.py", line 303, in post_port_sfp_info_to_db
Dec 28 22:54:12.247968 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     if not _wrapper_get_presence(physical_port):
Dec 28 22:54:12.248586 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd   File "/usr/local/lib/python2.7/dist-packages/xcvrd/xcvrd.py", line 151, in _wrapper_get_presence
Dec 28 22:54:12.248586 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd     return platform_chassis.get_sfp(physical_port).get_presence()
Dec 28 22:54:12.248586 ixp-kg-sw1 INFO pmon#/supervisord: xcvrd AttributeError: 'NoneType' object has no attribute 'get_presence'
Dec 28 22:54:12.308896 ixp-kg-sw1 INFO pmon#supervisord 2021-12-28 22:54:12,307 INFO exited: xcvrd (exit status 1; not expected)
Dec 28 22:54:13.311306 ixp-kg-sw1 INFO pmon#supervisord 2021-12-28 22:54:13,309 INFO gave up: xcvrd entered FATAL state, too many start retries too quickly

After some investigation I figured out that the platform file /usr/local/lib/python2.7/dist-packages/sonic_platform/sfp.py was not intended for seastone2 but for silverstone. The build process was working in the relative directory for silverstone instead of seastone2.

How to verify it

Check logs for xcvrd and verify that it's not crashing anymore

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106
• 202111

Backport to earlier releases as this is a bug fix for critical hardware monitoring

Description for the changelog

[Celestica Seastone2] Build correct platform files

A picture of a cute animal (not mandatory but encouraged)

[ghost]

All CLA requirements met.

[fyx]

After fixing the platform files we found some xcvrd issues related to adding SFP1 port in #8267 and we have included those patches in this PR as well

[prgeor]

Please NOTE SONiC has moved to using Sfp refactored code which is mostly platform independent code. Its advised to move your platform to start using sonic_xcvr https://github.com/Azure/sonic-platform-common/tree/master/sonic_platform_base/sonic_xcvr

Ref: SFP refactoring HLD. SFP refactoring HLD

Example Dell platform moved to using SFP refactored code : - #9016

[bluecmd]

@prgeor Got it - that might be a thing we have to defer to Celestica for, we only use the platform. The refactor does look very nice though, so hopefully they will adopt it.

As for backporting - could you add the relevant "Request for XYZ branch" labels? Or do we need somebody else to do that?

Thanks!

[bluecmd]

@prgeor Sorry to annoy, but could you add "Request for 202012 branch" as well? Thanks!