You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ref 1:
"
On Fri, Jan 10, 2020 at 6:58 PM Jeff.Yin@dell.com wrote:
Right, we’re on the same page in that regard. This whole syspoll thing was implemented a while back. At the time, we didn’t have the docker-to-host dBus mechanism in place, and we were working with the “restriction” of running the mgmt-framework in the docker and not doing things directly on the host. The PR you’ve linked seems to introduce a host service that writes to the STATE_DB. This seems to be OK, as the PR was merged, so in hindsight we could have explored this option.
We have pending work to extract the data from the DB where possible, make dBus calls to the system when data is not available in the DB, and then get rid of the syspoll/file system approach entirely. However, that code is not part of Release_1.0.
[EXTERNAL EMAIL]
Frankly speaking, file system is probably not the best place to carry such dynamic data. It is better to use database to store such data.
Mostly for the data is available in the state db now.
The data from /var/platform is required to service the below CLI show commands:
show system cpu
show system memory
show system processes
show system processes pid
show platform syseeprom
"
The text was updated successfully, but these errors were encountered:
Ref 1:
"
On Fri, Jan 10, 2020 at 6:58 PM Jeff.Yin@dell.com wrote:
Right, we’re on the same page in that regard. This whole syspoll thing was implemented a while back. At the time, we didn’t have the docker-to-host dBus mechanism in place, and we were working with the “restriction” of running the mgmt-framework in the docker and not doing things directly on the host. The PR you’ve linked seems to introduce a host service that writes to the STATE_DB. This seems to be OK, as the PR was merged, so in hindsight we could have explored this option.
We have pending work to extract the data from the DB where possible, make dBus calls to the system when data is not available in the DB, and then get rid of the syspoll/file system approach entirely. However, that code is not part of
Release_1.0
.From: Guohan Lu gulv@microsoft.com
Sent: Friday, January 10, 2020 3:42 PM
To: Yin, Jeff; anand.subramanian@broadcom.com; Renuka Manavalan; partha.dutta@broadcom.com
Cc: ben.gale@broadcom.com; mehak.mahajan@broadcom.com
Subject: RE: [EXTERNAL] Re: New comments to be resolved
[EXTERNAL EMAIL]
Frankly speaking, file system is probably not the best place to carry such dynamic data. It is better to use database to store such data.
Mostly for the data is available in the state db now.
Check the pr here. https://github.com/Azure/sonic-buildimage/pull/3525/files
We also have syseeprom in the state db as well.
From: Jeff.Yin@dell.com Jeff.Yin@dell.com
Sent: Friday, January 10, 2020 11:55 AM
To: anand.subramanian@broadcom.com; Renuka Manavalan Renuka.Manavalan@microsoft.com; partha.dutta@broadcom.com
Cc: Guohan Lu gulv@microsoft.com; ben.gale@broadcom.com; mehak.mahajan@broadcom.com
Subject: RE: [EXTERNAL] Re: New comments to be resolved
The data from /var/platform is required to service the below CLI show commands:
show system cpu
show system memory
show system processes
show system processes pid
show platform syseeprom
"
The text was updated successfully, but these errors were encountered: