[tahoe-lafs-trac-stream] [tahoe-lafs] #1568: S3 backend: [storage]readonly is documented but ignored

[tahoe-lafs]

#1568: S3 backend: [storage]readonly is documented but ignored
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  zooko
  davidsarah             |     Status:  assigned
         Type:  defect   |  Milestone:  1.10.0
     Priority:  major    |    Version:  1.9.0b1
    Component:  code-    |   Keywords:  s3-backend readonly storage lae
  storage                |  review-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by gdt):

 I don't really follow this.  It seems reasonable for a server operator to
 decide to not accept new shares, and for this to be separate than whether
 the server process is able to write the filesystem where the shares are
 kept.  For example, it might be reasonable to allow lease renewal, or for
 other metadata to be updated.   It might be that not accepting shares
 should be similar to zero space available, so increasing the size of a
 mutable share also might not be allowed.   And, if the purpose really is
 decommissioning, then presumably the mechanism used for repair should
 somehow signal that the share is present but should be migrated, so that a
 deep-check --repair can put those shares on some other server.

 There's a difference between people that don't understand enough to
 sysadmin a server, and the server having uniform configuation for server-
 level behavior.  When tahoe is ported to
 [http://en.wikipedia.org/wiki/Incompatible_Timesharing_System ITS], it
 should still be possible to tell it to stop taking shares.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1568#comment:6>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage