#999 closed enhancement (fixed)

support multiple storage backends, including amazon s3

Reported by: zooko Owned by: davidsarah
Priority: major Milestone: eventually
Component: code-storage Version: n/a
Keywords: s3-backend storage Cc: wilcoxjg@…, mk.fraggod@…, amontero@…
Launchpad Bug:

Description (last modified by amontero)

The focus of this ticket is (now) adapting the existing codebase to use multiple backends, rather than supporting any particular backend. We already have one backend -- the filesystem backend -- which I think should be a plugin in the same sense that the others will be plugins (i.e.: other code in tahoe-lafs can interact with a filesystem plugin without caring very much about how or where it is storing its files -- otherwise it doesn't seem very extensible). If you accept this, then we'd need to figure out what a backend plugin should look like. There is backend-independent logic in the current server implementation that we wouldn't want to duplicate in every other backend implementation. To address this, we could start by refactoring the existing code that reads or writes shares on disk, to use a local backend implementation supporting an IStorageProvider interface (probably a fairly simplistic filesystem-ish API). (This involves changing the code in src/allmydata/storage/server.py that reads from local disk in its _iter_share_files() method, and also changing storage/shares.py, storage/immutable.py, and storage/mutable.py that write shares to local disk.) At this point all the existing tests should still pass, since we haven't actually changed the behaviour. Then we have to add the ability to configure new storage providers. This involves figuring out how to map user configuration choices to what actually happens when a node is started, and how the credentials needed to log into a particular storage backend should be specified. The skeletal RIStorageServer would instantiate its IStorageProvider based on what the user configured, and use it to write/read data, get statistics, and so on. Naturally, all of this would require a decent amount of documentation and testing, too. Once we have all of this worked out, the rest of this project (probably to be handled in other tickets) would be identifying what other backends we'd want in tahoe-lafs, then documenting, implementing, and testing them. We already have Amazon S3 and Rackspace as targets -- users of tahoe-lafs will probably have their own suggestions, and more backends will come up with more research.

Attachments (68)

storagemocktest01.darcs.patch (5.9 KB) - added by arch_o_median at 2011-03-22T05:34:38Z.
sservertests.darcs.patch (8.8 KB) - added by arch_o_median at 2011-03-25T20:41:34Z.
for-arctic.darcs.patch (28.3 KB) - added by zooko at 2011-04-06T20:41:41Z.
for-arctic-2.darcs.patch (615.5 KB) - added by zooko at 2011-04-06T21:00:11Z.
workingonbackend01.darcs.patch (45.5 KB) - added by arch_o_median at 2011-06-24T20:32:00Z.
Implements tests of read and write for the nullbackend
snapshotofbackendimplementation.darcs.patch (94.2 KB) - added by arch_o_median at 2011-06-26T05:35:28Z.
just so I don't lose it all…
checkpoint3.darcs.patch (97.0 KB) - added by arch_o_median at 2011-06-26T17:11:13Z.
another checkpoint
checkpoint4.darcs.patch (109.3 KB) - added by arch_o_median at 2011-06-28T20:24:26Z.
checkpoint5.darcs.patch (121.7 KB) - added by arch_o_median at 2011-07-05T04:29:25Z.
more precise tests in TestServerFSBackend
checkpoint6.darcs.patch (127.2 KB) - added by arch_o_median at 2011-07-06T19:08:50Z.
backing myself up, some comments cleaned in interfaces, new tests in test_backends
checkpoint7.darcs.patch (127.6 KB) - added by arch_o_median at 2011-07-06T20:07:36Z.
tiny change, now tests that allocated returns correct value
checkpoint8.darcs.patch (128.9 KB) - added by arch_o_median at 2011-07-06T22:31:09Z.
The null backend test is useful for testing what happens when there's no effective limit on the backend
checkpoint9.darcs.patch (137.5 KB) - added by arch_o_median at 2011-07-07T04:29:24Z.
checkpoint 9
checkpoint10.darcs.patch (141.6 KB) - added by arch_o_median at 2011-07-07T17:45:22Z.
Completed coverage of remote_allocate_buckets
checkpoint11.darcs.patch (149.4 KB) - added by arch_o_median at 2011-07-08T21:39:13Z.
(JACP) Just Another CheckPoint?
consistentifysi.darcs.patch (158.0 KB) - added by arch_o_median at 2011-07-10T19:55:45Z.
all storage_index (word tokens) to storageindex in storage/server.py
checkpoint12.darcs.patch (166.8 KB) - added by arch_o_median at 2011-07-11T19:08:47Z.
no longer trying to mock FS in TestServerFSBackend
jacp13.darcs.patch (188.1 KB) - added by arch_o_median at 2011-07-12T02:52:35Z.
jacp14.darcs.patch (200.7 KB) - added by arch_o_median at 2011-07-12T06:11:10Z.
jacp15.darcs.patch (205.9 KB) - added by arch_o_median at 2011-07-13T06:06:01Z.
work-in-progress-on-tests-from-pair-programming-with-Zancas.darcs.patch (222.1 KB) - added by zooko at 2011-07-14T00:31:09Z.
work-in-progress-2011-07-14_21_23.darcs.patch (229.5 KB) - added by zooko at 2011-07-14T21:24:15Z.
work-in-progress-2011-07-15_19_15.darcs.patch (249.5 KB) - added by zooko at 2011-07-15T19:16:16Z.
work-in-progress-2011-07-20_06_05Z.darcs.patch (276.7 KB) - added by zooko at 2011-07-20T06:10:25Z.
jacp16Zancas20110722.darcs.patch (294.8 KB) - added by arch_o_median at 2011-07-22T07:03:25Z.
jacp17Zancas20110723.darcs.patch (302.6 KB) - added by arch_o_median at 2011-07-22T20:32:40Z.
jacp18Zancas20110723.darcs.patch (313.6 KB) - added by arch_o_median at 2011-07-23T03:19:05Z.
jacp19Zancas20110727.darcs.patch (339.1 KB) - added by Zancas at 2011-07-27T08:05:16Z.
jacp20Zancas20110728.darcs.patch (350.1 KB) - added by Zancas at 2011-07-28T07:23:47Z.
FinishFPWRTest_Zancas20110728.darcs.patch (366.8 KB) - added by Zancas at 2011-07-29T04:39:33Z.
Patch passes allmydata.test.test_backends.TestServerAndFSBackend.test_write_and_read_share
readoldshpasses_Zancas20110729.darcs.patch (371.8 KB) - added by Zancas at 2011-07-29T23:54:48Z.
TestServerAndFSBackend.test_read_old_share passes
TestServerandFSBackPasses_Zancas20110729.darcs.patch (383.5 KB) - added by Zancas at 2011-07-30T00:59:39Z.
TestServerAndFSBackend passes all (3) tests
test_backendpasses_Zancas20110729.darcs.patch (390.5 KB) - added by Zancas at 2011-07-30T03:41:42Z.
5 test_backend tests pass
JACP20_Zancas20110801.darcs.patch (405.1 KB) - added by Zancas at 2011-08-01T09:47:05Z.
uggg... bugs…
jacp22_test_backendpasses_Zancas20110802.darcs.patch (415.3 KB) - added by Zancas at 2011-08-01T20:05:17Z.
the 5 tests pass... so what?
backends-configuration-docs.darcs.patch (168.6 KB) - added by zooko at 2011-09-01T03:33:27Z.
pluggable-backends-davidsarah.darcs.patch (208.4 KB) - added by davidsarah at 2011-09-15T02:50:08Z.
This is just a "flat" recording of my refactoring of pluggable backends. I'll do a better recording tomorrow, and explain the refactoring.
pluggable-backends-davidsarah-v2.darcs.patch (298.7 KB) - added by davidsarah at 2011-09-17T02:13:03Z.
This is still just a flat recording (a lot more changes to tests were needed than I anticipated).
pluggable-backends-davidsarah-v3.darcs.patch (338.4 KB) - added by davidsarah at 2011-09-19T20:33:29Z.
Bleeding edge pluggable backends code from David-Sarah. refs #999
pluggable-backends-davidsarah-v4.darcs.patch (288.5 KB) - added by davidsarah at 2011-09-19T23:38:51Z.
Rerecording of pluggable-backends-davidsarah-v3.darcs.patch that should fix the darcs performance problem when applied to trunk.
pluggable-backends-davidsarah-v5.darcs.patch (308.1 KB) - added by davidsarah at 2011-09-20T03:42:59Z.
Work-in-progress, includes fix to bug involving BucketWriter?. refs #999
backends-configuration-docs-v2.darcs.patch (23.8 KB) - added by davidsarah at 2011-09-20T17:26:01Z.
docs: document the configuration options for the new backends scheme. This takes into account ticket:999#comment:26 and is rerecorded to avoid darcs context problems.
pluggable-backends-davidsarah-v6.darcs.patch (322.1 KB) - added by davidsarah at 2011-09-21T03:21:58Z.
v6. Tests are looking in much better shape now -- still some problems with path vs FilePath? and other stale assumptions in the test framework, but the disk backend basically works now.
trace-exceptions-option.darcs.patch (19.3 KB) - added by davidsarah at 2011-09-21T15:54:50Z.
Add --trace-exceptions option to trace raised exceptions on stderr. refs #999
pluggable-backends-davidsarah-v7.darcs.patch (359.6 KB) - added by davidsarah at 2011-09-21T18:54:37Z.
Latest snapshot, more tests passing.
snapshot-backend-config-parse.patch (6.0 KB) - added by zooko at 2011-09-21T21:12:15Z.
snapshot of work in progress
pluggable-backends-davidsarah-v8.darcs.patch (375.1 KB) - added by davidsarah at 2011-09-21T22:29:14Z.
v8 snapshot. More tests pass.
pluggable-backends-davidsarah-v9.darcs.patch (410.9 KB) - added by davidsarah at 2011-09-22T05:11:43Z.
Still more test fixes.
pluggable-backends-davidsarah-v10.darcs.patch (425.7 KB) - added by davidsarah at 2011-09-22T18:38:53Z.
Fix most of the crawler tests. Reinstate the cancel_lease methods of ImmutableDiskShare? and MutableDiskShare?, since they are needed for lease expiry. refs #999
pluggable-backends-davidsarah-v11.darcs.patch (487.1 KB) - added by davidsarah at 2011-09-23T04:20:00Z.
Includes a fix for iterating over a dict while removing entries from it in mutable/publish.py, some cosmetic changes, and a start on the S3 backend.
pluggable-backends-davidsarah-v12.darcs.patch (516.6 KB) - added by davidsarah at 2011-09-23T20:59:31Z.
Updates to null and S3 backends.
passtest_status_bad_disk_stats.darcs.patch (500.1 KB) - added by zancas at 2011-09-27T06:37:30Z.
contains changes in v12
pluggable-backends-davidsarah-v13.darcs.patch (542.6 KB) - added by davidsarah at 2011-09-27T07:47:54Z.
Includes fixes to test_status_bad_disk_stats and test_no_st_blocks in test_storage.py, and more work on the S3 backend.
pluggable-backends-davidsarah-v14.darcs.patch (588.2 KB) - added by davidsarah at 2011-09-27T07:48:49Z.
Work in progress for asyncifying the backend interface (necessary to call txaws methods that return Deferreds). This is incomplete so lots of tests fail. refs #999
pluggable-backends-davidsarah-v13a.darcs.patch (532.1 KB) - added by davidsarah at 2011-09-28T01:45:53Z.
This does not include the asyncification changes from v14, but does include a couple of fixes for failures in test_system.
pluggable-backends-davidsarah-v15.darcs.patch (687.3 KB) - added by davidsarah at 2011-09-28T05:34:24Z.
bleeding edge of asyncification work
pluggable-backends-davidsarah-v16.darcs.patch (821.4 KB) - added by davidsarah at 2011-09-29T04:19:16Z.
Latest asyncified patch. About 90% of tests pass.
s3-v13a-to-v16.diff (26.1 KB) - added by davidsarah at 2011-09-29T04:26:51Z.
Differences, just in the S3 backend, between v13a and v16.
split_s3share_classes_and_prune_unused_methods.diff (10.5 KB) - added by zooko at 2011-09-29T05:25:30Z.
split_s3share_classes_and_prune_unused_methods.dpatch (20.2 KB) - added by zooko at 2011-09-29T05:53:00Z.
configure-backends-incomplete.dpatch (26.0 KB) - added by zooko at 2011-09-29T06:14:14Z.
pluggable-backends-davidsarah-v17.darcs.patch (841.1 KB) - added by davidsarah at 2011-09-29T08:24:10Z.
Completes the splitting of IStoredShare into IShareForReading and IShareForWriting. Does not include configuration changes.
test_backends.py (7.6 KB) - added by davidsarah at 2011-09-29T17:14:08Z.
Snapshot of test_backends.py in David-Sarah's tree
pluggable-backends-davidsarah-v18.darcs.patch (859.3 KB) - added by davidsarah at 2011-09-29T18:33:41Z.
Includes backend configuration (rerecorded from zooko's patch), and other minor fixes.
asyncify-tests.dpatch (13.5 KB) - added by zooko at 2011-09-29T20:29:16Z.
pluggable-backends-davidsarah-v19.darcs.patch (898.0 KB) - added by davidsarah at 2011-09-29T21:27:35Z.
Include missing files for real and mock S3 backends. Also some fixes to tests, scripts/debug.py, and config parsing.
debug-mutable-hash-validation-failure.dpatch (34.6 KB) - added by zooko at 2011-09-30T06:05:43Z.
pluggable-backends-davidsarah-v20.darcs.patch (1.1 MB) - added by davidsarah at 2011-10-07T08:25:56Z.
Fix various bugs and tests. v20

Change History (220)

comment:2 Changed at 2010-03-24T04:52:20Z by kevan

(this is an email I sent to zooko a while ago with my thoughts on how this should be implemented:)

First, I'll summarize, to make sure that I understand what you had in mind. Please correct me if you disagree with any of this.

The "redundant array of inexpensive clouds" idea means extending the current storage server in tahoe-lafs to support storage backends that aren't what we have now (writing shares to the local filesystem). Well actually, the redundant array of inexpensive clouds idea means doing that, then implementing plugins for popular existing cloud storage services -- Amazon S3 and Rackspace are two that you've mentioned, but there are probably others (if we end up going through with this, I'll probably email tahoe-dev so I can get an idea of what else is out there/what else people want to see supported, in addition to my own research).

The benefit (or at least the benefit that seems clear to me from your explanation -- perhaps there are others that are more obvious if you run a big tahoe-lafs installation like allmydata.com, or if you're more familiar with tahoe-lafs than I am) is decoupling the ability of a tahoe-lafs node to store files from its physical filesystem. So if, say, allmydata.com were to start running tahoe-lafs nodes using S3 as a backend, and their grid was filled, they could create more space on the grid by buying more S3 buckets, rather than upgrading physical servers or adding new servers (I've never used S3, but I would bet that it is easier to buy more S3 buckets than to upgrade servers). Or, if you wanted to create a grid without purchasing a bunch of servers, you could run a bunch of nodes on one machine (I was thinking vmware images, but then I started wondering whether it was even necessary to have that level of separation between tahoe-lafs nodes -- is it? but that's not really on topic), each mapping to a different S3 bucket or buckets.

Am I missing anything (aside from more examples)?

It seems like -- at least for S3 -- you could already sort of do this. There are projects like s3fs, which provide a FUSE interface to an S3 bucket (though the last file for it is more than a year old. it seems like there should be other projects like that, though) (edit: this is actually wrong -- I just hadn't found the Google code project, which is at http://code.google.com/p/s3fs/). Using that, you could mount your S3 bucket somewhere in the filesystem of your server, then kajigger the basedir of the tahoe-lafs node so that it rests in that area of the filesystem, or otherwise configure the tahoe-lafs node to save files there. This requires more work than what we'd eventually want with "redundant array of inexpensive clouds", of course, and (depending on how well FUSE or other S3 interfaces play) may only work on tahoe-lafs nodes running one unix or other, but if an operator got it working, it seems like they'd have most of the benefit outlined above without any further work on my/our part.

(not that I mind working on this, of course, but I figured it would be worthwhile to mention that)

In any case, I think implementing this would come down to two basic parts.

The first part would be adapting the existing codebase to use multiple backends.

We already have one backend -- the filesystem backend -- which I think should be a plugin in the same sense that the others will be plugins (i.e.: other code in tahoe-lafs can interact with a filesystem plugin without caring very much about how or where it is storing its files -- otherwise it doesn't seem very extensible). If you accept this, then we'd need to figure out what a backend plugin should look like. Maybe we can make each plugin implement RIStorageServer, and leave it at that. Then we might not need to do very much work on the existing server to make it work with the rest of the (new) system. However, it's possible that there is backend-independent logic in the current server implementation that we wouldn't want to duplicate in every other backend implementation. To address this, we could instead make a sort of backend-agnostic storage server that implements RIStorageServer, then make another interface for backends to implement, say IStorageProvider. The skeletal RIStorageServer would instantiate its IStorageProvider based on what the user configured, and use it to write/read data, get statistics, and so on. Then IStorageProvider would be a fairly simplistic filesystem-ish API.

The other part of preparation would be figuring out how to map user configuration choices to what actually happens when a node is started. Also, we'd want to figure out how (if?) we need to do anything special with the credentials that users might need to log in to their storage backend. I'll have a better idea of how I'd implement this once I look at the way it works for other things that users configure.

Naturally, all of this would require a decent amount of documentation and testing, too.

(I'm open to other ideas, of course -- these are just what came to my mind)

Once we have all of this worked out, the rest of this project would be identifying what other backends we'd want in tahoe-lafs, then documenting, implementing, and testing those. We already have Amazon S3 and Rackspace as targets -- users of tahoe-lafs will probably have their own suggestions, and more backends will come up with more research.

comment:3 Changed at 2010-03-31T16:48:51Z by davidsarah

  • Description modified (diff)
  • Keywords backend s3 added
  • Summary changed from amazon s3 backend to support multiple storage backends, including amazon s3

Generalizing this to include support for multiple backends (since I don't think we want to do it in a way that would only support S3 and local disk).

comment:4 Changed at 2010-03-31T16:50:14Z by davidsarah

  • Description modified (diff)

fix typo

comment:5 Changed at 2010-03-31T17:17:57Z by davidsarah

  • Description modified (diff)

Update description to reflect kevan's suggested approach.

comment:6 Changed at 2011-02-23T18:31:25Z by zooko

  • Owner set to zooko
  • Status changed from new to assigned

Changed at 2011-03-22T05:34:38Z by arch_o_median

Changed at 2011-03-25T20:41:34Z by arch_o_median

comment:7 Changed at 2011-04-06T20:41:29Z by zooko

Here is an incomplete patch for others (arc) to look at or improve.

Changed at 2011-04-06T20:41:41Z by zooko

Changed at 2011-04-06T21:00:11Z by zooko

comment:8 Changed at 2011-06-22T00:06:25Z by arch_o_median

  • Owner changed from zooko to arch_o_median
  • Status changed from assigned to new

Changed at 2011-06-24T20:32:00Z by arch_o_median

Implements tests of read and write for the nullbackend

Changed at 2011-06-26T05:35:28Z by arch_o_median

just so I don't lose it all...

Changed at 2011-06-26T17:11:13Z by arch_o_median

another checkpoint

Changed at 2011-06-28T20:24:26Z by arch_o_median

Changed at 2011-07-05T04:29:25Z by arch_o_median

more precise tests in TestServerFSBackend

Changed at 2011-07-06T19:08:50Z by arch_o_median

backing myself up, some comments cleaned in interfaces, new tests in test_backends

Changed at 2011-07-06T20:07:36Z by arch_o_median

tiny change, now tests that allocated returns correct value

Changed at 2011-07-06T22:31:09Z by arch_o_median

The null backend test is useful for testing what happens when there's no effective limit on the backend

Changed at 2011-07-07T04:29:24Z by arch_o_median

checkpoint 9

Changed at 2011-07-07T17:45:22Z by arch_o_median

Completed coverage of remote_allocate_buckets

Changed at 2011-07-08T21:39:13Z by arch_o_median

(JACP) Just Another CheckPoint?

Changed at 2011-07-10T19:55:45Z by arch_o_median

all storage_index (word tokens) to storageindex in storage/server.py

Changed at 2011-07-11T19:08:47Z by arch_o_median

no longer trying to mock FS in TestServerFSBackend

Changed at 2011-07-12T02:52:35Z by arch_o_median

Changed at 2011-07-12T06:11:10Z by arch_o_median

Changed at 2011-07-13T06:06:01Z by arch_o_median

comment:9 Changed at 2011-07-13T06:07:08Z by arch_o_median

OK jacp15 contains a test that (almost) completely covers remote_allocate_buckets with the new backend. We should review this patches contents before writing more tests.

comment:10 Changed at 2011-07-13T15:45:17Z by davidsarah

  • Keywords review-needed added
  • Milestone changed from undecided to soon
  • Owner changed from arch_o_median to davidsarah
  • Status changed from new to assigned

I'll review this.

comment:11 Changed at 2011-07-13T18:19:39Z by arch_o_median

  • Cc wilcoxjg@… added
  • Keywords review-needed removed
  • Owner changed from davidsarah to arch_o_median
  • Status changed from assigned to new

comment:12 follow-up: Changed at 2011-07-20T16:55:00Z by davidsarah

Before going much further in relying on twisted.python.filepath.FilePath, can we think about the Unicode issue raised in ticket:1437#comment:3? Currently, storage directories with Unicode paths are intended to be supported on Windows.

comment:13 in reply to: ↑ 12 ; follow-up: Changed at 2011-07-20T20:17:23Z by arch_o_median

Replying to davidsarah:

Before going much further in relying on twisted.python.filepath.FilePath, can we think about the Unicode issue raised in ticket:1437#comment:3? Currently, storage directories with Unicode paths are intended to be supported on Windows.

OK... I guess that I should look into the twisted project's testing framework to determine what they know about this issue...

I'm currently snooping for leads here: http://twistedmatrix.com/trac/ticket/4736

Last edited at 2011-07-20T20:18:01Z by arch_o_median (previous) (diff)

comment:14 in reply to: ↑ 13 ; follow-up: Changed at 2011-07-20T20:23:04Z by arch_o_median

Replying to arch_o_median:

Replying to davidsarah:

Before going much further in relying on twisted.python.filepath.FilePath, can we think about the Unicode issue raised in ticket:1437#comment:3? Currently, storage directories with Unicode paths are intended to be supported on Windows.

OK... I guess that I should look into the twisted project's testing framework to determine what they know about this issue...

I'm currently snooping for leads here: http://twistedmatrix.com/trac/ticket/4736

So it seems like there may be (but probably there is not) an issue regarding Windows path representations to users versus to "OS" API's snooping here:

http://twistedmatrix.com/trac/ticket/2366

comment:15 in reply to: ↑ 14 Changed at 2011-07-20T20:27:29Z by arch_o_median

Replying to arch_o_median:

Replying to arch_o_median:

Replying to davidsarah:

Before going much further in relying on twisted.python.filepath.FilePath, can we think about the Unicode issue raised in ticket:1437#comment:3? Currently, storage directories with Unicode paths are intended to be supported on Windows.

OK... I guess that I should look into the twisted project's testing framework to determine what they know about this issue...

I'm currently snooping for leads here: http://twistedmatrix.com/trac/ticket/4736

So it seems like there may be (but probably there is not) an issue regarding Windows path representations to users versus to "OS" API's snooping here:

http://twistedmatrix.com/trac/ticket/2366

(Is replying to myself bad form?) OK so I can't tell how 2366 is (or is not resolved) should I get a twisted login so I can ask about it on that ticket... I await direction.

comment:16 Changed at 2011-07-21T19:52:44Z by zooko

I did some investigation about non-ASCII filename handling in filepath and in Tahoe-LAFS and posted my notes on Twisted #5203.

Changed at 2011-07-22T07:03:25Z by arch_o_median

Changed at 2011-07-22T20:32:40Z by arch_o_median

Changed at 2011-07-23T03:19:05Z by arch_o_median

comment:17 Changed at 2011-07-25T20:39:34Z by arch_o_median

After some chatting with zooko and warner in IRC, I've tentatively decided to use composition to inform the base Crawler object about the backend it is associated with. I'm not sure, but I think passing the whole <backend>Core object might be appropriate.

comment:18 Changed at 2011-07-26T04:10:47Z by Zancas

  • Owner changed from arch_o_median to Zancas

comment:19 Changed at 2011-07-27T23:05:55Z by Zancas

My current test suite contains several tests that Zooko calls "transparent box". I need to decide whether they are appropriate:

  1. remote_allocate_buckets populates incoming with shnum(s)
  2. an attempt to allocate the same share (same ss) does _not_ create a new bucketwriter
  3. test allocated size
  4. together remote_write, remote_close, get_shares, and read_share_data behave

Since I am altering the location (from server to backend/core) of some of this functionality, and since I am altering the mechanism by which the filesystem is manipulated (to FilePath)... I think all of these tests are necessary.

It would be nice if the tests were designed to ensure the proper behavior independent of the underlying storage medium... but I think I need to assume a filesystem-like interface for at least (1,2, and 4), probably (3) as well...

Last edited at 2011-07-27T23:10:14Z by Zancas (previous) (diff)

comment:20 Changed at 2011-07-29T02:31:31Z by Zancas

I'm confused about leases. When I look at the constructor for an immutable share file in a 'pristine' repository, (or in my latest version for that matter) I see that in the "create" clause of the constructor a python string representation of a big endian '0' is used for the number of leases.

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/storage/immutable.py#L63

This is confusing because in my test vector data (created some time ago) I have '1' as the initial number of leases. My guess is that I somehow got a bum test-vector value, but it'd be nice to hear from an architect that immutable share files really should start life with '0' leases!

Changed at 2011-07-29T04:39:33Z by Zancas

Patch passes allmydata.test.test_backends.TestServerAndFSBackend.test_write_and_read_share

comment:21 Changed at 2011-07-29T14:24:35Z by zooko

Cool! Will review.

Changed at 2011-07-29T23:54:48Z by Zancas

TestServerAndFSBackend.test_read_old_share passes

Changed at 2011-07-30T00:59:39Z by Zancas

TestServerAndFSBackend passes all (3) tests

Changed at 2011-07-30T03:41:42Z by Zancas

5 test_backend tests pass

comment:22 Changed at 2011-07-30T04:23:07Z by Zancas

  • Version changed from 1.6.0 to n/a

Changed at 2011-08-01T09:47:05Z by Zancas

uggg... bugs...

Changed at 2011-08-01T20:05:17Z by Zancas

the 5 tests pass... so what?

comment:23 Changed at 2011-08-11T04:40:10Z by Zancas

  • Owner changed from Zancas to zancas

comment:24 Changed at 2011-08-29T16:45:15Z by zancas

Ticket 1465 more succinctly organizes the same code contained in these patches.

comment:25 Changed at 2011-09-01T03:36:21Z by zooko

I added attachment:backends-configuration-docs.darcs.patch which contains documentation of the configuration options for the backends feature. I like Brian Warner's approach to development where he writes the docs first, even before the tests. (He writes tests second.) I encourage anyone working on this ticket to read (and possibly improve/fix/extend) these docs!

comment:26 follow-up: Changed at 2011-09-02T01:44:21Z by davidsarah

Review of backends-configuration-docs.darcs.patch:

s3.rst:

  • Add a short introduction saying what S3 is and why anyone might want to use it.
  • It's a bit inconsistent that the value of the backend option is uppercase "S3", but the other option names are lowercase "s3_*". Also, I would make it "s3.*", since that's similar to the use of "." to group other related options.
  • Should the s3_url option include the scheme name, i.e. defaulting to http://s3.amazonaws.com ? We might want to support https in future (although there would be more to configure if we check certificates).
  • In the description of s3_max_space, copy the paragraph starting "This string contains a number" from disk.rst rather than referring to it.
  • "enabling ``s3_max_space`` causes an extra S3 usage query to be sent for each share upload, causing the upload process to run slightly slower and incur more S3 request charges."

Each space query could be amortized over several uploads, using an estimate of the used space in-between. (That wouldn't be accurate if there are several storage servers accessing the same bucket, but it would be accurate enough if the maximum number of such servers is limited.) Even if we don't implement that right away, I'm not sure that this performance issue needs to go in s3.rst.

disk.rst:

  • "Storing Shares in local filesystem" -> "Storing Shares on a Local Filesystem"
  • use backend = disk, not backend = local filesystem, and say that it is the default.

configuration.rst:

  • "Clients will be unaware of what backend is used by the server." -> "Clients need not be aware of which backend is used by a server."
  • "including how to limit the space that will be consumed" -> "including how to reserve a minimum amount of free space"
Version 1, edited at 2011-09-02T01:47:22Z by davidsarah (previous) (next) (diff)

comment:27 Changed at 2011-09-02T04:47:04Z by zooko

I closed the subsidiary ticket #1465 as "fixed". The current patch set for this ticket as of this writing is attachment:20110829passespyflakes.darcs.patch (from that ticket) plus attachment:backends-configuration-docs.darcs.patch.

Changed at 2011-09-15T02:50:08Z by davidsarah

This is just a "flat" recording of my refactoring of pluggable backends. I'll do a better recording tomorrow, and explain the refactoring.

Changed at 2011-09-17T02:13:03Z by davidsarah

This is still just a flat recording (a lot more changes to tests were needed than I anticipated).

Changed at 2011-09-19T20:33:29Z by davidsarah

Bleeding edge pluggable backends code from David-Sarah. refs #999

Changed at 2011-09-19T23:38:51Z by davidsarah

Rerecording of pluggable-backends-davidsarah-v3.darcs.patch that should fix the darcs performance problem when applied to trunk.

Changed at 2011-09-20T03:42:59Z by davidsarah

Work-in-progress, includes fix to bug involving BucketWriter?. refs #999

comment:28 in reply to: ↑ 26 ; follow-ups: Changed at 2011-09-20T17:04:34Z by zancas

Replying to davidsarah:

Review of backends-configuration-docs.darcs.patch:

s3.rst:

  • Add a short introduction saying what S3 is and why anyone might want to use it.
  • It's a bit inconsistent that the value of the backend option is uppercase "S3", but the other option names are lowercase "s3_*". Also, I would make it "s3.*", since that's similar to the use of "." to group other related options.
  • Should the s3_url option include the scheme name, i.e. defaulting to http://s3.amazonaws.com ? We might want to support https in future (although there would be more to configure if we check certificates).
  • In the description of s3_max_space, copy the paragraph starting "This string contains a number" from disk.rst rather than referring to it.
  • "enabling ``s3_max_space`` causes an extra S3 usage query to be sent for each share upload, causing the upload process to run slightly slower and incur more S3 request charges."

Each space query could be amortized over several uploads, using an estimate of the used space in-between. (That wouldn't be accurate if there are several storage servers accessing the same bucket, but it would be accurate enough if the maximum number of such servers is limited.) Even if we don't implement that right away, I'm not sure that this performance issue needs to go in s3.rst.

disk.rst:

  • "Storing Shares in local filesystem" -> "Storing Shares on a Local Filesystem"
  • use backend = disk, not backend = local filesystem, and say that it is the default.

configuration.rst:

  • "Clients will be unaware of what backend is used by the server." -> "Clients need not be aware of which backend is used by a server."
  • "including how to limit the space that will be consumed" -> "including how to reserve a minimum amount of free space"
  • currently clients _are_ aware of backend type.

Changed at 2011-09-20T17:26:01Z by davidsarah

docs: document the configuration options for the new backends scheme. This takes into account ticket:999#comment:26 and is rerecorded to avoid darcs context problems.

comment:29 in reply to: ↑ 28 Changed at 2011-09-20T17:44:31Z by zooko

Replying to zancas:

  • currently clients _are_ aware of backend type.

They are? I don't think so. How would they find out about the backend type?

comment:30 Changed at 2011-09-20T17:51:49Z by zooko

attachment:backends-configuration-docs-v2.darcs.patch looks good to me. One thing I would change is to remove the "Issues" section about the costs of querying S3 objects and the effects on our crawler/lease-renewal scheme. I'm not sure that this branch will eventually land without a lease-checker implemented, so that part is making a statement that might be wrong. Also I'm not really sure the costs of querying S3 objects are worth mentioning. The current S3 pricing has 10,000 GET requests for $0.01. Let's remove that documentation for now and add in documentation when we understand better what the actual limitations or costs will be.

comment:31 in reply to: ↑ 28 ; follow-up: Changed at 2011-09-20T19:53:04Z by davidsarah

Replying to zancas:

Replying to davidsarah:

configuration.rst:

  • "Clients will be unaware of what backend is used by the server." -> "Clients need not be aware of which backend is used by a server."
  • currently clients _are_ aware of backend type.

The doc meant that client nodes need not be aware of backend type. Although the current hack to wire up a StorageServer to a backend in pluggable-backends-davidsarah-v5.darcs.patch is in allmydata/client.py, that code isn't actually run by clients, it is run only when setting up a storage server.

comment:32 in reply to: ↑ 31 Changed at 2011-09-20T19:57:02Z by davidsarah

Replying to davidsarah:

Replying to zancas:

Replying to davidsarah:

configuration.rst:

  • "Clients will be unaware of what backend is used by the server." -> "Clients need not be aware of which backend is used by a server."
  • currently clients _are_ aware of backend type.

The doc meant that client nodes need not be aware of backend type.

Ugh, I should never use the term "node" :-/. I meant the code that acts as a storage protocol client.

Changed at 2011-09-21T03:21:58Z by davidsarah

v6. Tests are looking in much better shape now -- still some problems with path vs FilePath? and other stale assumptions in the test framework, but the disk backend basically works now.

Changed at 2011-09-21T15:54:50Z by davidsarah

Add --trace-exceptions option to trace raised exceptions on stderr. refs #999

Changed at 2011-09-21T18:54:37Z by davidsarah

Latest snapshot, more tests passing.

Changed at 2011-09-21T21:12:15Z by zooko

snapshot of work in progress

Changed at 2011-09-21T22:29:14Z by davidsarah

v8 snapshot. More tests pass.

Changed at 2011-09-22T05:11:43Z by davidsarah

Still more test fixes.

comment:33 Changed at 2011-09-22T15:40:59Z by davidsarah

Josh wrote, re: pluggable-backends-davidsarah-v8.darcs.patch:

I think the test_crawlers failure stems from ShareCrawler being passed a FilePath object in its constructor where it expects a string literal to use in an old-style call to open (specifically in its "load_state" method). I'm not certain yet, but I think I'll stop here for the night.

No, load_state uses pickle.loads(self.statefp.getContent()) which is correct. The state handling is a red herring for the test_crawlers failure, I think.

Last edited at 2011-09-22T15:41:33Z by davidsarah (previous) (diff)

comment:34 follow-up: Changed at 2011-09-22T15:48:02Z by davidsarah

In v9, allmydata.test.test_storage.LeaseCrawler.test_basic is hanging due to an infinite recursion in pickle.py. Use

bin/tahoe --trace-exceptions debug trial --rterror allmydata.test.test_storage.LeaseCrawler.test_basic

(with trace-exceptions-option.darcs.patch applied) to see the recursion. I'm on the case...

comment:35 in reply to: ↑ 34 Changed at 2011-09-22T16:09:36Z by davidsarah

Replying to davidsarah:

In v9, allmydata.test.test_storage.LeaseCrawler.test_basic is hanging due to an infinite recursion in pickle.py.

That was another red herring; there was an innocuous exception in pickle.py that was happening in each iteration of whatever other code is livelocking.

Changed at 2011-09-22T18:38:53Z by davidsarah

Fix most of the crawler tests. Reinstate the cancel_lease methods of ImmutableDiskShare? and MutableDiskShare?, since they are needed for lease expiry. refs #999

Changed at 2011-09-23T04:20:00Z by davidsarah

Includes a fix for iterating over a dict while removing entries from it in mutable/publish.py, some cosmetic changes, and a start on the S3 backend.

Changed at 2011-09-23T20:59:31Z by davidsarah

Updates to null and S3 backends.

Changed at 2011-09-27T06:37:30Z by zancas

contains changes in v12

Changed at 2011-09-27T07:47:54Z by davidsarah

Includes fixes to test_status_bad_disk_stats and test_no_st_blocks in test_storage.py, and more work on the S3 backend.

Changed at 2011-09-27T07:48:49Z by davidsarah

Work in progress for asyncifying the backend interface (necessary to call txaws methods that return Deferreds). This is incomplete so lots of tests fail. refs #999

comment:36 Changed at 2011-09-28T00:09:58Z by davidsarah

In v13, test_storage.LeaseCrawler.test_share_corruption fails. However this is a test that is known to have race conditions -- it used to fail when logging was enabled (#923), and we tried to fix that in 3b1b0147a867759c, but in a way that in retrospect didn't really address the cause of the race condition. The problem is that it's trying to check for a particular instantaneous state of the lease crawler while it is running, which is inherently race-prone.

I suggest we not worry about this test for the current LAE iteration.

Changed at 2011-09-28T01:45:53Z by davidsarah

This does not include the asyncification changes from v14, but does include a couple of fixes for failures in test_system.

Changed at 2011-09-28T05:34:24Z by davidsarah

bleeding edge of asyncification work

comment:37 Changed at 2011-09-28T09:24:27Z by zancas

Huh... weird, I can't apply v15...

0 /home/arc/sandbox/working 550 $ darcs apply pluggable-backends-davidsarah-v15.darcs.patch

darcs failed: Bad patch bundle! 2 /home/arc/sandbox/working 551 $

Changed at 2011-09-29T04:19:16Z by davidsarah

Latest asyncified patch. About 90% of tests pass.

Changed at 2011-09-29T04:26:51Z by davidsarah

Differences, just in the S3 backend, between v13a and v16.

Changed at 2011-09-29T08:24:10Z by davidsarah

Completes the splitting of IStoredShare into IShareForReading and IShareForWriting. Does not include configuration changes.

Changed at 2011-09-29T17:14:08Z by davidsarah

Snapshot of test_backends.py in David-Sarah's tree

Changed at 2011-09-29T18:33:41Z by davidsarah

Includes backend configuration (rerecorded from zooko's patch), and other minor fixes.

Changed at 2011-09-29T20:29:16Z by zooko

Changed at 2011-09-29T21:27:35Z by davidsarah

Include missing files for real and mock S3 backends. Also some fixes to tests, scripts/debug.py, and config parsing.

comment:38 Changed at 2011-09-29T23:51:43Z by david-sarah@…

In [5373/ticket999-S3-backend]:

test_storage.py: only run test_large_share on the disk backend. (It will wedge your machine if run on the S3 backend with MockS3Bucket.) refs #999

comment:39 Changed at 2011-09-29T23:51:44Z by david-sarah@…

In [5374/ticket999-S3-backend]:

test/mock_s3.py: fix a typo. refs #999

comment:40 Changed at 2011-09-29T23:51:45Z by david-sarah@…

In [5375/ticket999-S3-backend]:

Make sure that the statedir is created before trying to use it. refs #999

comment:41 Changed at 2011-09-29T23:58:30Z by david-sarah@…

In [5376/ticket999-S3-backend]:

s3_bucket.py: fix an incorrect argument signature for list_objects. refs #999

comment:42 Changed at 2011-09-30T00:15:11Z by david-sarah@…

In [5379/ticket999-S3-backend]:

mock_s3.py: fix bug in MockS3Error constructor. refs #999

comment:43 Changed at 2011-09-30T00:15:11Z by david-sarah@…

In [5380/ticket999-S3-backend]:

test_storage.py: Server class uses ShouldFailMixin?. refs #999

comment:44 Changed at 2011-09-30T02:19:02Z by david-sarah@…

In [5382/ticket999-S3-backend]:

Add dummy lease methods to immutable S3 share objects. refs #999

comment:45 Changed at 2011-09-30T21:28:44Z by david-sarah@…

In [5387/ticket999-S3-backend]:

s3/immutable.py: minor simplification in ImmutableS3ShareForReading. refs #999

comment:46 Changed at 2011-10-04T01:12:02Z by david-sarah@…

In [5388/ticket999-S3-backend]:

Add a share._get_filepath() method used by tests to get the FilePath? for a share, rather than accessing the _home attribute. refs #999

comment:47 Changed at 2011-10-04T01:12:05Z by david-sarah@…

In [5391/ticket999-S3-backend]:

s3/s3_common.py: remove incorrect 'self' arguments from interface methods in IS3Bucket. refs #999

comment:48 Changed at 2011-10-04T01:12:05Z by david-sarah@…

In [5392/ticket999-S3-backend]:

More asyncification of tests. Also fix some bugs due to capture of slots in for loops. refs #999

Changed at 2011-10-07T08:25:56Z by davidsarah

Fix various bugs and tests. v20

comment:49 Changed at 2011-10-07T15:44:01Z by davidsarah

Re: pluggable-backends-davidsarah-v20.darcs.patch, I made a mistake in recording it that will cause a conflict with the ticket999-S3-backend branch. I'll attach a fixed version.

comment:50 Changed at 2011-10-07T19:39:49Z by david-sarah@…

In [5400/ticket999-S3-backend]:

Add a get_share method to IShareSet, to get a specific share. refs #999

comment:51 Changed at 2011-10-07T19:39:50Z by david-sarah@…

In [5402/ticket999-S3-backend]:

Add a _get_sharedir() method on IShareSet, implemented by the disk and mock S3 backends, for use by tests. refs #999

comment:52 Changed at 2011-10-07T19:39:51Z by david-sarah@…

In [5403/ticket999-S3-backend]:

Fix some miscapture bugs. refs #999

comment:53 Changed at 2011-10-07T19:39:52Z by david-sarah@…

In [5404/ticket999-S3-backend]:

Fix a duplicate umid. refs #999

comment:54 Changed at 2011-10-07T19:39:53Z by david-sarah@…

In [5405/ticket999-S3-backend]:

Remove unused load method and _loaded attribute from s3/mutable.py. refs #999

comment:55 Changed at 2011-10-07T19:39:54Z by david-sarah@…

In [5406/ticket999-S3-backend]:

Remove an inapplicable comment. refs #999

comment:56 Changed at 2011-10-07T19:39:55Z by david-sarah@…

In [5407/ticket999-S3-backend]:

Make sure that get_size etc. work correctly on an ImmutableS3ShareForWriting after it has been closed. Also simplify by removing the _end_offset attribute. refs #999

comment:57 Changed at 2011-10-07T19:39:56Z by david-sarah@…

In [5408/ticket999-S3-backend]:

unlink() on share objects should be idempotent. refs #999

comment:58 Changed at 2011-10-07T19:39:57Z by david-sarah@…

In [5409/ticket999-S3-backend]:

Partially asyncify crawlers. refs #999

comment:59 Changed at 2011-10-07T19:39:58Z by david-sarah@…

In [5410/ticket999-S3-backend]:

More miscapture fixes. refs #999

comment:60 Changed at 2011-10-07T19:39:59Z by david-sarah@…

In [5411/ticket999-S3-backend]:

Ensure that helper classes are not treated as test cases. Also fix a missing mixin. refs #999

comment:61 Changed at 2011-10-07T19:39:59Z by david-sarah@…

In [5412/ticket999-S3-backend]:

disk backend: size methods should no longer return Deferreds. refs #999

comment:62 Changed at 2011-10-07T19:59:24Z by david-sarah@…

In [5414/ticket999-S3-backend]:

test_storage.py: fix a trivial bug in LeaseCrawler?.test_unpredictable_future. refs #999

comment:63 Changed at 2011-10-07T20:02:16Z by davidsarah

Please ignore pluggable-backends-davidsarah-v20.darcs.patch; the equivalent of that patch is on the ticket999-S3-backend branch now.

comment:64 Changed at 2011-10-09T23:25:13Z by david-sarah@…

In [5415/ticket999-S3-backend]:

storage/backends/disk/mutable.py: put back a correct assertion that had been disabled. storage/base.py: fix the bug that was causing that assertion to fail. refs #999

comment:65 Changed at 2011-10-10T00:22:44Z by davidsarah

[5415/ticket999-S3-backend] fixes all but one of the tests in test_mutable.py.

comment:66 Changed at 2011-10-10T18:15:16Z by david-sarah@…

In [5416/ticket999-S3-backend]:

test_storage.py: move some tests that were not applicable to all backends out of ServerTest?. refs #999

comment:67 Changed at 2011-10-10T19:19:47Z by david-sarah@…

In [5417/ticket999-S3-backend]:

Instrument some assertions to report the failed values. refs #999

comment:68 Changed at 2011-10-10T20:07:49Z by david-sarah@…

In [5419/ticket999-S3-backend]:

interfaces.py: resolve conflicts with trunk. refs #999

comment:69 Changed at 2011-10-10T20:10:57Z by david-sarah@…

In [5421/ticket999-S3-backend]:

interfaces.py: resolve another conflict with trunk. refs #999

comment:70 Changed at 2011-10-10T20:48:02Z by david-sarah@…

In [5422/ticket999-S3-backend]:

test_download.py: fix test_download_failover (it should tolerate non-existing shares in _clobber_most_shares). refs #999

comment:71 Changed at 2011-10-10T20:48:02Z by david-sarah@…

In [5423/ticket999-S3-backend]:

Null backend: implement unlink and readv more correctly. refs #999

comment:72 Changed at 2011-10-10T20:48:03Z by david-sarah@…

In [5424/ticket999-S3-backend]:

Make unlink() on share objects consistently idempotent. refs #999

comment:73 Changed at 2011-10-10T23:17:29Z by david-sarah@…

In [5425/ticket999-S3-backend]:

S3 backend: move the implementation of list_objects from s3_bucket.py to s3_common.py, making s3_bucket.py simpler and list_objects easier to test independently. refs #999

comment:74 Changed at 2011-10-10T23:17:30Z by david-sarah@…

In [5426/ticket999-S3-backend]:

Add fileutil.fp_list(fp) which is like fp.children(), but returns [] in case of a directory that does not exist. Use it to simplify the disk backend and mock S3 bucket implementations. refs #999

comment:75 Changed at 2011-10-10T23:17:31Z by david-sarah@…

In [5427/ticket999-S3-backend]:

test/mock_s3.py: fix a bug that was causing us to use the wrong directory for share files. refs #999

comment:76 Changed at 2011-10-11T00:32:41Z by david-sarah@…

In [5429/ticket999-S3-backend]:

test_storage.py: make MutableServer?.test_leases pass. refs #999

comment:77 Changed at 2011-10-11T04:44:30Z by david-sarah@…

In [5430/ticket999-S3-backend]:

test_storage.py: fix a bug introduced by asyncification of test_allocate. refs #999

comment:78 Changed at 2011-10-11T04:54:21Z by david-sarah@…

In [5431/ticket999-S3-backend]:

test_storage.py: fix a typo in test_null_backend. refs #999

comment:79 Changed at 2011-10-11T04:59:26Z by david-sarah@…

In [5432/ticket999-S3-backend]:

test_storage.py: fix a trivial bug in MDMFProxies.test_write. refs #999

comment:80 Changed at 2011-10-11T05:16:34Z by david-sarah@…

In [5433/ticket999-S3-backend]:

test_storage.py: fix asyncification of three tests in MDMFProxies. refs #999

comment:81 Changed at 2011-10-11T05:20:45Z by david-sarah@…

In [5434/ticket999-S3-backend]:

Fix two pyflakes warnings about unused imports. refs #999

comment:82 Changed at 2011-10-12T21:47:44Z by david-sarah@…

In [5445/ticket999-S3-backend]:

test_storage.py: cosmetics. refs #999

comment:83 Changed at 2011-10-12T21:47:47Z by david-sarah@…

In [5446/ticket999-S3-backend]:

test_storage.py: fix test failures in MDMFProxies. refs #999

comment:84 Changed at 2011-10-12T21:47:49Z by david-sarah@…

In [5447/ticket999-S3-backend]:

Move configuration of each backend into the backend itself. refs #999

comment:85 Changed at 2011-10-12T21:47:50Z by david-sarah@…

In [5448/ticket999-S3-backend]:

util/deferredutil.py: remove unneeded utility functions. refs #999

comment:86 Changed at 2011-10-12T21:47:52Z by david-sarah@…

In [5449/ticket999-S3-backend]:

test_storage.py: Move test_seek to its own class, since it is independent of the backend. Also move test_reserved_space to ServerWithDiskBackend?, since reserved_space is specific to that backend. refs #999

comment:87 Changed at 2011-10-12T21:47:53Z by david-sarah@…

In [5450/ticket999-S3-backend]:

test_storage.py: add a test that we can create a share, exercising the backend's get_share and get_shares methods. This may explicate particular kinds of backend failure better than the existing tests. refs #999

comment:88 Changed at 2011-10-12T21:47:54Z by david-sarah@…

In [5451/ticket999-S3-backend]:

test_storage.py: asyncify some more tests, and fix create methods. refs #999

comment:89 Changed at 2011-10-12T21:47:56Z by david-sarah@…

In [5452/ticket999-S3-backend]:

S3 backend: fix corruption advisories and listing of shares for mock S3 bucket. refs #999

comment:90 Changed at 2011-10-12T21:47:57Z by david-sarah@…

In [5453/ticket999-S3-backend]:

no_network.py: fix delete_all_shares. refs #999

comment:91 Changed at 2011-10-12T21:47:58Z by david-sarah@…

In [5454/ticket999-S3-backend]:

test_download.py: fix and reenable Corruption.test_each_byte. Add a comment noting that catalog_detection = True has bitrotted. refs #999

comment:92 Changed at 2011-10-12T23:43:38Z by david-sarah@…

In [5455/ticket999-S3-backend]:

test_storage.py: add test_write_and_read_share and test_read_old_share originally from test_backends.py. refs #999

comment:93 Changed at 2011-10-12T23:43:40Z by david-sarah@…

In [5456/ticket999-S3-backend]:

Remove test_backends.py, since all its tests are now redundant with tests in test_storage.py or test_client.py. refs #999

comment:94 Changed at 2011-10-12T23:43:41Z by david-sarah@…

In [5457/ticket999-S3-backend]:

Null backend: make NullShareSet? inherit from ShareSet?, which should implement readv correctly. Remove its implementation of testv_and_readv_and_writev since the one from ShareSet? should work (if it doesn't that would be a separate bug). refs #999

comment:95 Changed at 2011-10-12T23:43:42Z by david-sarah@…

In [5458/ticket999-S3-backend]:

S3 backend: correct list_objects to list_all_objects in IS3Bucket. refs #999

comment:96 Changed at 2011-10-12T23:43:42Z by david-sarah@…

In [5459/ticket999-S3-backend]:

storage/backends/base.py: allow readv to work for both mutable and immutable shares. refs #999

comment:97 Changed at 2011-10-13T03:53:24Z by david-sarah@…

In [5461/ticket999-S3-backend]:

test_storage.py: test_read_old_share and test_write_and_read_share should only expect to be able to read input share data. refs #999

comment:98 Changed at 2011-10-13T03:53:25Z by david-sarah@…

In [5462/ticket999-S3-backend]:

S3 backend: keep track of incoming shares, so that the storage server can avoid creating BucketWriters? for shnums that have an incoming share. refs #999

comment:99 Changed at 2011-10-13T05:08:45Z by david-sarah@…

In [5463/ticket999-S3-backend]:

docs/backends/S3.rst: note that storage servers should use different buckets. refs #999

comment:100 Changed at 2011-10-13T22:30:09Z by david-sarah@…

In [5464/ticket999-S3-backend]:

test_storage.py: fix a typo (d vs d2) in test_remove_incoming. refs #999

comment:101 Changed at 2011-10-13T23:30:32Z by david-sarah@…

In [5465/ticket999-S3-backend]:

test_storage: rename the two test_leases methods to ServerTest?.test_immutable_leases and MutableServer?.test_mutable_leases. refs #999

comment:102 Changed at 2011-10-13T23:30:33Z by david-sarah@…

In [5466/ticket999-S3-backend]:

test_storage: fix some typos introduced when asyncifying test_immutable_leases. refs #999

comment:103 Changed at 2011-10-13T23:30:33Z by david-sarah@…

In [5467/ticket999-S3-backend]:

test_storage: in test_no_st_blocks, print the rec 'dict' if checking one of its fields fails. refs #999

comment:104 Changed at 2011-10-13T23:37:20Z by david-sarah@…

In [5468/ticket999-S3-backend]:

test_storage.py: remove some redundant coercions to bool. refs #999

comment:105 Changed at 2011-10-13T23:44:17Z by david-sarah@…

In [5469/ticket999-S3-backend]:

test_storage.py: print more info when checks fail. refs #999

comment:106 Changed at 2011-10-14T03:01:00Z by david-sarah@…

In [5470/ticket999-S3-backend]:

test_storage.py: fix two bugs in test_no_st_blocks -- the _cleanup function was being called too early, and we needed to treat directories as using no space in order for the configured-sharebytes == configured-diskbytes check to be correct. refs #999

comment:107 Changed at 2011-10-14T06:21:15Z by david-sarah@…

In [5471/ticket999-S3-backend]:

Undo partial asyncification of crawlers, and enable crawlers only for the disk backend. refs #999

comment:108 Changed at 2011-10-16T01:43:11Z by david-sarah@…

In [5472/ticket999-S3-backend]:

test_storage.py: fix a bug in _backdate_leases (it was returning too early). refs #999

comment:109 Changed at 2011-10-16T03:53:15Z by david-sarah@…

In [5473/ticket999-S3-backend]:

scripts/debug.py: fix stale code in describe_share that had not been updated for changes in share interfaces. refs #999

comment:110 Changed at 2011-10-16T03:53:16Z by david-sarah@…

In [5474/ticket999-S3-backend]:

Disk backend: make sure that disk shares with a storageindex of None (as sometimes created by test code) can be printed using repr. refs #999

comment:111 Changed at 2011-10-16T04:45:11Z by david-sarah@…

In [5475/ticket999-S3-backend]:

Change accesses of ._sharehomedir on a disk shareset to _get_sharedir(). refs #999

comment:112 Changed at 2011-10-16T04:45:12Z by david-sarah@…

In [5476/ticket999-S3-backend]:

test_storage.py: cleanup to style of test_limited_history to match other tests. refs #999

comment:113 Changed at 2011-10-18T06:47:04Z by david-sarah@…

In [5477/ticket999-S3-backend]:

Change IShareSet.get_shares[_synchronous] to return a pair (list of share objects, set of corrupt shnums). This is necessary to allow crawlers to record but skip over corrupt shares. This patch also changes the behaviour of storage servers to ignore corrupt shares on read, which may or may not be what we want. Note that the S3 backend does not yet report corrupt shares. refs #999

comment:114 Changed at 2011-10-18T06:47:08Z by david-sarah@…

In [5478/ticket999-S3-backend]:

Allow crawlers and storage servers to use a deterministic clock, for testing. We do not yet take advantage of this in tests. refs #999

comment:115 Changed at 2011-10-18T06:47:09Z by david-sarah@…

In [5479/ticket999-S3-backend]:

Fix race conditions in crawler tests. (storage.LeaseCrawler?.test_unpredictable_future may still be racy.) refs #999

comment:116 Changed at 2011-10-18T06:47:10Z by david-sarah@…

In [5480/ticket999-S3-backend]:

Add some repr methods. refs #999

comment:117 Changed at 2011-10-18T17:30:39Z by davidsarah

In [5479/ticket999-S3-backend], there's also a fix to a preexisting bug in test_storage.LeaseCrawler.test_unpredictable_future, where it was checking the s["estimated-remaining-cycle"]["space-recovered"] key twice, rather than both that key and s["estimated-current-cycle"]["space-recovered"] as intended.

comment:118 Changed at 2011-10-18T18:35:12Z by david-sarah@…

In [5481/ticket999-S3-backend]:

test_storage.py, test_crawler.py: change 'bucket' terminology to 'shareset' where appropriate. refs #999

comment:119 Changed at 2011-10-18T23:40:47Z by david-sarah@…

In [5482/ticket999-S3-backend]:

S3 backend: remove max_space option. refs #999

comment:120 Changed at 2011-10-19T06:19:29Z by david-sarah@…

In [5483/ticket999-S3-backend]:

Enable mutable tests for S3 backend (they all fail, as expected). refs #999

comment:121 Changed at 2011-10-20T03:08:45Z by david-sarah@…

In [5484/ticket999-S3-backend]:

storage/backends/disk/mutable.py: correct a typo. refs #999

comment:122 Changed at 2011-10-20T03:08:47Z by david-sarah@…

In [5485/ticket999-S3-backend]:

Disk backend: fix incorrect arguments in a call to create_mutable_disk_share. refs #999

comment:123 Changed at 2011-10-20T03:08:49Z by david-sarah@…

In [5486/ticket999-S3-backend]:

test_storage.py: move the test_container_size test to MutableServerWithDiskBackend? for now, because it tries to create a very large container which will wedge your machine. refs #999

comment:124 Changed at 2011-10-20T03:08:53Z by david-sarah@…

In [5487/ticket999-S3-backend]:

S3 backend: finish implementation of mutable shares. refs #999

comment:125 Changed at 2011-10-20T11:17:59Z by david-sarah@…

In [5488/ticket999-S3-backend]:

test_storage.py: reduce duplicated code by factoring 'create' methods into CreateS3Backend and CreateDiskBackend? classes. refs #999

comment:126 Changed at 2011-10-20T11:18:00Z by david-sarah@…

In [5489/ticket999-S3-backend]:

S3 backend: make sure that the container size limit is checked before writing. refs #999

comment:127 Changed at 2011-10-20T11:18:01Z by david-sarah@…

In [5490/ticket999-S3-backend]:

S3 backend: make precondition failures show more information. refs #999

comment:128 Changed at 2011-10-20T11:56:25Z by david-sarah@…

In [5491/ticket999-S3-backend]:

S3 backend: new_length argument to MutableS3Share.writev should only be able to truncate the share (after applying writes), not extend it. refs #999

comment:129 Changed at 2011-10-20T11:56:26Z by david-sarah@…

In [5492/ticket999-S3-backend]:

S3 backend: the mutable size limit should be on the data length, not the container size. Also simplify by removing _check_size_limit. refs #999

comment:130 Changed at 2011-10-20T11:56:27Z by david-sarah@…

In [5493/ticket999-S3-backend]:

Disk backend: make sure that the size limit is checked before writing. Also, the size limit is on the data length, not the container size. refs #999

comment:131 Changed at 2011-10-20T11:56:28Z by david-sarah@…

In [5494/ticket999-S3-backend]:

test_storage.py: reenable MutableServer?.test_container_size for the S3 backend. refs #999

comment:132 Changed at 2011-10-20T17:35:41Z by david-sarah@…

In [5495/ticket999-S3-backend]:

test_storage.py: the part of test_remove that checks non-existence of the share directory after deleting a share, is only applicable to the disk backend; but, we can check that the shareset has no overhead at that point. refs #999

comment:133 Changed at 2011-10-20T17:42:43Z by davidsarah

  • Keywords gsoc removed
  • Milestone changed from soon to 1.10.0

comment:134 Changed at 2011-10-21T00:18:57Z by david-sarah@…

In [5514/ticket999-S3-backend]:

Add a '[storage]backend = mock_s3' option for use by tests. Move mock_s3.py to src/allmydataa/storage/backends/s3 since it is now imported by non-test code. refs #999

comment:135 Changed at 2011-10-21T00:18:58Z by david-sarah@…

In [5515/ticket999-S3-backend]:

test_system.py: enable system tests to run against S3 backend as well as disk backend. refs #999

comment:136 Changed at 2011-10-21T01:11:39Z by david-sarah@…

In [5516/ticket999-S3-backend]:

test_system.py: fix a typo. refs #999

comment:137 Changed at 2011-10-21T01:11:40Z by david-sarah@…

In [5517/ticket999-S3-backend]:

test_system.py: rename ServerTestWith?*Backend to ServerWith?*Backend, for consistency with tst_storage.py. refs #999

comment:138 Changed at 2011-10-21T01:52:43Z by david-sarah@…

In [5518/ticket999-S3-backend]:

test_system.py: make checks in _test_runner more picky about field names to avoid accidental suffix matches. refs #999

comment:139 Changed at 2011-10-21T01:52:44Z by david-sarah@…

In [5519/ticket999-S3-backend]:

test_system.py: ensure that subclasses of SystemTest? use different test directories. refs #999

comment:140 Changed at 2011-10-21T03:22:38Z by david-sarah@…

In [5520/ticket999-S3-backend]:

test_system.py: fix SystemWithS3Backend.test_mutable by only requiring the line specifying which nodeid the lease secrets are for when the node has a disk backend. refs #999

comment:141 Changed at 2011-10-21T03:43:38Z by david-sarah@…

In [5521/ticket999-S3-backend]:

scripts/debug.py: in catalog-shares, gracefully handle the case where a share has no leases (for example because it is an S3 share). refs #999

comment:142 Changed at 2011-10-21T04:42:32Z by david-sarah@…

In [5522/ticket999-S3-backend]:

test_system.py: check that there is no error output from invocations of 'tahoe debug'. refs #999

comment:143 Changed at 2011-10-22T04:58:36Z by david-sarah@…

In [5523/ticket999-S3-backend]:

mock_s3.py: remove bucketname argument to MockS3Bucket constructor, since it is not needed. refs #999

comment:144 Changed at 2011-10-24T18:31:36Z by david-sarah@…

In [5524/ticket999-S3-backend]:

S3 backend: remove support for [storage]readonly option. refs #999, #1568

comment:145 Changed at 2011-10-24T18:31:40Z by david-sarah@…

In [5525/ticket999-S3-backend]:

S3 backend: the s3.region option is unnecessary; it is only used for EC2 endpoints, and we only need an S3 one. Also simplify wording in S3.rst. refs #999

comment:146 Changed at 2011-10-25T10:10:05Z by david-sarah@…

In [5526/ticket999-S3-backend]:

docs/backends/S3.rst: document the requirement for the storage server to have the correct time to within 15 minutes. refs #999

comment:147 Changed at 2011-10-28T18:18:24Z by zancas

  • Owner changed from zancas to davidsarah

comment:148 Changed at 2011-12-16T16:17:27Z by davidsarah

  • Resolution set to fixed
  • Status changed from new to closed

Further work on this functionality will be in ticket #1569.

comment:149 Changed at 2011-12-16T16:17:51Z by davidsarah

  • Keywords s3-backend storage added; backend s3 removed

comment:150 Changed at 2012-03-31T23:58:14Z by davidsarah

  • Milestone changed from 1.11.0 to eventually

comment:151 Changed at 2012-09-13T17:46:21Z by mk.fg

  • Cc mk.fraggod@… added

comment:152 Changed at 2019-09-08T22:55:09Z by amontero

  • Cc amontero@… added
  • Description modified (diff)
Note: See TracTickets for help on using tickets.