Skip to content

[db_migrator] Set docker_routing_config_mode to the value obtained from minigraph parser#2890

Merged
vaibhavhd merged 4 commits intosonic-net:masterfrom
vaibhavhd:routing-mode
Jul 11, 2023
Merged

[db_migrator] Set docker_routing_config_mode to the value obtained from minigraph parser#2890
vaibhavhd merged 4 commits intosonic-net:masterfrom
vaibhavhd:routing-mode

Conversation

@vaibhavhd
Copy link
Contributor

@vaibhavhd vaibhavhd commented Jun 30, 2023

What I did

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it

Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it

Added a new unit test. Updated old unit tests.

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)

@vaibhavhd vaibhavhd merged commit 7ca3147 into sonic-net:master Jul 11, 2023
@qiluo-msft
Copy link
Contributor

@vaibhavhd This commit could not be cleanly cherry-picked to 202012. Please submit another PR.

StormLiangMS pushed a commit that referenced this pull request Jul 19, 2023
…om minigraph parser (#2890)

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it
Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it
Added a new unit test. Updated old unit tests.
vaibhavhd added a commit to vaibhavhd/sonic-utilities that referenced this pull request Jul 21, 2023
…om minigraph parser (sonic-net#2890)

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it
Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it
Added a new unit test. Updated old unit tests.
vaibhavhd added a commit to vaibhavhd/sonic-utilities that referenced this pull request Jul 21, 2023
…om minigraph parser (sonic-net#2890)

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it
Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it
Added a new unit test. Updated old unit tests.
@liuh-80 liuh-80 added the Cherry Pick PR created_202012 Label for a manually cherry-pick PR created for 202012 cherry-pick conflict PR. label Jul 24, 2023
rajkumar38 pushed a commit to rajkumar38/sonic-utilities that referenced this pull request Jul 25, 2023
…om minigraph parser (sonic-net#2890)

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it
Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it
Added a new unit test. Updated old unit tests.
yxieca pushed a commit that referenced this pull request Aug 10, 2023
…om minigraph parser (#2890) (#2922)

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it
Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it
Added a new unit test. Updated old unit tests.
pdhruv-marvell pushed a commit to pdhruv-marvell/sonic-utilities that referenced this pull request Aug 23, 2023
…om minigraph parser (sonic-net#2890)

MSFT ADO: 24419953

This is to fix a bug where warm upgrade from old image (eg. 20181130) to new image (eg. 202012) does not update docker_routing_config_mode to the new config expected the target OS.

For eg., in 201811 DEVICE_METADATA.localhost.docker_routing_config_mode is set to unified.
After upgrade to 202012 the value is not changed. However, the expectation in newer images is that the value is separated.

The move from unified to separated was done as part of an old change: sonic-net/sonic-buildimage#2961

However, migration logic was not updated since then. Because of this miss, cross-branch warm-upgrade from 201811 to 2020212 to 202305 to latest will always keep the setting as unified.

How I did it
Added a common migration logic: update docker_routing_config_mode to the value from minigraph parser.

How to verify it
Added a new unit test. Updated old unit tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants