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 [email protected] 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 [email protected] 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 [email protected]
Sent: Friday, January 10, 2020 3:42 PM
To: Yin, Jeff; [email protected]; Renuka Manavalan; [email protected]
Cc: [email protected]; [email protected]
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: [email protected] [email protected]
Sent: Friday, January 10, 2020 11:55 AM
To: [email protected]; Renuka Manavalan [email protected]; [email protected]
Cc: Guohan Lu [email protected]; [email protected]; [email protected]
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: