This squelches a spurious warning that we get due to rewriting the low
data such that the name and version are aggregated under the "pkgs" arg,
with the "version" key remaining in the low chunk.
This fixes an issue in which states which contained a single package
name (no "pkgs" or "sources") paired with a "version" argument, were
having the version ignored. This is because just the name was being
added to the aggregated "pkgs".
Since we're munging low data to aggregate states, this bug wouldn't even
result in the state failing if a different version were installed.
Doing so will cause problems trying to install as Salt does not support
installing from both binary packages and repository packages in the same
call to pkg.install.
The cloud roster retrieves a minions's profile, provider and driver
names from the cloud cache index and then issues the show_instance
action to get the minions's IP address. If the minion wasn't found in
the cloud cache index, the cloud roster stops. However, the cloud cache
index is only maintained by the EC2 driver, making the cloud roster only
usable with EC2.
Don't stop if a minion wasn't found in the cloud cache index, trying
show_instance anyway. In this way, although it's impossible to get the
minion's profile, the cloud roster is applicable to cloud providers
other than EC2.
If the show_instance action failed on a node, the node's name would be
added to a list located at 'Not Actioned/Not Running' key of a
dictionary returned by the action. Ensure that a target node isn't
included into that list.
Pass the vm_ variable with provider and profile info to
salt.utils.cloud.ssh_usernames in order to lookup ssh_username not only
in the main salt-cloud config file but in provider and profile
configuration as well. It is the same way all other settings are
retrieved in the cloud roster.
The cloud roster places an instance's info under 'tgt' key in the
dictionary it returns. Because of this salt-ssh reports host name 'tgt'
instead of the specified in the command line. Fix it.
The cloud roster expects an additional nest level when extracting an
instance's info from the result of the show_instance action. It looks
for (which is what show_instance of EC2 driver returned prior to
2016.3):
info[provider][driver][name][name]
whereas the correct location is
info[provider][driver][name]
Fix it.
A path to salt-cloud config file is hardcoded into the cloud roster, so
it won't work with custom conf dir. Remove the hardcoded path and
construct it using __opts__['conf_file'].
This provides a natural solution to the chicken-and-egg problem
identified in the FAQ. It also changes the name of the event in the
reactor example, as I think we may have stopped sending the legacy
(i.e. not-namespaced) events, so the "minion_start" event in the example
would be incorrect.
