[tahoe-lafs-trac-stream] [tahoe-lafs] #666: Accounting: limit storage space used by different parties

[tahoe-lafs]

#666: Accounting: limit storage space used by different parties
------------------------------+------------------------
     Reporter:  warner        |      Owner:  davidsarah
         Type:  task          |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.3.0
   Resolution:                |   Keywords:  accounting
Launchpad Bug:                |
------------------------------+------------------------

Comment (by nejucomo):

 **Understanding the Scope of 666-accounting:**

 I want to understand which parts of https://tahoe-lafs.org/trac/tahoe-
 lafs/browser/docs/proposed/accounting-overview.txt are in scope for branch
 https://github.com/davidsarah/tahoe-lafs/tree/666-accounting .

 Then, after I understand that, I'd like to create smaller more bite-sized
 tickets to serve as a roadmap and as an indicator of progress.

 I want to know which of the following coarse features are present or not
 in that branch, as well as if these feature distinctions are accurate or
 useful "bite sized pieces" of the {{{accounting-overview.txt}}} design:

 * Storage Server:
   1. Authority creation implementation on the server without a UI.
     * This would provide a concrete specification of the certificate
 formats.
     * Possibly with special-case uses like "create a general-public
 account for backwards compatibility / opt-in behavior."
   1. Upload/write restriction based on authority in the storage server.
 (Selective request denial.)
   1. Authority creation UI: commandline
   1. Authority creation UI: webapi (Is this a goal? I did not see it in
 the overview.)
   1. Backwards compatibility in the storage server.
     * I consider this a separable task, because a branch could break
 compatibility, then fix it later, as distinct phases.
     * I recall warner describing something that assigns legacy client
 requests to a "general public" account.  That's one example implementation
 of this bullet.
 * Client-gateway:
   1. The ability to provide account authority in foolscap requests, with
 no exposed api.
     * Perhaps this includes a hardcoded "general public" request.
   1. Backwards compatibility with storage servers that don't speak
 accounting.
   1. The ability to provide account authority in requests with a webapi.
     * Updated {{{webapi.rst}}} describing the interface.
   1. Commandline tools for passing explicit account authorities.
   1. Commandline tools for "account petnames" and "ambient account
 authority".

 I'm kind of guessing here at the proper way to split up the implementation
 and specification work.

 **Desire for a roadmap:**

 I'd like to create tickets at a level of granularity so that we have a
 tangible roadmap.

 If no one comments on these bullets, then when I next invest time in
 accounting, I'll examine the branches and try to determine which bullets
 are in scope for the {{{666-accounting}}} branch, and which are out of
 scope.

 For any "bite sized chunks" that I notice, I will create distinct tickets
 and link them into this parent ticket.

 **Landing Changes:**

 I believe it may be possible to land onto trunk/default at multiple
 intermediate stages.  I recognize this might imply more overall work.  I
 prefer it because it signals to the general community where the progress
 is.

 If we *don't* land intermediate stages which are tracked in separate
 tickets, perhaps we can create a "branch666" keyword?  Is that sensible?

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