[sonic-py-common] Add platform and chassis info methods to device_info

[alexrallen]

Why I did it

These methods were added to make some convenient platform and chassis information methods accessible through sonic-py-common. These methods were refactored from sonic-utilities and are used in the show platform summary and show version commands.

How I did it

There are two methods, one is get_platform_info() which simply calls local methods to collect useful platform information into a dictionary format, this came directly from sonic-utilities.

The other method is get_chassis_info() which retrieves the chassis model, serial number, and hardware revision from the STATE_DB directly.

How to verify it

Open a python3 interpreter and enter the following lines

Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sonic_py_common import device_info
>>> device_info.get_platform_info()
{'platform': 'x86_64-mlnx_msn2700-r0', 'hwsku': 'ACS-MSN2700', 'asic_type': 'mellanox', 'asic_count': 1}
>>> device_info.get_chassis_info()
{'model':'MSN2700-CS2FO', 'serial':'MT1623X09522', 'revision': 'A1'}

For different platforms these values will be different, simply check if they are successfully populated (Not empty or N/A). If it says "Not Provided" this means that the requested information is not encoded into the DMI of the switch.

Description for the changelog

[sonic-py-common] Add platform and chassis info methods to device_info

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

[lgtm-com]

This pull request introduces 1 alert when merging a305336 into c646257 - view on LGTM.com

new alerts:

• 1 for Except block handles 'BaseException'

[alexrallen]

This pull request introduces 1 alert when merging a305336 into c646257 - view on LGTM.com

new alerts:

* 1 for Except block handles 'BaseException'

This is expected. The block of code calling this makes a redis db call which from my experience right now can return a plethora of errors (if the whole service is down, timeout etc.), I want this to nicely handle that situation and simply return the dictionary with as many values as it was able to successfully retrieve. Handling of not having this information is done by the caller.

[liat-grozovik]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lgtm-com]

This pull request introduces 1 alert when merging 9f92c74 into 9930e73 - view on LGTM.com

new alerts:

• 1 for Except block handles 'BaseException'

[jleveque]

Please fix LGTM alert.

[alexrallen]

Did you see my earlier comment about the LGTM alert?

[jleveque]

Did you see my earlier comment about the LGTM alert?

If you need to catch all exceptions, please use except Exception rather than simply except. This is the preferred method, and it will resolve the LGTM alert.

[jleveque]

Here's a little bit more about the difference: https://stackoverflow.com/a/18982754

[alexrallen]

Thats very interesting, I was not aware of that distinction. Thanks!

[jleveque]

Thats very interesting, I was not aware of that distinction. Thanks!

I wasn't either until we began using the LGTM plugin. :)

[dgsudharsan]

/azpw run

[jleveque]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[liat-grozovik]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).