[bug] dfdaemon flag --node don't work

[yeya24]

Ⅰ. Issue Description

In master branch, maybe there is a bug for --node, I cannot specify the supernode address I want, and it always become the default value 127.0.0.1:8002

Ⅱ. Describe what happened

I started supernode in localhost:8002, and started dfdaemon with dfdaemon --node 127.0.0.1:9000, here I specified a non-exist address and expected that dfdaemon cannot work.

logs of dfdaemon

2019-09-12 23:37:43.340 INFO sign:6335 : use dfget dfget version  0.4.3
  Git commit:     9e2a93c
  Build date:     20190912-23:32:47
  Go version:     go1.12.6
  OS/Arch:        linux/amd64 from /home/parallels/hub/gowork/Dragonfly/bin/linux_amd64/dfget
2019-09-12 23:37:43.340 INFO sign:6335 : using config: {"registry_mirror":{"remote":"https://index.docker.io","certs":null,"insecure":false},"proxies":null,"hijack_https":null,"port":65001,"hostIp":"127.0.0.1","certpem":"","keypem":"","verbose":false,"maxprocs":4,"dfget_flags":null,"supernodes":null,"ratelimit":"20M","localrepo":"/home/parallels/.small-dragonfly/dfdaemon/data","dfpath":"/home/parallels/hub/gowork/Dragonfly/bin/linux_amd64/dfget"}

It is weird that "supernodes":null.

Then used docker pull ubuntu to download an image, and then dfdaemon works well, which is not what I expected.
Logs of dfclieng.log

2019-09-12 23:37:56.018 INFO sign:6481-1568345876.017 : do register result:{"code":200,"msg":"success","data":{"taskId":"25fd49a3bb8d2ab47356b297a6996d3e31fc63dc99fa4bf8ac72994f305cf843","fileLength":162,"pieceSize":4194304}} and cost:0.001s
2019-09-12 23:37:56.018 INFO sign:6481-1568345876.017 : downloading piece:{"taskID":"25fd49a3bb8d2ab47356b297a6996d3e31fc63dc99fa4bf8ac72994f305cf843","superNode":"127.0.0.1:8002","dstCid":"","range":"","result":502,"status":700,"pieceSize":0,"pieceNum":0}
2019-09-12 23:37:56.019 INFO sign:6481-1568345876.017 : pull rate result:10485760 cost:237.29µs
2019-09-12 23:37:56.019 WARN sign:6481-1568345876.017 : request piece result:{"code":601,"data":[{"range":"0-4194303","pieceNum":0,"pieceSize":4194304,"pieceMd5":"","cid":"cdnnode:10.211.55.3~25fd49a3bb8d2ab47356b297a6996d3e31fc63dc99fa4bf8ac72994f305cf843","peerIp":"127.0.0.1","peerPort":8001,"path":"/download/25f/25fd49a3bb8d2ab47356b297a6996d3e31fc63dc99fa4bf8ac72994f305cf843","downLink":0}]}
2019-09-12 23:37:56.022 INFO sign:6481-1568345876.017 : downloading piece:{"taskID":"25fd49a3bb8d2ab47356b297a6996d3e31fc63dc99fa4bf8ac72994f305cf843","superNode":"127.0.0.1:8002","dstCid":"cdnnode:10.211.55.3~25fd49a3bb8d2ab47356b297a6996d3e31fc63dc99fa4bf8ac72994f305cf843","range":"0-4194303","result":503,"status":701,"pieceSize":4194304,"pieceNum":0}
2019-09-12 23:37:56.023 INFO sign:6481-1568345876.017 : remaining piece to be written count:0
2019-09-12 23:37:56.024 INFO sign:6481-1568345876.017 : wait client writer finish cost:0.001,main qu size:0,client qu size:0
2019-09-12 23:37:56.025 INFO sign:6481-1568345876.017 : move src:/home/parallels/.small-dragonfly/data/1db1791d-6164-44be-90da-9d7cd924a737-6481-1568345876.017 to dst:/home/parallels/.small-dragonfly/dfdaemon/data/1db1791d-6164-44be-90da-9d7cd924a737 result:true cost:0.000
2019-09-12 23:37:56.025 INFO sign:6481-1568345876.017 : download successfully from dragonfly
2019-09-12 23:37:56.025 INFO sign:6481-1568345876.017 : download SUCCESS from supernode [127.0.0.1:8002] cost:0.009s length:162

Ⅲ. Describe what you expected to happen

I expected that dfget cannot register to supernode, and then dfget will just download from source. However, it registered to 127.0.0.1:8002 successfully instead of 127.0.0.1:9000 which I specified.

Ⅳ. How to reproduce it (as minimally and precisely as possible)

I think this bug relates to dfdaemon.yml file, if I don't create /etc/dragonfly/dfdaemon.yml, then the bug occur. If I create this config file, then this flag works.

1. make build
2. supernode --home-dir ~/supernode -D
3. dfdaemon --node 127.0.0.1:9000 (you can specify any address here and it will finally become 127.0.0.1:8002)

Ⅴ. Anything else we need to know?

Ⅵ. Environment:

• dragonfly version: master
• OS (e.g. from /etc/os-release): ubuntu 18.04
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[pouchrobot]

Thanks for your report, @yeya24
😱 This is a priority/P1 issue which is highest.
Seems to be severe enough.
ping @dragonflyoss/Dragonfly , PTAL.

[inoc603]

"supernodes": null seems to be caused by dragonflyoss/dragonfly#849. It fixed the config file, but broke cli flag. The root cause is how viper handles alias, which doesn't quite work for our use case. #903 should fix this, and added related tests.