Attempt to retry_join to external-cloud IPv6 addresses results in address literal syntax errors

[odysseus654]

consul version for both Client and Server

Client: 1.0.0
Server: 0.9.2

consul info for both Client and Server

Client:

agent:
        check_monitors = 0
        check_ttls = 0
        checks = 0
        services = 0
build:
        prerelease =
        revision = 51ea240
        version = 1.0.0
consul:
        known_servers = 0
        server = false
runtime:
        arch = amd64
        cpu_count = 1
        goroutines = 35
        max_procs = 1
        os = windows
        version = go1.9.1
serf_lan:
        coordinate_resets = 0
        encrypted = true
        event_queue = 0
        event_time = 1
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 0
        member_time = 1
        members = 1
        query_queue = 0
        query_time = 1

Server:

agent:
        check_monitors = 0
        check_ttls = 1
        checks = 1
        services = 1
build:
        prerelease =
        revision = 75ca2ca
        version = 0.9.2
consul:
        bootstrap = false
        known_datacenters = 1
        leader = false
        leader_addr = [2600:1f14:e22:1502:a071:b0e6:67d0:e573]:8300
        server = true
raft:
        applied_index = 5966887
        commit_index = 5966887
        fsm_pending = 0
        last_contact = 13.999942ms
        last_log_index = 5966887
        last_log_term = 1408
        last_snapshot_index = 5964026
        last_snapshot_term = 1408
        latest_configuration = [{Suffrage:Voter ID:4ce4368f-5856-361e-e8dd-ed107                                                                                                                               ec0fa25 Address:[2600:1f14:e22:1502:a071:b0e6:67d0:e573]:8300} {Suffrage:Voter I                                                                                                                               D:29881c65-bc4b-4060-f783-7f9662751b38 Address:[2600:1f14:e22:1501:f9a:2e0c:a167                                                                                                                               :67e8]:8300} {Suffrage:Voter ID:493b7c9d-a1fa-f36a-95e9-9684ddf619ae Address:[26                                                                                                                               00:1f14:e22:1503:b05e:32d4:17c2:9e13]:8300}]
        latest_configuration_index = 5835881
        num_peers = 2
        protocol_version = 3
        protocol_version_max = 3
        protocol_version_min = 0
        snapshot_version_max = 1
        snapshot_version_min = 0
        state = Follower
        term = 1408
runtime:
        arch = amd64
        cpu_count = 1
        goroutines = 98
        max_procs = 2
        os = linux
        version = go1.8.3
serf_lan:
        coordinate_resets = 0
        encrypted = true
        event_queue = 0
        event_time = 42
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 1
        member_time = 782
        members = 9
        query_queue = 0
        query_time = 53
serf_wan:
        coordinate_resets = 0
        encrypted = true
        event_queue = 0
        event_time = 1
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 0
        member_time = 233
        members = 3
        query_queue = 0
        query_time = 1

Operating system and Environment details

Client: Windows Server 2012 R2, 1GB RAM
Server: Linux xxxx 4.9.58-18.51.amzn1.x86_64 #1 SMP Tue Oct 24 22:44:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Description of the Issue (and unexpected/desired result)

Beginning attempt to upgrade cluster to v1.0, downloaded new instance and applied updates to the config file to represent behavior changes and new features supported by v1,0

old config:

{
  "datacenter": "vpc-d29997b6",
  "bind_addr": "::",
  "data_dir": "C:\\tw\\consul\\data",
  "log_level": "INFO",
  "server": false,
  "retry_join":[
    "provider=aws tag_key=feature%3Aconsul tag_value=yes __censored__"
  ],
  "ports": {"dns":53},
  "recursors": ["10.2.0.2"],
  "encrypt": __censored__
}

new config:

{
	"datacenter": "vpc-d29997b6",
	"bind_addr": "::",
	"data_dir": "C:\\tw\\consul\\data",
	"log_level": "INFO",
	"server": false,
	"retry_join":[
		"provider=aws tag_key=feature:consul addr_type=public_v6 tag_value=yes __censored__"
	],
	"ports": {"dns":-1},
	"encrypt": __censored__,
	"ui": true
}

Result:

Consul successfully retrieves the IPv6 addresses of the servers in the cluster, but fairly obviously doesn't realize that IPV6 address literals must be wrapped in [brackets] or (parenthesis). The :8301 at the end of the address is fairly obviously a port number, which once is concatenated to the naked ipv6 literal cannot be parsed back out again.

Log Fragments or Link to gist

https://gist.github.com/odysseus654/202fad4c35a394d72c2db7b165670297

[odysseus654]

Log file after removing addr_type=public_v6 and switching back to ipv4 discovery:

https://gist.github.com/odysseus654/7363e05b1a9c2065c6f44594063dc610

[slackpad]

Hi @odysseus654 thanks for the report - looks like we need to do some filtering/cleanup of the results coming back from the AWS APIs in order to format them correctly for Go. This'll probably best be fixed down in go-discover (and hopefully in a generic place that applies to all providers) - will take a look!

[meangrape]

Same problem here. The actual error is coming from SplitHostPorts in Go's ipsock.go.

[odysseus654]

FWIW From my perspective the responsibility for resolving this lies where the host and port are combined together, to ensure that the address is properly escaped during the concatenation.

[slackpad]

FWIW From my perspective the responsibility for resolving this lies where the host and port are combined together, to ensure that the address is properly escaped during the concatenation.

You are probably right. I was looking at go-discover and it's just a list of strings, and the user could also supply addresses not formatted in the Go way, so this may be better done on the Consul side vs. go-discover.

[slackpad]

Your insight was spot-on @odysseus654!