allow configurable paramiko logging level

[blackboxsw]

Since ever instance._ssh_connect call sets and resets paramiko logging level to INFO, any consumer of pycloudlib gets logging spam for every single cmd execution making it tough to sift though CI logs.

Let's make logging level configurable on the cloud, and reflect that logging level to dependencies like paramiko if called/setup. Otherwise your CI runs look like:

INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
INFO:paramiko.transport:Authentication (publickey) successful!
INFO:paramiko.transport.sftp:[chan 0] Opened sftp connection (server version 3)
--- Push /tmp/pr_source.tar.gz -> i-0fb3543500b23e7b6:/tmp
---- Pull i-0fb3543500b23e7b6:/tmp/ubuntu-advantage-pro.deb /tmp/
--- Pull i-0fb3543500b23e7b6:/tmp/ubuntu-advantage-tools.deb /tmp/
/INFO:paramiko.transport.sftp:[chan 0] sftp session closed.

--- Launching VM to create a base image with updated ubuntu-advantage
--- Launching AWS PRO image ami-0a64b4493bc9dc321(trusty)
/INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
INFO:paramiko.transport:Authentication (publickey) successful!
|--- aws PRO instance launched: i-0f3fd86752859bcb4. Waiting for ssh access
\INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
|INFO:paramiko.transport:Authentication (publickey) successful!
INFO:paramiko.transport.sftp:[chan 0] Opened sftp connection (server version 3)
INFO:paramiko.transport.sftp:[chan 0] sftp session closed.
INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
INFO:paramiko.transport:Authentication (publickey) successful!
INFO:paramiko.transport.sftp:[chan 0] Opened sftp connection (server version 3)
INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
INFO:paramiko.transport:Authentication (publickey) successful!
/INFO:paramiko.transport.sftp:[chan 0] sftp session closed.
--- Creating  base image snapshot from vm i-0f3fd86752859bcb4
INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
INFO:paramiko.transport:Authentication (publickey) successful!
\INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_6.6.1p1)
INFO:paramiko.transport:Authentication (publickey) successful!

[OddBloke]

Since ever instance._ssh_connect call sets and resets paramiko logging level to INFO

Why does it do this?

Let's make logging level configurable on the cloud, and reflect that logging level to dependencies like paramiko if called/setup.

IMO we should be following the advice in the Python docs and logging to pycloudlib.* logger names, which allows consumers of pycloudlib to configure logging for all the messages we produce (by configuring logging.getLogger("pycloudlib")). (A brief inspection of the code suggests to me that this is how things are laid out currently.)

We should also document what loggers each of the clouds uses, so that consumers can configure those loggers as they wish. I don't think we should be setting levels etc. within the library code, because that makes it very difficult for consumers to opt into more logging themselves. Consider a consumer who want to emit paramiko's DEBUG-level logging to a file: the fact we call setLevel(logging.INFO) within the library means that they cannot do this, the DEBUG-level logging will disappear after _ssh_connect or _sftp_connect.

For further background, I think it's worth noting that a cloud will likely have more than one logger associated with it: paramiko and its cloud-specific library's logger. We do not necessarily want these loggers to have the same level, because they may not treat each level at the same importance: we may want WARNING for paramiko, but INFO for the library's logger. If we make "logging level configurable on the cloud" then we have to decide in the library what the correct combination of levels for these loggers is; I don't think we can make that determination for all possible consumers in the library itself.

Now this isn't to say that we can't provide helpers for consumers of the library which configure logging in a particular common way, but those should be separate utilities that consumers can choose to use to simplify their logging setup, rather than integrated into the operation of the library.