Make the SONiC port_config path configurable - #2563
Merged
Merged
Conversation
The directory holding the per-HWSKU port_config .ini files was hardcoded to /etc/sonic/port_config, which only exists inside the conductor image -- the Containerfile copies files/sonic/port_config there. A generator run from a checkout instead, as in local development, finds nothing at that path, and planting the files under /etc/sonic to work around it needs root. Introduce a SONIC_PORT_CONFIG_PATH setting in osism.settings, following the existing SONIC_* environment variable convention, and wire constants.PORT_CONFIG_PATH to it. The default is the previous hardcoded path, so container behaviour is identical; setting the variable points the generator at files/sonic/port_config/ in the checkout instead. Tests cover the default, the environment override, and the settings-to-constants wiring. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- In
test_port_config_path_follows_settings, consider usingmonkeypatch.setattr(and possibly the existingreload_settingsfixture) instead of manually mutatingsettings_module.SONIC_PORT_CONFIG_PATHand handling reloads withtry/finally, to keep test setup/teardown more consistent and less error-prone.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `test_port_config_path_follows_settings`, consider using `monkeypatch.setattr` (and possibly the existing `reload_settings` fixture) instead of manually mutating `settings_module.SONIC_PORT_CONFIG_PATH` and handling reloads with `try/finally`, to keep test setup/teardown more consistent and less error-prone.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First of the series tracked in #2562, which explains the ordering and what each
PR covers. This one stands on its own — it is a production change with an
unchanged default, and nothing later in the series is needed to review it.
The problem
PORT_CONFIG_PATHwas hardcoded to/etc/sonic/port_config, which exists onlyinside the conductor image:
Containerfile:21copiesfiles/sonic/port_config/there. A generator run from a checkout instead — local development — finds
nothing at that path, and the workaround is to plant the
.inifiles under/etc/sonic, which needs root.The change
Add
SONIC_PORT_CONFIG_PATHtoosism/settings.py, following the existingSONIC_*environment variable convention, and wireconstants.PORT_CONFIG_PATHto it.The default is the previous hardcoded path, so container behaviour is
identical and nothing in production moves. Setting the variable points the
generator at
files/sonic/port_config/in the checkout instead.Tests
Three cases: the setting's default, the environment override, and the
settings-to-constants wiring — the last because
constants.PORT_CONFIG_PATHisassigned at import time, so a test that only checked the setting would not catch
the wiring being dropped.