Sanitize create_container input for volumes_from

[fcoelho]

Client.create_container takes a volumes_from argument that should be: a string, a list of strings, or None. If an empty list or dict is passed instead, docker-py throws a weird error:

(env)[root@host ~]# python fail.py 
Traceback (most recent call last):
  File "fail.py", line 6, in <module>
    client.start(container['Id'])
  File "/root/env/lib/python2.7/site-packages/docker/client.py", line 742, in start
    self._raise_for_status(res)
  File "/root/env/lib/python2.7/site-packages/docker/client.py", line 115, in _raise_for_status
    raise APIError(e, response, explanation=explanation)
docker.client.APIError: 406 Client Error: Not Acceptable ("Cannot start container c6d6a22391b092de05b12eb97d8787fb976cf180f5db4e4a8d54b74e73f8c422: Container c6d6a22391b092de05b12eb97d8787fb976cf180f5db4e4a8d54b74e73f8c422 not found. Impossible to mount its volumes")

This happens on docker 0.9.0 and docker-py 0.3.1. There are a few differences from the output of docker inspect for a container created with volumes_from=None or volumes_from=[]. I'll create an issue on dotcloud/docker and link it here when it's done.

Edit: moby/moby#5108

[shin-]

Thanks! Can you add the case to the unit tests, so we can avoid a regression in the future?

[fcoelho]

Done, the test just checks whether VolumesFrom is passed or not to the daemon. I didn't write code that actually triggers the exception, as I thought that could change too much of the fake requests data. If you think I should go for that, I'll add changes there too

[shin-]

No that's great, thanks! (and sorry for the merging delay)