[Imported from Trac: page Summit2Day3, version 1]
parent
4733eef952
commit
d6f1503ec5
56
Summit2Day3.md
Normal file
56
Summit2Day3.md
Normal file
|
@ -0,0 +1,56 @@
|
||||||
|
# [2nd Summit](Summit) Day 3
|
||||||
|
|
||||||
|
10-Nov-2011, Mozilla SF.
|
||||||
|
|
||||||
|
No video due to technical problems.
|
||||||
|
|
||||||
|
## Attendees
|
||||||
|
* Zooko
|
||||||
|
* David-Sarah
|
||||||
|
* Zancas
|
||||||
|
* Brian
|
||||||
|
* Bill Frantz
|
||||||
|
* Sam Stoller
|
||||||
|
|
||||||
|
## Goals
|
||||||
|
|
||||||
|
* David-Sarah to present LAE's s3-backend branch
|
||||||
|
* figure out merge plan for s3-backend and accounting
|
||||||
|
* figure out leasedb crawler: detailed case analysis
|
||||||
|
|
||||||
|
## Topics
|
||||||
|
|
||||||
|
* (one-person) Tahoe InstallFest!
|
||||||
|
* successfully got Tahoe installed on Bill Frantz's laptop. Excitement
|
||||||
|
ensued from its lack of XCode and gcc. Eggs were built and
|
||||||
|
installation proceeded smoothly.
|
||||||
|
* (one-person) LAE Customer Setup!
|
||||||
|
* successfully (eventually) got Brian signed up as an LAE customer.
|
||||||
|
Kinda neat to include a PGP fingerprint on a signup form. Succeeded
|
||||||
|
in uploading a (small) test file.
|
||||||
|
* quick review of LAE's s3-backend branch (davidsarah)
|
||||||
|
* brian hesitant about apparent complexity, but mitigated by the
|
||||||
|
pre-existing messy complexity of the non-pluggable-backend code.
|
||||||
|
* all parties looking forward to ripping out lease code and replacing
|
||||||
|
with whatever comes out of brian's Accounting project
|
||||||
|
* s3 backend currently has memory-footprint problems with large shares
|
||||||
|
* branch also includes extra cleanups:
|
||||||
|
`twisted.python.filepath`-ification, whitespace cleanups,
|
||||||
|
`Interface`-de-parameterization, client-side comment fixes.
|
||||||
|
Hopefully these will turn into separate patches which can be landed
|
||||||
|
separately.
|
||||||
|
* discussion of mutable-file CAP stuff
|
||||||
|
* proposal to use two-phase commit and locking to improve mutable-file
|
||||||
|
data preservation
|
||||||
|
* general idea would be that servers allow one client to lock the next
|
||||||
|
version of a share (for some limited time), then clients obtain lock
|
||||||
|
on all shares before committing to a change. If clients observe
|
||||||
|
contention (i.e. they are refused a lock because some second client
|
||||||
|
already grabbed it), abandon all locks and back off.
|
||||||
|
* additional idea: servers retain previous version of share until a
|
||||||
|
third phase lets them delete it. Clients obtain lock, upload+commit
|
||||||
|
to v2, when all servers report success, clients delete v1. Some
|
||||||
|
failure cases result in mix of (v1-only) and (v1+v2) servers. Repair
|
||||||
|
would need to spot these and be able to roll back to v1. Servers
|
||||||
|
would need to report all versions that had been committed. Readers
|
||||||
|
could see v1 and v2 and deliver v1 if v2 is not recoverable.
|
Loading…
Reference in a new issue