[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2816: make sure tub.location and tub.port can be empty

[Tahoe-LAFS]

#2816: make sure tub.location and tub.port can be empty
--------------------------------+----------------------
     Reporter:  warner          |      Owner:  warner
         Type:  task            |     Status:  reopened
     Priority:  normal          |  Milestone:  1.12.0
    Component:  code-nodeadmin  |    Version:  1.11.0
   Resolution:                  |   Keywords:
Launchpad Bug:                  |
--------------------------------+----------------------
Changes (by warner):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 At today's devchat, we agreed that an empty value is confusing, especially
 because it introduces a critical difference between "key is missing" and
 "key is present but value is empty" (one turns off the listener, the other
 turns on automatic port assignment). So I've reopened this, and I'm going
 to change it to:

 {{{
 [node]
 tub.port = disabled
 tub.location = disabled
 }}}

 and we'll reject any confusing cases that aren't already in use. `tahoe
 create-node` creates commented-out lines, which means we can reject "key
 present but value empty" cases:

 {{{
 # default created by 'tahoe create-node'
 [node]
 #tub.port =
 #tub.location =
 }}}

 So we'll throw an error at startup if we see:

 {{{
 # rejected!
 [node]
 tub.port =
 tub.location =
 }}}

 I'll also add a constraint that if `tub.port = disabled`, then
 `tub.location` must be `disabled` too, so they always show up as a pair.
 (and if `tub.location = disabled`, then `tub.port` must be too). I think
 that'll catch a lot of the confusing cases. "key is missing" and "value is
 missing" will mean different things, but instead of "X vs not X", it'll be
 "X vs error", which is probably safer.

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