Fix ParamikoSSHClient.run() so that it works in Python 3.4.1

[ereyes01]

I was trying to do the following using apache-libcloud==0.15.1 on Python 3.4.1:

• Run deploy_node to create an EC2 node with a MultiStepDeployment.
• The MultiStepDeployment consists of 2 FileDeployment's followed by 1 ScriptDeployment

The deploy_node would work fine in Python 2.7.6 but failed when I switched to Python 3,4,1 with the following:

DeploymentError                           Traceback (most recent call last)
<ipython-input-18-79924dc2c1dc> in <module>()
      2                           ex_security_groups=[SECURITY_GROUP_NAME],
      3                           ex_keyname=KEY_NAME, deploy=deployment, ssh_username=USERNAME,
----> 4                           ssh_key=PRIVATE_KEY_PATH)
      5 print(node)

/home/ereyes/.pyenv/versions/deploy3/lib/python3.4/site-packages/libcloud/compute/base.py in deploy_node(self, **kwargs)
    924         if deploy_error is not None:
    925             raise DeploymentError(node=node, original_exception=deploy_error,
--> 926                                   driver=self)
    927 
    928         return node

DeploymentError: <DeploymentError: node=i-1ff25335, error=<LibcloudError in <libcloud.compute.drivers.ec2.EC2NodeDriver object at 0x7f91a0782d68> "Failed after 3 tries: string argument expected, got 'bytes'">, driver=<libcloud.compute.drivers.ec2.EC2NodeDriver object at 0x7f91a0782d68>>

After instrumenting the code to print more informative stack traces, I located the source of the Exception, which was in ParamikoSSHClient.run(). The code where a data chunk is obtained from chan.recv() returns a bytes object in Python 3, where it presumably returns a descendant of basestring in Python 2. This object is then passed to stdout.write() (or stderr.write), which blows up because it's not a stringy value.

My change decodes the bytes into strings as they are passed into those write() methods.

This change made deploy_node() work in my code for Python 3.4.1. I'm not sure if the same type of bug exists elsewhere, but this fix is what I needed to unblock myself.

Thanks for the excellent library, and I hope this helps.

[Kami]

Good catch, the same issue should exist in all the Python 3.x versions where bytes / unicode handling has been changed.

[Kami]

Looks good.

Only thing I would do is wrap data with libcloud.utils.py3 with b function call to be on the safe side and make sure that type of data is in fact bytes in Python 3 (if for some reason, data is not bytes in Python 3, decode call will throw).

I'll go ahead and make this change.

[Kami]

Merged into trunk. Thanks.

[ereyes01]

Thank you for merging, and for the quick response!