From: Daira Hopwood Date: Wed, 9 Apr 2014 04:34:08 +0000 (+0100) Subject: Leasedb and cloud backend merge is scheduled for v1.12.0. X-Git-Url: https://git.rkrishnan.org/pf/content/en/service?a=commitdiff_plain;h=1fa0202b4f0b1fc3fe93efbbcf35d4fb6da2ada6;p=tahoe-lafs%2Ftahoe-lafs.git Leasedb and cloud backend merge is scheduled for v1.12.0. Signed-off-by: Daira Hopwood --- diff --git a/docs/backends/disk.rst b/docs/backends/disk.rst index c4e54c67..eaed40a1 100644 --- a/docs/backends/disk.rst +++ b/docs/backends/disk.rst @@ -3,7 +3,7 @@ Storing Shares on a Local Filesystem ==================================== The "disk" backend stores shares on the local filesystem. Versions of -Tahoe-LAFS before v1.11.0 always stored shares in this way. +Tahoe-LAFS before v1.12.0 always stored shares in this way. ``[storage]`` diff --git a/docs/garbage-collection.rst b/docs/garbage-collection.rst index 2078fdcc..091f13eb 100644 --- a/docs/garbage-collection.rst +++ b/docs/garbage-collection.rst @@ -205,13 +205,13 @@ The ``tahoe.cfg`` file uses the following keys to control lease expiration: In previous versions, the ``expire.immutable`` and ``expire.mutable`` keys could be used to selectively expire only mutable or only immutable shares. -As of Tahoe-LAFS v1.11.0, these are no longer supported and will cause an +As of Tahoe-LAFS v1.12.0, these are no longer supported and will cause an error if set to ``False``. Expiration Progress =================== -As of Tahoe-LAFS v1.11.0, leases are stored in a database that can be queried +As of Tahoe-LAFS v1.12.0, leases are stored in a database that can be queried and updated quickly, rather than in share files. However, an "accounting crawler" is still needed to discover shares when upgrading from a previous version, and to actually delete expired shares. The crawler limits the amount diff --git a/docs/proposed/leasedb.rst b/docs/proposed/leasedb.rst index cab0e103..21f81c7b 100644 --- a/docs/proposed/leasedb.rst +++ b/docs/proposed/leasedb.rst @@ -5,7 +5,7 @@ Lease database design ===================== The target audience for this document is developers who wish to understand -the new lease database (leasedb) planned to be added in Tahoe-LAFS v1.11.0. +the new lease database (leasedb) planned to be added in Tahoe-LAFS v1.12.0. Introduction diff --git a/src/allmydata/interfaces.py b/src/allmydata/interfaces.py index de6574a5..56bc6ce4 100644 --- a/src/allmydata/interfaces.py +++ b/src/allmydata/interfaces.py @@ -101,7 +101,7 @@ class RIStorageServer(RemoteInterface): """ Allocate BucketWriters for a set of shares on this server. - renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.11.0, + renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.12.0, but for backward compatibility with older servers, should be calculated in the same way as previous clients (see allmydata.util.hashutil.file_{renewal,cancel}_secret_hash). @@ -139,7 +139,7 @@ class RIStorageServer(RemoteInterface): longer lease), but expiration behaviour also depends on the server's configured policy (see docs/garbage-collection.rst). - renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.11.0, + renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.12.0, but for backward compatibility with older servers, should be calculated in the same way as previous clients (see allmydata.util.hashutil.file_{renewal,cancel}_secret_hash). @@ -156,14 +156,14 @@ class RIStorageServer(RemoteInterface): longer lease), but expiration behaviour also depends on the server's configured policy (see docs/garbage-collection.rst). - renew_secret is ignored as of Tahoe-LAFS v1.11.0, but for backward + renew_secret is ignored as of Tahoe-LAFS v1.12.0, but for backward compatibility with older servers, should be calculated in the same way as previous clients (see allmydata.util.hashutil.file_renewal_secret_hash). In versions - prior to v1.X.0, this method would only renew leases with the given + prior to v1.12.0, this method would only renew leases with the given renew_secret. - Note that as of Tahoe-LAFS v1.11.0, the lease database does not retain + Note that as of Tahoe-LAFS v1.12.0, the lease database does not retain information about the node ids of lease holders, so if an IndexError is raised for a mutable share, it no longer includes that information. """ @@ -212,7 +212,7 @@ class RIStorageServer(RemoteInterface): The 'secrets' argument is a tuple of (write_enabler, renew_secret, cancel_secret). The first is required to perform any write. - renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.11.0, + renew_secret and cancel_secret are ignored as of Tahoe-LAFS v1.12.0, but for backward compatibility with older servers, should be calculated in the same way as previous clients (see allmydata.util.hashutil.file_{renewal,cancel}_secret_hash). diff --git a/src/allmydata/storage/backends/disk/immutable.py b/src/allmydata/storage/backends/disk/immutable.py index 0363b8fe..61da7d93 100644 --- a/src/allmydata/storage/backends/disk/immutable.py +++ b/src/allmydata/storage/backends/disk/immutable.py @@ -24,7 +24,7 @@ from allmydata.storage.common import si_b2a, CorruptStoredShareError, UnknownImm # Footnote 1: as of Tahoe v1.3.0 this field is not used by storage servers. -# Footnote 2: as of Tahoe v1.11.0 this field is not used by storage servers. +# Footnote 2: as of Tahoe v1.12.0 this field is not used by storage servers. # New shares will have a 0 here. Old shares will have whatever value was left # over when the server was upgraded. All lease information is now kept in the # leasedb.