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

Expecting an object VirtualIPs but instead got Spec #11

Open
aroundthecode opened this issue Sep 13, 2017 · 6 comments
Open

Expecting an object VirtualIPs but instead got Spec #11

aroundthecode opened this issue Sep 13, 2017 · 6 comments
Labels

Comments

@aroundthecode
Copy link

I've run the service in my local swarm (docker 4 Mac) and it works perfectly

Client:
Version: 17.06.1-ce
API version: 1.30
Go version: go1.8.3
Git commit: 874a737
Built: Thu Aug 17 22:53:38 2017
OS/Arch: darwin/amd64

Server:
Version: 17.06.1-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 874a737
Built: Thu Aug 17 22:54:55 2017
OS/Arch: linux/amd64
Experimental: true

But when I deploy the same on my online swarm cluster

Client:
Version: 17.06.0-ce
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:20:36 2017
OS/Arch: linux/amd64

Server:
Version: 17.06.0-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:21:56 2017
OS/Arch: linux/amd64
Experimental: false

the dashboard only shows me the error:

Expecting an object with a field named VirtualIPs at _.services[8].Endpoint but instead got: {"Spec":{}}

Since they run the same API version (both > 1.29) I'm quite puzzled, can you provide any hint ?
thanks in advance

@killcity
Copy link

I'm also seeing the same thing. Docker 17.06.1-ce

@srigaux
Copy link

srigaux commented Oct 16, 2017

Yes, the same for me. 17.05.0-ce

@jamesmcdonald
Copy link
Contributor

jamesmcdonald commented Oct 19, 2017

This happens when services are running that are not attached to any swarm network. As a workaround, you can just make sure that every service uses at least one network, but ideally it should be able to handle that situation.

@satishsverma
Copy link

Hi, you can use this stack.yml file. It's work for my swarm cluster.

version: "3.2"

services:
  dashboard:
    image: charypar/swarm-dashboard
    privileged: true
    volumes:
      - type: bind
        source: "/var/run/docker.sock"
        target: "/var/run/docker.sock"
    ports:
      - 8080:8080
    environment:
      PORT: 8080
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager

@stevenklar
Copy link

This also happens if you use dnsrr instead of vip.

@anton-johansson
Copy link

As @stevenklar mentioned, this also happens when using endpoint_mode: dnsrr. Not sure why we don't get any virtual IP's when we inspect (I still use a network, so I should get one, right?), but maybe we shouldn't crash if we don't have one. Sure, we can't show the network connection in the dashboard, but I guess it's better than crashing?

@charypar charypar added the bug label Nov 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants