[tahoe-lafs-trac-stream] [tahoe-lafs] #1310: separate "gateway state directory" from "client state directory"

[tahoe-lafs]

#1310: separate "gateway state directory" from "client state directory"
-----------------------------------+-----------------------
     Reporter:  zooko              |      Owner:  warner
         Type:  defect             |     Status:  reopened
     Priority:  major              |  Milestone:  undecided
    Component:  code-frontend-cli  |    Version:  1.8.1
   Resolution:                     |   Keywords:  usability
Launchpad Bug:                     |
-----------------------------------+-----------------------

Old description:

> updating the Description for clarity:
>
> This ticket is about the proposal to have separate directories for
> holding the state/configuration of the LAFS gateway from the
> state/configuration of the LAFS client. In the current (Tahoe-LAFS v1.10)
> code, both of those things are maintained in one shared directory, called
> the "node directory" or "base directory". The state therein is actually
> non-overlapping:
>
> * things a client (i.e. the "tahoe" command-line tool) uses out of the
> base directory:
>   - the {{{node.url}}} file to find out how to connect to the gateway
>   - the {{{private/backupdb.sqlite}}} file to find out what files have
> already been uploaded
>
> * things a gateway uses out of the base directory:
>   - everything else that is stored in there ''except'' for the
> {{{node.url}}}, and {{{private/backupdb.sqlite}}} files
>
> So the client never uses any of the files that are kept in that directory
> for the gateway's purposes, and the gateway never uses any of the files
> that are kept in that directory for the client's purposes.
>

> ---- original Description follows
>
> I use multiple grids (pub grid, volunteergrid, and a private family
> grid), and I just now had a confusing error where I ran {{{tahoe
> backup}}} and it completed quickly but produced a backup directory full
> of links to files with 0 shares each.
>
> What happened, of course, was that I had previously run {{{tahoe backup
> --node-url=http://127.0.0.1:3458/}}} to backup these files to my family
> grid, and now I was running {{{tahoe backup --node-
> url=http://127.0.0.1:3457/}}} to backup these files to the volunteergrid,
> but I was unwittingly using the same {{{backupdb.sqlite}}}.
>
> I wonder if, when the {{{--node-url}}} option is present, then the CLI
> shouldn't look into {{{~/.tahoe}}} at all. Most of the configuration and
> state in {{{~/.tahoe}}} is specific to the gateway that the {{{--node-
> url}}} points to, and the CLI will ignore it anyway and instead whatever
> configuration is in the tahoe-base-dir that is used by the gateway will
> take effect.
>
> The only exception that I can think of right away is the
> {{{private/backupdb.sqlite}}}. Is that the only thing that affects the
> CLI when {{{--node-url}}} is present? Maybe it should be kept in a
> different directory.
>
> I think I'm a bit confused about this. I'm not sure what all it means
> that there exists a {{{~/.tahoe}}} when I'm actually using a gateway
> which runs as a separate user process, is specified by the {{{--node-
> url}}} option, and it has its own {{{~/.tahoe}}} in its own user account.
> As a work-around and a way to gain clarity, I'll probably start
> specifying {{{--node-directory}}} in addition to {{{--node-url}}}, but
> this really feels wrong as it isn't a node directory at all! It is a CLI
> directory. :-)

New description:

 updating the Description for clarity:

 This ticket is about the proposal to have separate directories for holding
 the state/configuration of the LAFS gateway from the state/configuration
 of the LAFS client. In the current (Tahoe-LAFS v1.10) code, both of those
 things are maintained in one shared directory, called the "node directory"
 or "base directory". The state therein is actually non-overlapping:

 * things a client (i.e. the "tahoe" command-line tool) uses out of the
 base directory:
   - the {{{node.url}}} file to find out how to connect to the gateway
   - the {{{private/backupdb.sqlite}}} file to find out what files have
 already been uploaded
   - the {{{private/aliases}}} file holding aliases to caps

 * things a gateway uses out of the base directory:
   - everything else that is stored in there ''except'' for the
 {{{node.url}}}, {{{private/aliases}}} and {{{private/backupdb.sqlite}}}
 files

 So the client never uses any of the files that are kept in that directory
 for the gateway's purposes, and the gateway never uses any of the files
 that are kept in that directory for the client's purposes.


 ---- original Description follows

 I use multiple grids (pub grid, volunteergrid, and a private family grid),
 and I just now had a confusing error where I ran {{{tahoe backup}}} and it
 completed quickly but produced a backup directory full of links to files
 with 0 shares each.

 What happened, of course, was that I had previously run {{{tahoe backup
 --node-url=http://127.0.0.1:3458/}}} to backup these files to my family
 grid, and now I was running {{{tahoe backup --node-
 url=http://127.0.0.1:3457/}}} to backup these files to the volunteergrid,
 but I was unwittingly using the same {{{backupdb.sqlite}}}.

 I wonder if, when the {{{--node-url}}} option is present, then the CLI
 shouldn't look into {{{~/.tahoe}}} at all. Most of the configuration and
 state in {{{~/.tahoe}}} is specific to the gateway that the {{{--node-
 url}}} points to, and the CLI will ignore it anyway and instead whatever
 configuration is in the tahoe-base-dir that is used by the gateway will
 take effect.

 The only exception that I can think of right away is the
 {{{private/backupdb.sqlite}}}. Is that the only thing that affects the CLI
 when {{{--node-url}}} is present? Maybe it should be kept in a different
 directory.

 I think I'm a bit confused about this. I'm not sure what all it means that
 there exists a {{{~/.tahoe}}} when I'm actually using a gateway which runs
 as a separate user process, is specified by the {{{--node-url}}} option,
 and it has its own {{{~/.tahoe}}} in its own user account. As a work-
 around and a way to gain clarity, I'll probably start specifying
 {{{--node-directory}}} in addition to {{{--node-url}}}, but this really
 feels wrong as it isn't a node directory at all! It is a CLI directory.
 :-)

--

Comment (by amontero):

 Added {{{private/aliases}}} to client-side files in issue description.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1310#comment:13>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage