In the 0.2.0-rc1 release binary, /machines call doesn't return the correct advertised IP #378

Closed
alexzorin opened this Issue Dec 6, 2013 · 7 comments

Comments

Projects
None yet
4 participants

Not quite sure what is going on, but it doesn't seem like the rc1 binary posted in releases matches the behavior of the source.

Specifically, /machines seems to lie about the advertised IP address of a node when using the binary, but its fine using source.

Just thought I'd note it here in case anyone ran into this snag. In my case, SSL verification failed because 127.0.0.1 wasn't listed as an IP subjAltName for the etcd server, only the intended IP (172.17.42.1) was.

Either I'm using git wrong or the release might be worth rebuilding ...

Build from source

root@precise64:/go/src/github.com/coreos/etcd# git checkout v0.2.0-rc1
HEAD is now at f499100... Merge branch 'master' of https://github.com/benbjohnson/etcd into benbjohnson-master
root@precise64:/go/src/github.com/coreos/etcd# ./build
root@precise64:/go/src/github.com/coreos/etcd# ./etcd -version
v0.2.0-rc1
root@precise64:/go/src/github.com/coreos/etcd# ./etcd -c 172.17.42.1:4001 -f
[etcd] Dec  6 00:33:40.308 WARNING   | Using hostname precise64 as the machine name. You must ensure this name is unique among etcd machines.
[etcd] Dec  6 00:33:40.308 WARNING   | Using the directory precise64.etcd as the etcd configuration directory because a directory was not specified.
[etcd] Dec  6 00:33:40.309 INFO      | etcd server [name precise64, listen on 172.17.42.1:4001, advertised url http://172.17.42.1:4001]
[etcd] Dec  6 00:33:40.313 INFO      | URLs:  / precise64 (http://127.0.0.1:7001)
[etcd] Dec  6 00:33:40.313 WARNING   | the entire cluster is down! this machine will restart the cluster.
[etcd] Dec  6 00:33:40.313 INFO      | raft server [name precise64, listen on 127.0.0.1:7001, advertised url http://127.0.0.1:7001]
[etcd] Dec  6 00:33:50.433 INFO      | URLs: precise64 / precise64 (https://172.17.42.1:4001)

... in another terminal

root@precise64:/go/src/github.com/coreos/etcd# curl http://172.17.42.1:4001/v2/machines
https://172.17.42.1:4001

OK, seems good.

Using rc1 release binary

root@precise64:~/etcd-v0.2.0-rc1-Linux-x86_64# ./etcd -c 172.17.42.1:4001 -f
[etcd] Dec  6 00:38:01.600 WARNING   | Using hostname precise64 as the machine name. You must ensure this name is unique among etcd machines.
[etcd] Dec  6 00:38:01.600 WARNING   | Using the directory precise64.etcd as the etcd configuration directory because a directory was not specified.
[etcd] Dec  6 00:38:01.601 INFO      | etcd server [name precise64, listen on 172.17.42.1:4001, advertised url http://172.17.42.1:4001]
[etcd] Dec  6 00:38:01.609 INFO      | URLs:  / precise64 (http://127.0.0.1:7001)
[etcd] Dec  6 00:38:01.609 WARNING   | the entire cluster is down! this machine will restart the cluster.
[etcd] Dec  6 00:38:01.609 INFO      | raft server [name precise64, listen on 127.0.0.1:7001, advertised url http://127.0.0.1:7001]

results in ...

root@precise64:~/etcd-v0.2.0-rc1-Linux-x86_64# curl http://172.17.42.1:4001/v2/machines
https://127.0.0.1:4001

Which is wrong.

Contributor

xiang90 commented Dec 6, 2013

@alexzorin We messed up -f flag in rc1. It probably caused by that.

Owner

philips commented Dec 6, 2013

@alexzorin Odd. I will rebuild it really quick.

It would likely be worth it to start using master. A number of changes to the v2 API just landed. http://thread.gmane.org/gmane.comp.distributed.etcd/48

Owner

philips commented Dec 6, 2013

@xiangli-cmu Ah, good call. Yes, that is probably it.

@xiangli-cmu both cases above are labelled "rc1" and are in separate working directories, so I'm not quite sure of your meaning. I accept that -f is broken in rc1, but both source and binary release it should be broken, no?

Anyway, I am very much looking forward to the v2 API changes stabilising, good work :)

Contributor

xiang90 commented Dec 6, 2013

@alexzorin Clean the working directory of etcd. The problem is that -f does not help you to clean it up and update the configuration.

Contributor

shoe commented Dec 23, 2013

Is this resolved?

Owner

philips commented Dec 30, 2013

Closing. Please reopen if this wasn't resolved.

@philips philips closed this Dec 30, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment