add member to cluster by dns recovery

[zyf0330]

I want to know if I can add member to a running cluster by dns recovery way ?

[gyuho]

See https://github.com/coreos/etcd/blob/master/Documentation/op-guide/runtime-reconf-design.md#do-not-use-public-discovery-service-for-runtime-reconfiguration.

The public discovery service should only be used for bootstrapping a cluster. To join member into an existing cluster, use runtime reconfiguration API.

[xiang90]

closing because of @gyuho's reply.

[zyf0330]

Just confirm. Thanks.

[zyf0330]

When I add a member, After getting config from etcdctl member add, could I change
ETCD_INITIAL_CLUSTER option into dns recovery option?

[gyuho]

When I add a member, After getting config from etcdctl member add, could I change
ETCD_INITIAL_CLUSTER option into dns recovery option?

Can you explain more of your use case?

[zyf0330]

In the doc example, etcdctl member add gives this

added member 9bf1b35fc7761a23 to cluster

ETCD_NAME="infra3"
ETCD_INITIAL_CLUSTER="infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra3=http://10.0.1.13:2380"
ETCD_INITIAL_CLUSTER_STATE=existing

And ETCD_INITIAL_CLUSTER option specifies static way to find cluster. So I think I can replace this option with --discovery-srv example.com, so the way becomes DNS discovery. I have not tried it, but a colleague tell me that he succeeded.

[gyuho]

With ETCD_INITIAL_CLUSTER, yes. Discovery is only for initial bootstrap.

[zyf0330]

I remove a member from three-member cluster, then try to add a member.
When I use ETCD_INITIAL_CLUSTER, everything is normal.

Then I try dns discovery. The reason that I remove a member from three-member cluster and re-add it, is that I don't need to change dns srv records.
This is what I got when try to add member.

2017-09-26 09:54:09.622563 I | etcdmain: Go OS/Arch: linux/amd64
2017-09-26 09:54:09.622571 I | etcdmain: setting maximum number of CPUs to 4, total number of available CPUs is 4
2017-09-26 09:54:09.622678 I | embed: listening for peers on http://127.0.0.1:2380
2017-09-26 09:54:09.622748 I | embed: listening for client requests on 127.0.0.1:2379
2017-09-26 09:54:09.884646 N | embed: got bootstrap from DNS for etcd-server at node03=https://node03.example.com:2380
2017-09-26 09:54:09.884809 N | embed: got bootstrap from DNS for etcd-server at 0=https://node01.example.com:2380
2017-09-26 09:54:09.884823 N | embed: got bootstrap from DNS for etcd-server at 1=https://node02.example.com:2380
2017-09-26 09:54:10.017366 W | etcdserver: could not get cluster response from https://node01.example.com:2380: Get https://node01.example.com:2380/members: x509: certificate is valid for node01.example.com, not example.com
2017-09-26 09:54:10.073606 W | etcdserver: could not get cluster response from https://node02.example.com:2380: Get https://node02.example.com:2380/members: x509: certificate is valid for node02.example.com, not example.com
2017-09-26 09:54:10.074702 C | etcdmain: cannot fetch cluster info from peer urls: could not retrieve cluster information from the given urls

The problem about https has been issued in #8445 and is being fixed. And there is another problem here

2017-09-26 09:54:09.884809 N | embed: got bootstrap from DNS for etcd-server at 0=https://node01.example.com:2380
2017-09-26 09:54:09.884823 N | embed: got bootstrap from DNS for etcd-server at 1=https://node02.example.com:2380

It shows 0 and 1 not node01 and node02 as name, maybe it is index of array and I don't know whether it affects.
@gyuho

[zyf0330]

After read source code, I know that 0 and 1 are just temp name and after get cluster response while DNS Discovery process they will be right. So this is duplicate issue of #8445.