Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

containers field in NetworkDetails can be null (on Docker Swarm) #290

Open
pitkley opened this issue Apr 18, 2021 · 0 comments
Open

containers field in NetworkDetails can be null (on Docker Swarm) #290

pitkley opened this issue Apr 18, 2021 · 0 comments

Comments

@pitkley
Copy link
Contributor

pitkley commented Apr 18, 2021

Calling Docker::new().networks().list(&Default::default()).await on a Docker Swarm manager node (potentially also on non-manager nodes, I wasn't able to reproduce this though) causes the following error:

SerdeJsonError(
    Error("invalid type: null, expected a map", line: 1, column: 364),
),

I have analyzed this and have identified that in a Swarm Docker will have a special network called ingress which, as far as I understood, is used for routing ingress traffic within the cluster to a worker node that can respond to it. Apparently this network can never have containers associated to it, which the Docker API under GET /networks (as called by .networks().list()) seems to indicate by returning a null in the containers key instead of an empty object. For clarification, following is the reduced output for GET /networks on a Docker Swarm manager node:

[
  {
    "Name": "ingress",
    // ...
    "Containers": null,
    // ...
  },
  // ...
  {
    "Name": "bridge",
    // ...
    "Containers": {},
    // ...
  },
  // ...
]

Unfortunately shiplift expects this field to always be present (@v0.7.0, @master), which causes the error shown above.

A simple non-breaking solution would probably be to just annotate the field with #[serde(default)], for which I'm happy to open a PR, but I'm noticing that since 0.7.0 some major refactorings seem to have taken place, where backwards-compatibility might not be a concern and actually redefining the field as Optional<HashMap<...>> might be the "more correct" solution.

Do you have any preference on the solution chosen? I'm happy to provide a PR for either one.


  • Crate version: 0.7.0, master @ 9750d29
  • OS: Linux (CentOS 7)
  • Output of running docker version on the command line:
Client: Docker Engine - Community
 Version:           20.10.6
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        370c289
 Built:             Fri Apr  9 22:45:33 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.6
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd2
  Built:            Fri Apr  9 22:43:57 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant