| | 1 | = [wiki:Summit 2nd Summit] Day 3 = |
| | 2 | |
| | 3 | 10-Nov-2011, Mozilla SF. |
| | 4 | |
| | 5 | No video due to technical problems. |
| | 6 | |
| | 7 | == Attendees == |
| | 8 | * Zooko |
| | 9 | * David-Sarah |
| | 10 | * Zancas |
| | 11 | * Brian |
| | 12 | * Bill Frantz |
| | 13 | * Sam Stoller |
| | 14 | |
| | 15 | == Goals == |
| | 16 | |
| | 17 | * David-Sarah to present LAE's s3-backend branch |
| | 18 | * figure out merge plan for s3-backend and accounting |
| | 19 | * figure out leasedb crawler: detailed case analysis |
| | 20 | |
| | 21 | == Topics == |
| | 22 | |
| | 23 | * (one-person) Tahoe !InstallFest! |
| | 24 | * successfully got Tahoe installed on Bill Frantz's laptop. Excitement |
| | 25 | ensued from its lack of XCode and gcc. Eggs were built and |
| | 26 | installation proceeded smoothly. |
| | 27 | * (one-person) LAE Customer Setup! |
| | 28 | * successfully (eventually) got Brian signed up as an LAE customer. |
| | 29 | Kinda neat to include a PGP fingerprint on a signup form. Succeeded |
| | 30 | in uploading a (small) test file. |
| | 31 | * quick review of LAE's s3-backend branch (davidsarah) |
| | 32 | * brian hesitant about apparent complexity, but mitigated by the |
| | 33 | pre-existing messy complexity of the non-pluggable-backend code. |
| | 34 | * all parties looking forward to ripping out lease code and replacing |
| | 35 | with whatever comes out of brian's Accounting project |
| | 36 | * s3 backend currently has memory-footprint problems with large shares |
| | 37 | * branch also includes extra cleanups: |
| | 38 | {{{twisted.python.filepath}}}-ification, whitespace cleanups, |
| | 39 | {{{Interface}}}-de-parameterization, client-side comment fixes. |
| | 40 | Hopefully these will turn into separate patches which can be landed |
| | 41 | separately. |
| | 42 | * discussion of mutable-file CAP stuff |
| | 43 | * proposal to use two-phase commit and locking to improve mutable-file |
| | 44 | data preservation |
| | 45 | * general idea would be that servers allow one client to lock the next |
| | 46 | version of a share (for some limited time), then clients obtain lock |
| | 47 | on all shares before committing to a change. If clients observe |
| | 48 | contention (i.e. they are refused a lock because some second client |
| | 49 | already grabbed it), abandon all locks and back off. |
| | 50 | * additional idea: servers retain previous version of share until a |
| | 51 | third phase lets them delete it. Clients obtain lock, upload+commit |
| | 52 | to v2, when all servers report success, clients delete v1. Some |
| | 53 | failure cases result in mix of (v1-only) and (v1+v2) servers. Repair |
| | 54 | would need to spot these and be able to roll back to v1. Servers |
| | 55 | would need to report all versions that had been committed. Readers |
| | 56 | could see v1 and v2 and deliver v1 if v2 is not recoverable. |
