Supervisor cannot bind to IPv6 addresses, should bind both v4 and v6 by default

[HT154]

I noticed that the supervisor only binds to 0.0.0.0:9631 and 0.0.0.0:9638. I'm trying to get Habitat working in an IPv6-only environment. When I attempted to set the listen addresses via the hab sup run command, I encountered errors. This appears to be a bug in hab-sup. Once this is fixed, the supervisor's default behavior should be to bind to both 0.0.0.0 and [::] addresses.

OS: Oracle Linux 7.4 Backtrace:

# RUST_LOG=debug RUST_BACKTRACE=1 DEBUG=1 hab sup run --listen-gossip '[::]:9639' --override-name test --listen-http '[::]:9632'
DEBUG 2018-05-18T17:30:23Z: habitat_common::ui: InputStream(stdin): { is_a_terminal(): true }
DEBUG 2018-05-18T17:30:23Z: habitat_common::ui: OutputStream(stdout): { is_colored(): true, supports_color(): true, is_a_terminal(): true }
DEBUG 2018-05-18T17:30:23Z: habitat_common::ui: OutputStream(stderr): { is_colored(): true, supports_color(): true, is_a_terminal(): true }
DEBUG 2018-05-18T17:30:23Z: habitat_core::os::process::imp: Calling execvp(): ("/hab/pkgs/core/hab-launcher/7241/20180321162126/bin/hab-launch") ["run", "--listen-gossip", "[::]:9639", "--override-name", "test", "--listen-http", "[::]:9632"]
DEBUG 2018-05-18T17:30:23Z: habitat_launcher::server: Starting Supervisor...
hab-sup(MN):
hab-sup(MN): CAUTION: Running more than one Habitat Supervisor is not recommended for most
hab-sup(MN): CAUTION: users in most use cases. Using one Supervisor per host for multiple
hab-sup(MN): CAUTION: services in one ring will yield much better performance.
hab-sup(MN):
hab-sup(MN): CAUTION: If you know what you're doing, carry on!
hab-sup(MN):
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Creating data directory: /hab/sup/test/data
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Creating specs directory: /hab/sup/test/specs
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Creating composites directory: /hab/sup/test/composites
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Cleaning cached health checks
hab-sup(MR): Supervisor Member-ID 7ac23565437f496e8f9778d34cd1e1e9
hab-sup(MR): Starting gossip-listener on [::]:9639
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Header Version: 2
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Header Size: 64
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Header: Header { member_len: 0, service_len: 0, service_config_len: 0, service_file_len: 0, election_len: 0, update_len: 0, departure_len: 0 }
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager::spec_watcher: SpecWatcher(/hab/sup/test/specs) thread starting
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading membership list from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading service rumors from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading service-config rumors from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading service-file rumors from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading election rumors from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading update election rumors list from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_butterfly::rumor::dat_file: Reading departure rumors list from /hab/sup/test/data/7ac23565437f496e8f9778d34cd1e1e9.rst
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: gossip-listener started
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Writing census state to disk
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Writing butterfly state to disk
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: Writing services state to disk
hab-sup(MR): Starting http-gateway on [::]:9632
DEBUG 2018-05-18T17:30:23Z: habitat_sup::manager: http-gateway started
thread 'pull-7ac23565437f496e8f9778d34cd1e1e9' panicked at 'Failure to bind the ZMQ Pull socket to the port: No such device', /checkout/src/libcore/result.rs:916:5
DEBUG 2018-05-18T17:30:23Z: hyper::server: threads = 32
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: clone
DEBUG 2018-05-18T17:30:23Z: zmq: socket dropped
^CDEBUG 2018-05-18T17:30:43Z: habitat_launcher::server: Shutting down...
 WARN 2018-05-18T17:30:43Z: habitat_launcher::server: Forcefully stopping Supervisor: 18340
hab-launch(SV): Hasta la vista, services.

[baumanj]

Confirmed as valid in 0.57. First we'd need to call set_ipv6(true) if the address we're binding (here for example) is a SocketAddr::V6.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[HT154]

Please don't close this. The fact that issues like this haven't been addressed is one of the primary reasons my org is moving away from all use of Habitat. The use of the stale bot just adds insult to injury.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.