[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2773: `tahoe create-node` should require `--location`, and not autodetect

[Tahoe-LAFS]

#2773: `tahoe create-node` should require `--location`, and not autodetect
--------------------------------+-----------------------
     Reporter:  warner          |      Owner:
         Type:  task            |     Status:  new
     Priority:  normal          |  Milestone:  undecided
    Component:  code-nodeadmin  |    Version:  1.11.0
   Resolution:                  |   Keywords:
Launchpad Bug:                  |
--------------------------------+-----------------------

Comment (by warner):

 Hm, I realized I'm not sure whether `--location=` is supposed to be just a
 hostname (`example.com`), or a full Foolscap connection hint
 (`tcp:example.com:12345`).

 If it's just a hostname, then it makes sense for `--port` to be optional,
 because the command can build a connection hint from the given hostname
 and a self-allocated port.

 If it's a full connection hint, then you basically ''must'' provide a
 `--port` that matches the hint: `--location=tcp:example.com:12345
 --port=12345`. If you have some funky non-1-to-1 port-mapping firewall
 going on, you might provide different port numbers (where `--location`
 points at the external one, and `--port` provides the internal one). You'd
 do the same to use an externally-configured Tor onion service,
 `--location=tor:xyz.onion:80 --port=tcp:12345`.

 I suppose we could say that if you pass `--location`, but not `--port`,
 and the location is in the form `tcp:HOSTNAME:PORT`, then we glean
 `--port` from the last component of the location, but this feels a bit
 magic to me.

 We could also say that if you provide `--location=tcp:HOSTNAME:PORT1` and
 a different `--port=PORT2`, then we could pretend that you really said
 `--location=tcp:HOSTNAME:PORT2`, but that would be even more magical, and
 would prevent setting up the portmapping example above.

 I guess I'm most inclined to be fully explicit. `--location=` would be a
 full `tcp:HOSTNAME:PORT` connection hint (or a comma-separated list of
 them). `--port=` would be a full endpoint specification (so `tcp:PORT` or
 `tcp:PORT:interface=127.0.0.1`), with maybe the "tcp:" being optional.

 Oh, what if we have a separate argument name `--hostname=`? Then we'd have
 the following possibilities:

 * `--hostname=example.com` : self-allocate a port, use
 location=`tcp:example.com:PORT`, and port=`tcp:PORT`
 * `--hostname=example.com --port=12345`: use `tcp:example.com:12345` and
 `tcp:12345`
 * `--location=tcp:example.com:12345 --port=tcp:12345`: use those as
 location and port
 * it would be an error to provide both `--hostname` and `--location`, or
 to provide `--location` without `--port`.

 And then using an automatically-configured Tor onion service would still
 be something different, like `--tor` or `--listen-tor`, which builds the
 service, then sets `--location` and `--port` internally.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773#comment:1>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage