configurable on/off storage server #168

New Issue

zooko · 2007-10-08T20:10:44Z

zooko commented

2007-10-08 20:10:44 +00:00

It would be nice if you could run a Tahoe client without running a storage server.

http://allmydata.org/pipermail/tahoe-dev/2007-October/000189.html

It would be nice if you could run a Tahoe client without running a storage server. <http://allmydata.org/pipermail/tahoe-dev/2007-October/000189.html>

zooko added the

labels 2007-10-08 20:10:44 +00:00

zooko added this to the undecided milestone 2007-10-08 20:10:44 +00:00

warner commented

2007-10-11 09:57:57 +00:00

so, you can mostly do this, by writing "0" into a file named 'sizelimit'. If you do that, you still
wind up with a StorageServer instance, but it will reject all lease requests.

We should make several changes here:

if sizelimit==0, don't even create a StorageServer. We need to modify the peer-selection code
to not complain when callRemote("get_service", "storage") fails, so that this doesn't cause
a lot of noise in the logs on both ends.
Add a --no-storage or --storage or --storage-size-limit option to 'create-client', to make
it easy to set this value at node-creation time.

so, you can mostly do this, by writing "0" into a file named 'sizelimit'. If you do that, you still wind up with a [StorageServer](wiki/StorageServer) instance, but it will reject all lease requests. We should make several changes here: * if sizelimit==0, don't even create a [StorageServer](wiki/StorageServer). We need to modify the peer-selection code to not complain when callRemote("get_service", "storage") fails, so that this doesn't cause a lot of noise in the logs on both ends. * Add a --no-storage or --storage or --storage-size-limit option to 'create-client', to make it easy to set this value at node-creation time.

warner modified the milestone from undecided to 0.7.0

2007-10-11 10:19:16 +00:00

zooko added

0.6.1

and removed

0.6.0

labels 2007-10-18 23:22:01 +00:00

zooko self-assigned this 2007-10-18 23:22:01 +00:00

zooko commented

2007-11-01 17:25:44 +00:00

We're focussing on an imminent v0.7.0 (see the roadmap) which hopefully has [#197 Small Distributed Mutable Files] and also a fix for [#199 bad SHA-256]. So I'm bumping less urgent tickets to v0.7.1.

We're focussing on an imminent v0.7.0 (see [the roadmap](http://allmydata.org/trac/tahoe/roadmap)) which hopefully has [#197 Small Distributed Mutable Files] and also a fix for [#199 bad SHA-256]. So I'm bumping less urgent tickets to v0.7.1.

zooko added

minor

and removed

major

labels 2007-11-13 19:40:18 +00:00

robk commented

2008-01-05 01:58:56 +00:00

Brian and I just had a long discussion, incited by this ticket, about refactoring introduction.

Of the ideas discussed, the best seems to be to split introduction into publish and subscribe aspects (so that, e.g., storage servers can publish without subscribing, and storageless clients can subscribe without publishing) and along with that most probably to add 'type' information, so that objects published to the introducer are published as a specific type ('storage', 'login', 'encoder', 'checker' etc) and then consumers can subscribe to notifications of the types they're interested in.

This then retains a single-point of entry for configuration simplicity, while providing a flexible method for handling discovery of disparate types of services, and hence later extensions to new types of service.

Brian and I just had a long discussion, incited by this ticket, about refactoring introduction. Of the ideas discussed, the best seems to be to split introduction into publish and subscribe aspects (so that, e.g., storage servers can publish without subscribing, and storageless clients can subscribe without publishing) and along with that most probably to add 'type' information, so that objects published to the introducer are published as a specific type ('storage', 'login', 'encoder', 'checker' etc) and then consumers can subscribe to notifications of the types they're interested in. This then retains a single-point of entry for configuration simplicity, while providing a flexible method for handling discovery of disparate types of services, and hence later extensions to new types of service.

zooko commented

2008-01-05 02:36:02 +00:00

Nice!