[tahoe-dev] Physical Meetup 2013-12-10: Minutes of the Meeting

[Zancas Dearana]

Summary:
  This was a brief meeting.  The technical content was focused on the
"Lease Database" documentation.

https://github.com/davidsarah/tahoe-lafs/blob/5161b1fb8dea9ad9dce23db5f8f7c89c3d7ea82d/docs/proposed/leasedb.rst

Discussion:

freddyb (having reviewed the document prior to the meetup) felt that
an understanding of the "pre-leasedb" architecture was implied by the
format of "leasedb.rst".

warner mentioned a "Theory of Operation" (I believe this is what he
was referring to: https://en.wikipedia.org/wiki/Theory_of_operation)
and suggested the following format:

 1) motivation
 2) description of the "Steady State" operating result
 3) subsequent description of edge cases (e.g. startup)

Zooko suggested that the section currently titled "Motivation" should
be an appendix.  (I'm unclear on whether or not this is consistent
with the format warner advocated.)

Warner described some aspects of peer-to-peer communication in the
context of Tahoe to Tom, at the edge of my hearing (i.e. I have no
details to report).

freddyb and I discussed the notion of a "share" he said
(approximately):  "Your data is divided into a set of shares a subset
of which is sufficient to recover that data."

[Caveat Emptor:  We didn't talk about the fact that the subset is not
strict, in the sense that you may need _all_ of the shares.   For
example, in the LeastAuthority TLOS3 case there's only 1 share. We
assume decryption capability.]

Our conversation was stimulated by my experience scanning the document
related code in preparation for the meeting.

The following assumes "immutables" as context:
 Before the Lease Database existed leases were stored with the data in
"ShareFiles".

https://github.com/tahoe-lafs/tahoe-lafs/blob/a9272522d5aff5342d08892992bf669b047c17fe/src/allmydata/storage/immutable.py#L39

  These ShareFiles then provided  methods both for data management
(reading, writing, etc.) and for _meta_data management (renew_lease,
etc.).

 There did not exist a class implementing an interface for a share as
an object independent of the ShareFile.

 The accounting architecture permits the excision of the ShareFile class.

 Classes implementing the IShareBase, IShareForWriting, and
IShareForReading interfaces replace the data management functionality,
while the AccountingCrawler class handles lease data.

  Because the storage media is abstracted away in the cloud backend
there are different types of IShareBase implementing classes:

https://github.com/davidsarah/tahoe-lafs/blob/5161b1fb8dea9ad9dce23db5f8f7c89c3d7ea82d/src/allmydata/interfaces.py#L476

  The AccountingCrawler is defined in the allmydata/storage directory
as it uses the abstract "backend" object to interface with backends in
general:

https://github.com/davidsarah/tahoe-lafs/blob/5161b1fb8dea9ad9dce23db5f8f7c89c3d7ea82d/src/allmydata/storage/accounting_crawler.py#L13

  In short, as reflected in the document the commonly understood
concept of the "Share" is now more closely reified as a "IShareBase"
than was possible in the pre-accounting architecture.


 We did not discuss the states of a share and the possible transitions
between them.   I propose those topics as the agenda for the next
meetup!


  Changes to the content of the document as a result of the meeting are here:

https://github.com/zancas/tahoe-lafs-1/blob/bc0e3766805f3f8842b6158ccf0b49d44d09ef30/docs/proposed/leasedb.rst

--
-- ظ

P.S.-- Dinner afterwards was great fun!