This code is breaking when server names with multiple periods are used - for
example, name=server1.prod.dc1 domain=example.com. Simply "split and use first
one isn't the reverse operation of "'.'.join([name, domain])" which is done
when VM is created here: 9dcd11c155 (diff-ac8112a3f8d2ebde0edf104797fe64d7)
We've been running with these changes for a while and don't have any issues
creating or destroying instances.
The caveat that some operations (such as destroying) through SoftLayer API
require hostname (without domain) is already documented in Salt and still
applies.
group no longer fails when domain is not specified
group.present now accepts group names without domains
local groups are assumed if domain is not specified
documentation improved
moved fix_local_user function to salt.utils.win_functions
now called get_sam_name
If a location isn't passed to list_nodes_full, we can just use get_location().
Of no location is set in the provider, it will just use get_location().
The problem with the lookup if there are profiles, is the way that the
provider/driver was changed in the last release, if it just uses the profile
directly, it will fail when trying to do a full list.
Then for multiple locations being called, each provider has to have a location
in it, and will be called once, as it stands now, if you have multiple
providers, minions from each provider could be doubled up with this lookup.
This change should meet all the needs that this if statement was added for, and not fail in 2017.7
The Testinfra module had a line where the collection of passed arguments was silently overwritten so that it would not actually perform any assertions. Updated the variable names to address the issue of the parameters being clobbered so that asertions are performed properly.
The Testinfra module had a line where the collection of passed arguments was silently overwritten so that it would not actually perform any assertions. Updated the variable names to address the issue of the parameters being clobbered so that asertions are performed properly.
The git.latest state runs a `git ls-remote` on the remote repo to
discover which SHA it should end up at, and whether or not it needs to
fetch from the repo to get the commit it needs. However, since we
fast-forward using a `git merge` to the branch specified in the `rev`
argument, this leaves the state susceptible to a race condition when
someone pushes to the remote repo between when we run the `git
ls-remote` and when we fetch the remote repo. We will successfully
fast-forward to the head of the branch, but that branch will be pointing
to a different commit than the one identified in the `git ls-remote`, so
we will report the state as having failed.
This commit fixes that race condition by fast-forwarding to the commit
identified in the `git ls-remote`, rather than to the branch named by
`rev`.
NOTE: This means that in these edge cases, we will report a `True`
result despite the head of the branch having advanced past the commit to
which we fast-forwarded, but that seems like a reasonable trade-off for
avoiding a race condition. If we repeated the `git ls-remote` after
fetching, we'd just be opening up a window (albeit a smaller one) for
another race condition.
