[Imported from Trac: page Accounting, version 1]
parent
f25059b9a5
commit
d5a99e6219
133
Accounting.md
Normal file
133
Accounting.md
Normal file
|
@ -0,0 +1,133 @@
|
||||||
|
|
||||||
|
(This was copied from a [LeastAuthority](LeastAuthority) wiki page, summarizing steps and desire to get cloud-backend things into master .. mostly related directly to the S4 service, but is fairly general)
|
||||||
|
|
||||||
|
# background
|
||||||
|
|
||||||
|
We wish to get the 2237-cloud-backend branch onto master. The
|
||||||
|
cloud-backend branch was built off of a minimal Accounting prototype
|
||||||
|
(warner/accounting-2) so that the new "lease-db" could have somewhere
|
||||||
|
to hang.
|
||||||
|
|
||||||
|
## currently
|
||||||
|
|
||||||
|
As far as leases and accounting go, 2237 / accounting-3 have the
|
||||||
|
following design:
|
||||||
|
|
||||||
|
- Accountant hold accounts. There are just 2 accounts and no way
|
||||||
|
(yet) to create or manage them:
|
||||||
|
|
||||||
|
- "starter" account
|
||||||
|
- "anonymous" account
|
||||||
|
|
||||||
|
- an Account object now implments RIStorageServer (formerly
|
||||||
|
implemented by [StorageServer](StorageServer)). So from a client perspective,
|
||||||
|
nothing changes: they contact a fURL that implements the
|
||||||
|
RIStorageServer API. During client setup, that fURL is now pointed
|
||||||
|
at the anonymous Account instance (instead of the [StorageServer](StorageServer)
|
||||||
|
instance).
|
||||||
|
|
||||||
|
- leases are stored in a local sqlite database
|
||||||
|
- new "starter" leases are created for anything which lacks a lease
|
||||||
|
- all the code that reads/writes leases to the shares themselves is gone
|
||||||
|
|
||||||
|
- the Accountant and Account objects have access to the leasedb
|
||||||
|
- the Account object manages leases
|
||||||
|
- an [AccountingCrawler](AccountingCrawler) replaces the [LeaseCheckingCrawler](LeaseCheckingCrawler). This new crawler will:
|
||||||
|
- Remove leases that are past their expiration time.
|
||||||
|
- Delete objects containing unleased shares.
|
||||||
|
- Discover shares that have been manually added to storage.
|
||||||
|
- Discover shares that are present when a storage server is upgraded from
|
||||||
|
a pre-leasedb version, and give them "starter leases".
|
||||||
|
- Recover from a situation where the leasedb is lost or detectably
|
||||||
|
corrupted. This is handled in the same way as upgrading.
|
||||||
|
- Detect shares that have unexpectedly disappeared from storage.
|
||||||
|
|
||||||
|
## problems
|
||||||
|
|
||||||
|
|
||||||
|
There are a few problems with this:
|
||||||
|
|
||||||
|
### database durability, ops burden
|
||||||
|
|
||||||
|
- ultimately, cloud-backend uses "not local disk" for storage
|
||||||
|
- ...but the leasedb is "a thing that should be backed up", but isn't
|
||||||
|
stored in the "not local disk" storage. That is, if we're using an
|
||||||
|
S3 thing, it would be best to have the lease-db in S3 (or AWS
|
||||||
|
database)
|
||||||
|
|
||||||
|
- this is "okay" for now, because the lease-db is built to recover
|
||||||
|
from "zero leases". Basically:
|
||||||
|
- if there's no lease for a share, add a "starter" one
|
||||||
|
- eventually (after the default-30-days expiry) we will either
|
||||||
|
learn which clients care about that share (because they renewed
|
||||||
|
their leases) or the starter lease expires (and we delete the
|
||||||
|
share)
|
||||||
|
- ...but this means we can't use the lease-db to definitely answer
|
||||||
|
the question "how much space is Alice using" if our lease-db is
|
||||||
|
younger than "default-expiry-time".
|
||||||
|
|
||||||
|
### non-async APIs
|
||||||
|
|
||||||
|
- the current LeaseDB API is synchronous. This is "sort of fine if
|
||||||
|
you squint" for a local sqlite database (although still not
|
||||||
|
correct, because a database read can take an arbitrary amount of
|
||||||
|
time). Ideally the LeaseDB API should be async.
|
||||||
|
- e.g. by using twisted.enterprise.adbapi (or similar "general-pupose
|
||||||
|
Twisted database API" -- is there a better one?)
|
||||||
|
|
||||||
|
|
||||||
|
### "database as cache"
|
||||||
|
|
||||||
|
- currently, the database is completely throw-away
|
||||||
|
- that may limit future designs (i.e. we can't put anything
|
||||||
|
"permanent" in the leasedb)
|
||||||
|
- is this a problem? (if so, is it a problem we *can't* easily fix
|
||||||
|
later? i.e. if and when we want to add a feature that needs durable
|
||||||
|
lease-db data?)
|
||||||
|
- I *think* we decided in last Nuts&Bolts that treating the database
|
||||||
|
as "mostly disposible" is okay
|
||||||
|
|
||||||
|
|
||||||
|
## the future
|
||||||
|
|
||||||
|
### Remote API Design
|
||||||
|
|
||||||
|
- obviously, to support "not yet upgraded" clients, the
|
||||||
|
"anonymous-storage-FURL" API can't change. That is, it must
|
||||||
|
implement RIStorageServer.
|
||||||
|
- but maybe having Account directly implement that isn't great.
|
||||||
|
- Consider this:
|
||||||
|
|
||||||
|
- we want introducers to go away
|
||||||
|
- thus, "tahoe storage servers" need to stay (as "the" smart thing)
|
||||||
|
- what if we call these "tahoe servers" instead, and they provide services
|
||||||
|
- one of those services is "storage"
|
||||||
|
- (another service might be e.g. a "membrane" that provides
|
||||||
|
temporary access to a read-cap)
|
||||||
|
- (another might be a payment API of some kind, to pay for "storage" or other services)
|
||||||
|
|
||||||
|
- ...so I think a better API might be this:
|
||||||
|
|
||||||
|
- Account just provides a "services" API
|
||||||
|
- "storage" is one of those services (the only one we provide right now)
|
||||||
|
- ...and "storage" implements RIStorageServer
|
||||||
|
|
||||||
|
- not much changes, except the shape of the code: during client
|
||||||
|
setup, we get the "anonymous-storage-FURL" from the "storage"
|
||||||
|
service of the anonymous Account (instead of it just *being* the
|
||||||
|
Account directly).
|
||||||
|
|
||||||
|
|
||||||
|
### Backing up the Databse
|
||||||
|
|
||||||
|
- one thing suggested was to just periodically (e.g. every hour) back
|
||||||
|
up the sqlite database to "whatever storage the backend is
|
||||||
|
using". That is, a "storage backend" has an API to backup (and
|
||||||
|
restore) an sqlite file.
|
||||||
|
- then can "mostly" still answer the "how much space is Alice using"
|
||||||
|
stuff (except for the possibility that shares were added by Alice
|
||||||
|
after the last database backup)
|
||||||
|
- ...but you get fast, local queries most of the time for other things
|
||||||
|
- (I still think we should make the LeaseDB API async even if we're
|
||||||
|
"always" using sqlite)
|
||||||
|
|
Loading…
Reference in a new issue