Closed ambsw-technology closed 7 years ago
That was the API. Here's the CLI error at the same place:
DEBUG:dockerfabric.base:Creating new DockerCliConnections connection for key ('172.24.2.11', None) with args: (), kwargs: {}
DEBUG:paramiko.transport:[chan 18] Max packet in: 32768 bytes
DEBUG:paramiko.transport:[chan 18] Max packet out: 32768 bytes
DEBUG:paramiko.transport:Secsh channel 18 opened.
DEBUG:paramiko.transport:[chan 18] Sesch channel 18 request ok
DEBUG:paramiko.transport:[chan 18] Sesch channel 18 request ok
DEBUG:paramiko.transport:[chan 18] EOF received (18)
DEBUG:paramiko.transport:[chan 18] EOF sent (18)
Traceback (most recent call last):
File "/mnt/data/.virtualenvs/build_deploy/local/lib/python2.7/site-packages/fabric/main.py", line 756, in main
*args, **kwargs
File "/mnt/data/.virtualenvs/build_deploy/local/lib/python2.7/site-packages/fabric/tasks.py", line 426, in execute
results['<local-only>'] = task.run(*args, **new_kwargs)
File "/mnt/data/.virtualenvs/build_deploy/local/lib/python2.7/site-packages/fabric/tasks.py", line 173, in run
return self.wrapped(*args, **kwargs)
File "/data/apex-server/build_deploy/src/fabfile.py", line 812, in setup_service_graylog
pull_required_containers()
File "/data/apex-server/build_deploy/src/fabfile.py", line 1957, in pull_required_containers
docker_client.pull(env.docker_maps.containers[container].image)
File "/mnt/data/.virtualenvs/build_deploy/local/lib/python2.7/site-packages/dockerfabric/cli.py", line 113, in pull
cmd_str = self._out.get_cmd('pull', repo_tag, **kwargs)
File "/mnt/data/.virtualenvs/build_deploy/local/lib/python2.7/site-packages/dockermap/client/cli.py", line 263, in get_cmd
return '{0}{1} {2}'.format(cmd_prefix or '', self._cmd, ' '.join(cmd_args))
TypeError: sequence item 1: expected string or Unicode, _NotSet found
If you use code similar to what you described when reporting the client parsing errors, there has been a change in the containers
property in Docker-Map from 0.7.0
to 0.7.1
. It was intended to be working similar to several other objects (e.g. the volumes
property) as
containers['c1']
is equivalent to containers.c1
);Unfortunately the behavior was not as documented which went unnoticed for a while. So the code from your earlier example could be changed similar to this:
for container_name, container_config in env.docker_maps.containers:
docker_client.pull(container_config.image)
Whereas the attribute access is just an additional feature that should not cause any issues, the iteration behavior change probably should have been mentioned in the change log.
Thanks for the explanation.
Upgraded. When I reached code to pull my repositories, I get the following:
Probably won't dig into the issue tonight, but wanted to at least get it reported.