How to reproduce the issue:
```py
>>> import docker
>>> cli = docker.from_env()
>>> cli.secrets.create(name="any_name", data="1")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/docker-py/docker/models/secrets.py", line 10, in __repr__
return "<%s: '%s'>" % (self.__class__.__name__, self.name)
File "/home/docker-py/docker/models/secrets.py", line 14, in name
return self.attrs['Spec']['Name']
KeyError: 'Spec'
```
The exception raises because create secrets API `/secrets/create` only
return the `id` attribute:
https://docs.docker.com/engine/api/v1.41/#operation/SecretCreate
The secret model is created using just the `id` attribute and fails
when looking for Spec.Name attribute.
```py
def __repr__(self):
return "<%s: '%s'>" % (self.__class__.__name__, self.name)
```
```py
@property
def name(self):
return self.attrs['Spec']['Name']
```
I came up with a ugly solution but will prevent the problem to happen
again:
```py
def create(self, **kwargs):
obj = self.client.api.create_secret(**kwargs)
+ obj.setdefault("Spec", {})["Name"] = kwargs.get("name")
return self.prepare_model(obj)
```
After the API call, I added the name attribute to the right place to be
used on the property name.
```py
>>> import docker
>>> cli = docker.from_env()
>>> cli.secrets.create(name="any_name", data="1")
<Secret: 'any_name'>
```
It isn't the most elegant solution, but it will do the trick.
I had a previous PR #2517 when I propose using the `id` attribute
instead of `name` on the `__repr__` method, but I think this one will be better.
That fixes#2025
Signed-off-by: Felipe Ruhland <felipe.ruhland@gmail.com>
Docker API 1.32 added support for providing options to a network driver
via EndpointConfig when connecting a container to a network.
Signed-off-by: Mike Haboustak <haboustak@gmail.com>
This fix lets the responsability of changing the
protocol to `parse_host` afterwards, letting
`base_url` with the original value.
Signed-off-by: Ulysses Souza <ulysses.souza@docker.com>
This test was testing for a 500 status, but this status
is actually a bug in the API (as it's due to an invalid
request), and the API should actually return a 400 status.
To make this test handle both situations, relax the test
to accept either a 4xx or 5xx status.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Check that the return value against the various combination of
parameters this function can take (tty, stream, and demux).
This commit also fixes a bug that the tests uncovered a bug in
consume_socket_output.
Signed-off-by: Corentin Henry <corentinhenry@gmail.com>
Pulling an image with option `stream=True` like this:
```
client.api.pull('docker.io/user/repo_name', tag='latest', stream=True)
```
without consuming the generator oftentimes results in premature drop of the connection. Docker daemon tries to send progress of pulling the image to the client, but it encounters an error (broken pipe) and therefore cancells the pull action:
```
Thread 1 "dockerd-dev" received signal SIGPIPE, Broken pipe.
ERRO[2018-09-03T05:12:35.746497638+02:00] Not continuing with pull after error: context canceled
```
As described in issue #2116, even though client receives response with status code 200, image is not pulled.
Closes#2116
Signed-off-by: Przemysław Adamek <adw1n@users.noreply.github.com>
The method now uses parsing methods from urllib to better split provided URLs.
Addresses containing query strings, parameters, passwords or fragments no longer fail silently.
SSH addresses containing paths are no longer accepted.
Signed-off-by: Joffrey F <joffrey@docker.com>
Anthony Sottile
Anca Iordache
Felipe Ruhland
Ulysses Souza
Nicolas De Loof
aiordache
WojciechowskiPiotr
Sebastiaan van Stijn
Mariano Scazzariello
Ville Skyttä
Lucidiot
Ulysses Souza
Mike Haboustak
Niklas Saari
Matt Fluet
Joffrey F
Ian Campbell
Hannes Ljungberg
Corentin Henry
Joffrey F
adw1n