Before, if the driver parameter wasn't specified, the dockerng state
module's volume_present() function would try to delete the volume and
recreate it. Now it simply ignores the existing volume's driver
setting and returns success.
Note that this change assumes that if the driver is unspecified then
the user means "I don't care what the driver is", not "I care that the
driver matches the Docker default".
05782aa introduced a regression in which only one repo's pillar data
would be evaluated if more than one repo was configured under the same
"git" entry in ext_pillar.
The reason for this is that the ``pillar_roots`` list that we build
always has the same order, and that order of precedence means that when
the Pillar class goes to grab the top file, it always gets the first one
in the list. So when processing the pillar data for the 2nd source, it
grabs the first source's top.sls file instead, and when it doesn't find
SLS matches no pillar data is compiled for that 2nd source.
This fixes the problem by ensuring that the pillar_dir currently being
processed is always first in the ``pillar_roots`` list, so that the
correct top file is grabbed.
Fixes#30869.
This prevents the master's maintenance process from attempting to run a
fetch while GitBase.init_remotes() is in the process fetching a
newly-added remote.
We have proper locking in place, so there is no danger of a race
condition, but this does suppress the warning generated when an update
lock is in place at the time a fetch is attempted.
When configured to use a gitpython-based ext_pillar, salt-call --local (I don't have a master) was giving the error:
Failed to checkout <branch> from git_pillar remote '<repo location>': remote ref does not exist
regardless of whether the branch existed or not. Poking around in the cache directory, I found that the cloned repository had a remote named 'origin' set, but no fetch had ever been done, so 'git checkout' would always fail. It doesn't know about any branches yet.
Adding the fetch here, immediately after creating the remote, resolves the problem.
I'm not totally sure this is the _correct_ fix as I'm not familiar with this code, and this code is used in many situations, not just minced. But I believe it to be harmless in the worst case, a redundant fetch.
6d747df broke this by returing the name being searched for instead of
the state ID, causing the traceback found in #30820.
This fixes#30820 by returning the state ID and not the desired name.
