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

Volume stores from remote nodes aren't correctly identified. #186

Closed
skx opened this issue Sep 4, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@skx
Copy link
Contributor

commented Sep 4, 2015

I setup a (self-compiled) installation of version 0.70 beta linux amd64, on a pair of nodes:

  • media1
    • This runs the master-server, with replication enabled.
    • This runs a single volume server.
  • media2
    • This runs a single volume server.

The clients were started like this:

  • media1
    • weed master -mdir /srv/weed/master -defaultReplication=001
    • weed volume -dir=/srv/weed/data -max=1 -mserver=media1:9333 -port.public=80 -port=8001
  • media2
    • weed volume -dir=/srv/weed/data -max=1 -mserver=media1:9333 -port.public=80 -port=8002

This resulted in the two volume-servers connecting to the single-master, as expected, however the logging on the master showed connections from:

  • localhost:8001
  • localhost:8002

This meant that the master could only talk to one of the volume-servers, and thus all uploads failed because I'd mandated replication such that writes went to both.

To resolve this problem I had to explicitly set the hostname/IP address of the volume-servers:

  • weed volume -dir=/srv/weed/data -max=1 -mserver=media1:9333 -ip=$(hostname) -port.public=80 -port=8001
  • weed volume -dir=/srv/weed/data -max=1 -mserver=media1:9333 -ip=$(hostname) -port.public=80 -port=8002

Did I miss an important piece of documentation, or does this seem like a bug? Looking at the code I see go/weed/volume.go contains the following setup:

    if *v.ip == "" {
            *v.ip = "127.0.0.1"
    }

So clearly the behaviour I'm seeing comes from that - if I don't set an IP explicitly it defaults to local-host which isn't going to work in a real deployment. I updated that code to use that from here, and things started working as expected:

In conclusion:

  • Either I've missed something obvious, or ..
  • The default should be changed to use the default IP of the host rather than 127.0.0.1 for volume-servers.

Feedback/corrections welcome. Thanks for the great project, too, lest you think I'm just complaining without appreciating your enormous effort!

@chrislusf

This comment has been minimized.

Copy link
Owner

commented Sep 4, 2015

Thanks for such a long and detailed writing!

The default values are just for playing around at first, not in real production.

I bet you are not setting up production servers, but just trying it. Do you want to fail fast and find out this setup issue now or after it's a few days on production?

Some computer has multiple IP addresses, or IPv6 plus IPv4, or IPv6 only. Relying on guessing one of them is not helping production cases. Your network may change one day. The guessed value also depends on ordering. So someday the server may start fine, someday the server can not work...

So I prefer fail fast and require users have to explicitly set production values themselves. The guessing magic may give users a false sense of "correct setup".

@skx

This comment has been minimized.

Copy link
Contributor Author

commented Sep 5, 2015

Your explanation makes sense, thanks for the prompt response!

@skx skx closed this Sep 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.