-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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.
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
In modular chassis, add CHASSIS_STATE_DB on control card #5624
Conversation
@BrynXu can you help to review? |
retest vsimage please |
can you resolve conflict? |
There is no GLOBAL_STATE_DB mentioned in sonic-net/SONiC#646. |
Added additonal sections in the document with the temperature_info-schema for the table in CHASSIS_STATE_DB . This was discussed in Section 3.2.4. |
Enhancing CC/Supervisor's local redis-DB to add one more table catering to sensors contents? or IMO, local redis-DB of CC is initialized and maintained by PMON's chassisD whereas Global redis-DB of CC is initialized and maintained by PMON's thermalctlD. Since these two are seperate daemons inside PMON container so their respective DB's to be kept independent and restart of one should not impact other |
retest vsimage please |
1 similar comment
retest vsimage please |
2a3b9d0
to
a414204
Compare
retest baseimage please |
retest vsimage please |
retest mellanox please |
retest vsimage please |
2 similar comments
retest vsimage please |
retest vsimage please |
With this change, it fails in below test. Since you made changes to CHASSIS_APP_DB, are you aware why this could fail?
|
Looks like the error was because it was not able to find redis_chassis. Will update "files/scripts/update_chassisdb_config" to delete this from the config. |
retest baseimage please |
retest vs please |
retest vsimage please |
@BrynXu @qiluo-msft please review |
c5af325
to
e486786
Compare
retest baseimage please |
On a modular chassis, add a CHASSIS_STATE_DB where all state information from line-cards can be persisted.
e486786
to
2f6edec
Compare
retest vsimage please |
1 similar comment
retest vsimage please |
@qiluo-msft @judyjoseph @jleveque could one of you please review/approve this? |
Can you check this PR ..#5283 if you need references of CHASSIS_STATE_DB in vs_platform as well ? |
@judyjoseph since the CHASSIS_STATE_DB provider/consumers are pmon processes, there was no need to add references in vs platform. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only concern is occupying new Redis database index. I prefer other reviewers familiar with this topic to approve.
retest vs please |
Discussed with @Qi on this, the suggestion he was making is not to define a new DB for chassis APP/STATE DB .. instead use the existing STATE_DB/APP_DB , and created tables in them with CHASSIS_ prefix in them. |
We introduced new DB because this new DB is hosted in supervisor card and reachable from all linecards. Existing ones aren't reachable to all linecards sonic instances and we would want to them to be isolated than shared. CHASSIS_STATE_DB is added as part of this PR to keep pmon inline with using STATE_DB instead of APP_DB. |
Thanks ! I am fine with that then. A question though is Can we start the id from 0, 1 for this instance "redis_chassis", instead of continuing the numbering as 12, 13 with the original "redis" instance. Did you see any issues in your tests ? |
we have an open issue,Duplicated dbid in redis multi-instances causes error
<#5351>, to prevent us
using duplicated dbid even they are in different redis instance.
…On Wed, Dec 9, 2020 at 12:00 PM judyjoseph ***@***.***> wrote:
Discussed with @Qi <https://github.com/Qi> on this, the suggestion he was
making is not to define a new DB for chassis APP/STATE DB .. instead use
the existing STATE_DB/APP_DB , and created tables in them with CHASSIS_
prefix in them.
@BrynXu <https://github.com/BrynXu> was there any discussion why
CHASSIS_APP_DB was added as a new DB with redis instance.
We introduced new DB because this new DB is hosted in supervisor card and
reachable from all linecards. Existing ones aren't reachable to all
linecards sonic instances and we would want to them to be isolated than
shared.
CHASSIS_STATE_DB is added as part of this PR to keep pmon inline with
using STATE_DB instead of APP_DB.
Thanks ! I am fine with that then. A question though is Can we start the
id from 0, 1 for this instance "redis_chassis", instead of continuing the
numbering as 12, 13 with the original "redis" instance. Did you see any
issues in your tests ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5624 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTR7VJEBDEON6OL3Y6BOX3ST7JOZANCNFSM4SQIE7IA>
.
|
As BrynXu mentioned, there is some limitation in reusing ID. thats why it has to be unique across all DB instances even if its different redis server. |
Ok, we will revisit this along this issue resolution, #5351. |
HLD: sonic-net/SONiC#646
In modular chassis, add CHASSIS_STATE_DB on control card
Why I did it
Modular Chassis has control-cards, line-cards and fabric-cards along with other peripherals. Control-Card CHASSIS_STATE_DB will be the central DB to maintain any state information of cards that is accessible to control-card/
How I did it
Adding another DB on an existing REDIS instance running on port 6380.