-
Notifications
You must be signed in to change notification settings - Fork 667
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
[FC] remove FC delay field #3577
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
f5081c9
to
9163729
Compare
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
@qiluo-msft @wen587 Please help review |
@vaibhavhd Could you review fastreboot, and db_migrator parts? |
…into remove-fc-delay Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
Will restart |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Azure.sonic-utilities |
Azure Pipelines successfully started running 1 pipeline(s). |
@stepanblyschak Can you please sync code with master branch? The PR test has been fixed in master branch. |
scripts/db_migrator.py
Outdated
@@ -1170,8 +1168,6 @@ def version_4_0_2(self): | |||
Version 4_0_2. | |||
""" | |||
log.log_info('Handling version_4_0_2') | |||
if self.stateDB.keys(self.stateDB.STATE_DB, "FAST_REBOOT|system"): |
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.
Changing the functionality of old and already deployed versions is not generally recommended - the db version handling should be same on all feature branches. Otherwise it creates conflicting views and also causes confusion.
I think you can leave version_4_0_2
and migrate_config_db_flex_counter_delay_status
untouched, and handle your new intention in a new function (as you are already doing in common ops).
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.
@vaibhavhd Done
@shlomibitton can you review this PR? |
…into remove-fc-delay Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
f341fa9
to
ba9ed26
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
ba9ed26
to
4560bd7
Compare
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
What I did
Simplify approach to delaying counters on warm boot and fast boot. Removed FLEX_COUNTER_DELAY_STATUS_FIELD and instead postpone all FC processing to happen after apply view to not delay data plane configuration.
The CONFIG_DB should not be updated in runtime anymore for counters to be delayed.
How I did it
Removed FLEX_COUNTER_DELAY_STATUS_FIELD and corresponding counterpoll commands (that weren't supposed to be used by user directly anyway). Updated db_migrator.py to remove that field.
How to verify it
Ran fast-reboot from 202405. Made sure no delay field present, counters are enabled and delayed.
Previous command output (if the output of a command-line utility has changed)
New command output (if the output of a command-line utility has changed)