Give each deltaproxy sub-proxy its own loader namespace (#70144) - #70211
Open
ggiesen wants to merge 1 commit into
Open
Give each deltaproxy sub-proxy its own loader namespace (#70144)#70211ggiesen wants to merge 1 commit into
ggiesen wants to merge 1 commit into
Conversation
) Sub-proxies were built without a ``loaded_base_name``, so the loader put their execution modules in one shared namespace and handed every sub-proxy the same module objects. Whichever sub-proxy packed a module last then owned that module's ``__opts__`` for the life of the process. With ``multiprocessing: False`` -- what a proxy talking to a real device runs, since a live NETCONF/SSH session cannot be forked -- targeting two or more sub-proxies in a single job left every later SLS render resolving grains, pillar, ``cachedir`` and ``id`` from the wrong sub-proxy, and it stayed wrong until the deltaproxy was restarted. Execution modules were unaffected because their grains are repopulated per job, which is why the failure only showed up in rendering. ``Minion._load_modules`` also dropped ``loaded_base_name`` on its non-multimaster branch, so handing sub-proxies a namespace had no effect on its own; both changes are needed together.
twangboy
approved these changes
Sep 2, 2026
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
2 participants
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.
What does this PR do?
Fixes #70144. Each deltaproxy sub-proxy now gets its own loader namespace, so the loader stops handing every sub-proxy the same execution-module objects.
What issues does this PR fix?
Fixes #70144
Root cause
Sub-proxies were built without a
loaded_base_name, so they all shared one module namespace. Whichever sub-proxy packed a module last owned that module's__opts__for the life of the process.Minion._load_modulesalso droppedloaded_base_nameon its non-multimaster branch (the multimaster branch passes it), so handing sub-proxies a namespace had no effect on its own -- both changes are required.With
multiprocessing: False-- what a proxy talking to a real device runs, since a live NETCONF/SSH session cannot be forked -- targeting two or more sub-proxies in a single job left every later SLS render resolving grains, pillar,cachedirandidfrom the wrong sub-proxy, and it stayed wrong until the deltaproxy was restarted.Execution modules were unaffected because their grains are repopulated per job, which is why the failure only showed up in rendering.
__grains__still read correctly while__opts__did not, and the SLS render derives grains fromopts["grains"], so the rendered identity was the wrong sub-proxy's.Note for reproducing:
multiprocessing: Falseis required. With the defaultTrueeach job is forked and the issue does not reproduce.Previous Behavior
On a deltaproxy running
multiprocessing: False, targeting two or more sub-proxies in one job made every later SLS render resolve grains, pillar,cachedirandidfrom the wrong sub-proxy, silently and until restart.New Behavior
Each sub-proxy renders with its own identity, in single-target and multi-target jobs alike, and stays correct afterwards.
Merge requirements satisfied?
Tests written?
Yes. Two unit tests in
tests/pytests/unit/metaproxy/test_deltaproxy.py: each sub-proxy gets a distinct, id-derivedloaded_base_name, and_load_modulesforwards it tosalt.loader.minion_mods. Both fail against unmodified 3008.x. The fix was also verified end to end against a live deltaproxy on 3008.2, where the reporter's four-step reproducer now returns the correct identity at every step.Commits signed with GPG?
No