Skip to content

[202111][db_migrator] Add migration of FLEX_COUNTER_DELAY_STATUS during 1911->2111 upgrade + fast-reboot. Add UT.#2869

Closed
vadymhlushko-mlnx wants to merge 2 commits intosonic-net:202111from
vadymhlushko-mlnx:202111-flex-counter-delay-status-migration
Closed

[202111][db_migrator] Add migration of FLEX_COUNTER_DELAY_STATUS during 1911->2111 upgrade + fast-reboot. Add UT.#2869
vadymhlushko-mlnx wants to merge 2 commits intosonic-net:202111from
vadymhlushko-mlnx:202111-flex-counter-delay-status-migration

Conversation

@vadymhlushko-mlnx
Copy link
Copy Markdown
Contributor

What I did

Add migration of FLEX_COUNTER_DELAY_STATUS attribute of config_db FLEX_COUNTER_TABLE during the SONiC to SONiC upgrade + fast-reboot from older versions 201911 -> 202111.

This change is required for the fast-reboot procedure because without it the counters will be created during the init flow which will waste a lot of resources and cause data plane degradation of more than 30 seconds.

How I did it

Modify the db_migrator.py.

How to verify it

Add UT.

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)

@liat-grozovik
Copy link
Copy Markdown
Collaborator

@vadymhlushko-mlnx pls check failures

@vadymhlushko-mlnx
Copy link
Copy Markdown
Contributor Author

@vadymhlushko-mlnx pls check failures

the 202111 branch CI is currently broken.
We are waiting sonic-utilities/pull/2880 to be merged

@liat-grozovik liat-grozovik requested a review from vaibhavhd June 21, 2023 15:52
@vaibhavhd
Copy link
Copy Markdown
Contributor

I just noticed that 202012 and 202111 are creating same versions w/ different migration logic.

I think the deviation begun starting version_2_0_0. This is not expected as now same DB version will have different looking config (or other db) schema.

This almost sounds like an issue that was earlier seen for 202211 branch: https://github.com/sonic-net/sonic-utilities/pull/2470/files

Unfortuantely, like before, we did not lock new version for 202111 branch. This is not an issue just w/ this PR, rather this is a missed step in new branch creation.

I think we need to lock a version everytime a feature branch is created. This needs further discussion and agreement w/ branch owners.

…ng 1911->master upgrade + fast-reboot. Add UT.

Signed-off-by: vadymhlushko-mlnx <[email protected]>
@vadymhlushko-mlnx vadymhlushko-mlnx force-pushed the 202111-flex-counter-delay-status-migration branch from c389c76 to 62534a1 Compare July 3, 2023 08:36
@vadymhlushko-mlnx
Copy link
Copy Markdown
Contributor Author

I just noticed that 202012 and 202111 are creating same versions w/ different migration logic.

I think the deviation begun starting version_2_0_0. This is not expected as now same DB version will have different looking config (or other db) schema.

This almost sounds like an issue that was earlier seen for 202211 branch: https://github.com/sonic-net/sonic-utilities/pull/2470/files

Unfortuantely, like before, we did not lock new version for 202111 branch. This is not an issue just w/ this PR, rather this is a missed step in new branch creation.

I think we need to lock a version everytime a feature branch is created. This needs further discussion and agreement w/ branch owners.

Could you please tell me with whom I could talk about this versioning issue?

@vadymhlushko-mlnx vadymhlushko-mlnx force-pushed the 202111-flex-counter-delay-status-migration branch from 3955c68 to fa3b4ae Compare July 12, 2023 07:47
@vadymhlushko-mlnx
Copy link
Copy Markdown
Contributor Author

I just noticed that 202012 and 202111 are creating same versions w/ different migration logic.
I think the deviation begun starting version_2_0_0. This is not expected as now same DB version will have different looking config (or other db) schema.
This almost sounds like an issue that was earlier seen for 202211 branch: https://github.com/sonic-net/sonic-utilities/pull/2470/files
Unfortuantely, like before, we did not lock new version for 202111 branch. This is not an issue just w/ this PR, rather this is a missed step in new branch creation.
I think we need to lock a version everytime a feature branch is created. This needs further discussion and agreement w/ branch owners.

Could you please tell me with whom I could talk about this versioning issue?

@vaibhavhd kind reminder

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants