[tahoe-lafs-trac-stream] [Tahoe-LAFS] #468: design+build the Usage/Aggregator service

[Tahoe-LAFS]

#468: design+build the Usage/Aggregator service
------------------------------+----------------------------
     Reporter:  warner        |      Owner:
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  undecided
    Component:  code-storage  |    Version:  1.1.0
   Resolution:                |   Keywords:  accounting wui
Launchpad Bug:                |
------------------------------+----------------------------

Old description:

> As part of the Accounting project, we'll be building a "Usage" service,
> which
> will help keep track of how much space is used per account. Here are my
> notes
> from last week:
>
>    creating a Tahoe node with a storage server component creates a Usage
>    component by default. You can also create a node with a Usage
> component
>    but nothing else: we call this an Aggregator. The Usage component
>    subscribes to any co-resident Storage component, and can also
> subscribe to
>    other Storage services in other nodes. The Usage component provides a
> web
>    interface (localhost:8124/usage) that provides different views of a
> table
>    that shows usage (in bytes) per (server,account) pair. It also
> provides a
>    sum across all servers. If the Usage component is only subscribing to
> a
>    single storage server, the table will only have one column, and the
> sum
>    will be the same as the table. It can also return information about
> just a
>    subset of accounts (to return data in batches, since there might be a
>    million accounts). The Usage component will consult an optional
> "petname
>    database", which maps account to name. It will have an HTML table
> display,
>    and a machine-readable JSON interface.
>
>    Allmydata will run an Aggregator that subscribes to all prodnet
> storage
>    servers. Peter's SQL database stuff will then make JSON queries of the
>    aggregator to keep track of how much each customer is using.
>
>    In a friendnet deployment, the storage server admin can use their
> local
>    Usage service to find out how much each of their friends is using on
> that
>    one server. If the friendnet members exchange Usage-subscription-FURLs
>    symmetrically, they will be able to see how much each member is using
>    across the whole friendnet.
>
>    When we implement Invitations, the code that negotiates the invitation
>    will populate the petname database.

New description:

 As part of the Accounting project, we'll be building a "Usage" service,
 which
 will help keep track of how much space is used per account. Here are my
 notes
 from last week:

    creating a Tahoe node with a storage server component creates a Usage
    component by default. You can also create a node with a Usage component
    but nothing else: we call this an Aggregator. The Usage component
    subscribes to any co-resident Storage component, and can also subscribe
 to
    other Storage services in other nodes. The Usage component provides a
 web
    interface (localhost:8124/usage) that provides different views of a
 table
    that shows usage (in bytes) per (server,account) pair. It also provides
 a
    sum across all servers. If the Usage component is only subscribing to a
    single storage server, the table will only have one column, and the sum
    will be the same as the table. It can also return information about
 just a
    subset of accounts (to return data in batches, since there might be a
    million accounts). The Usage component will consult an optional
 "petname
    database", which maps account to name. It will have an HTML table
 display,
    and a machine-readable JSON interface.

    Allmydata will run an Aggregator that subscribes to all prodnet storage
    servers. Peter's SQL database stuff will then make JSON queries of the
    aggregator to keep track of how much each customer is using.

    In a friendnet deployment, the storage server admin can use their local
    Usage service to find out how much each of their friends is using on
 that
    one server. If the friendnet members exchange Usage-subscription-FURLs
    symmetrically, they will be able to see how much each member is using
    across the whole friendnet.

    When we implement Invitations, the code that negotiates the invitation
    will populate the petname database.

--

Comment (by exarkun):

 What if we build an access control system that doesn't have accounts at
 all?

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