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.
The tornado web aplication that was set up in the archive tests, and then
duplicated in the remote file integration tests, starts the web server,
but never stops it. This creates a stacktrace that hangs the other test
file that attempts to start the web server.
The Application class has a `listen()` function, but not a `stop()` function.
The change uses the `HTTPServer` class to set up the listening server, but
also has the necessary `stop()` function. (The `listen()` function from the
`Application` class just calls out to the `HTTPServer`'s `listen()` function,
so this works nicely here.)
We can then call the `stop()` function in the `tearDownClass` class method.
I also removed some duplicate STATE_DIR definitions.
