[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3931: Factor functionality related to running a storage service into a separate class from `_Client`

[Tahoe-LAFS]

#3931: Factor functionality related to running a storage service into a separate
class from `_Client`
-----------------------------+-----------------------
     Reporter:  exarkun      |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  undecided
    Component:  unknown      |    Version:  n/a
   Resolution:               |   Keywords:
Launchpad Bug:               |
-----------------------------+-----------------------
Description changed by exarkun:

Old description:

> `allmydata.client._Client` combines many concerns.  At least:
>
> * metrics collection
> * secrets management
> * webui frontend initialization
> * storage services
> * storage client services
> * blacklist management
> * file "node" creation
> * helper management
> * sftp frontend initialization
>
> This is just the list that's obvious from reading the names of its
> methods.
>
> Most of the logic for most of these things is already implement by
> something other than `_Client`.  However, `_Client` ties them all
> together in an obligatory "super object".  Much of the functionality can
> be disabled - but only through the very awkward interface of the bytes in
> a `tahoe.cfg` file.
>
> Instead of making `tahoe.cfg` the only control structure for what
> `_Client` does and does not do, we should arrange to have a convenient
> Python API that allows for composition of functionality.  For starters,
> this could exactly mirror the capabilities of `tahoe.cfg` (and should, in
> fact, be the API that the contents of `tahoe.cfg` drives).  The point
> would be to make it easier to make these choices from Python code -
> without a trip through an ini-style configuration file.
>
> We could start by pulling any one of these pieces out but the storage
> service piece is particularly interesting as it is undergoing a non-
> trivial amount of maintenance these days so it makes sense as a starting
> place for me.
>
> This refactoring would make it easier to test existing and new features
> of the storage system.  It should also make the implementation easier to
> maintain and experiment with in the future.
>
> Presently a `_Client` is almost always created by
> `create_client_from_config` which mediates between `tahoe.cfg` and the
> current `_Client` Python API.  A reasonable goal for this particular
> ticket could be a refactoring with allows `create_client_from_config` to
> perform a single, simple composition between `_Client` and an API
> responsible for the storage service (for example, create the storage
> service object and pass it to `_Client`, or vice-versa, or pass both to a
> third thing that does the necessary Twisted `Service` setup, etc).
>
> This would replace the current implementation which does some some
> storage service initialization in `create_client_from_config` _and_
> creates a `_Client` _and_ passes some of the storage service values to a
> method on the partially-initialized `_Client` where there is further
> `tahoe.cfg` inspection and the rest of the storage service setup process.

New description:

 `allmydata.client._Client` combines many concerns.  At least:

 * metrics collection
 * secrets management
 * webui frontend initialization
 * storage services
 * storage client services
 * blacklist management
 * file "node" creation
 * helper management
 * sftp frontend initialization

 This is just the list that's obvious from reading the names of its
 methods.

 Most of the logic for most of these things is already implemented by
 something other than `_Client`.  However, `_Client` ties them all together
 in an obligatory "super object".  Much of the functionality can be
 disabled - but only through the very awkward interface of the bytes in a
 `tahoe.cfg` file.

 Instead of making `tahoe.cfg` the only control structure for what
 `_Client` does and does not do, we should arrange to have a convenient
 Python API that allows for composition of functionality.  For starters,
 this could exactly mirror the capabilities of `tahoe.cfg` (and should, in
 fact, be the API that the contents of `tahoe.cfg` drives).  The point
 would be to make it easier to make these choices from Python code -
 without a trip through an ini-style configuration file.

 We could start by pulling any one of these pieces out but the storage
 service piece is particularly interesting as it is undergoing a non-
 trivial amount of maintenance these days so it makes sense as a starting
 place for me.

 This refactoring would make it easier to test existing and new features of
 the storage system.  It should also make the implementation easier to
 maintain and experiment with in the future.

 Presently a `_Client` is almost always created by
 `create_client_from_config` which mediates between `tahoe.cfg` and the
 current `_Client` Python API.  A reasonable goal for this particular
 ticket could be a refactoring with allows `create_client_from_config` to
 perform a single, simple composition between `_Client` and an API
 responsible for the storage service (for example, create the storage
 service object and pass it to `_Client`, or vice-versa, or pass both to a
 third thing that does the necessary Twisted `Service` setup, etc).

 This would replace the current implementation which does some some storage
 service initialization in `create_client_from_config` _and_ creates a
 `_Client` _and_ passes some of the storage service values to a method on
 the partially-initialized `_Client` where there is further `tahoe.cfg`
 inspection and the rest of the storage service setup process.

--

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