Tahoe-LAFS devchat 08-Aug-2017

Attendees: warner, exarkun, meejah, simpson, dawuud

* current deprecation warnings
 * twisted/conch/ssh/keys.py:1340: DeprecationWarning: signer and
   verifier have been deprecated. Please use sign and verify instead.
  * make sure there's a Twisted bug filed on this one
 * the others are in pyopenssl or Cryptography, and should be fixed by
   their next release
* other buildbot problems
 * both openbsd builders (Kyle, sickness) seem to be using the wrong
   compiler options
 * Centos just started failing because 'tox' is not executable
 * xenial is failing (has for a month now) because of the tox2/tox3
* warner noticed a lot of "fURL" in the docs, should be FURL, will file
  a bug/patch
* tahoe-invite PR418
 * should the wormhole.tahoe-lafs.org Rendezvous Server listen on port
   80 instead of 4000?
  * since port 80 is more reachable than 4000
  * requires us to set up a reverse proxy, to share port 80 between
    nginx/trac and the rendezvous
  * plan: land as-is, later (after we figure out reverse proxy) change
    from 4000 to 80 or 443, add TCP forwarder from the old port
 * change wormhold appid to "tahoe-lafs.org/invite", no need for /v1 or
   extra "tahoe-lafs"
 * warner will add CNAME from "wormhole.tahoe-lafs.org" to
*  test_node needs to be changed to not actually listen on ports
 * meejah's change in PR418 was needed to avoid listening on 1234
 * test shouldn't need to listen at all
* cloud-backend
 * close PR264
* sequence of necessary steps
 * async startup PR417
 * pluggable leasedb, initial only implementation is local sqlite (but
   constructor returns Deferred)
* should the leasedb be simpler?
 * what if the only way to delete share was to have a server that stays
   up for at least a month?
 * keep the leasedb in RAM? (or in a tempfile that is dropped at
   restart) (or just delete the DB at startup)
 * accounting info isn't correct until the server has been up long
   enough for renewals to arrive
 * or meejah proposes: no leasedb. just a crawler, that starts a 30-day
   deletion timer on each share. when a client adds a lease, the timer
   is reset
  * doomsday list
  * when the timer expires, the share is deleted
  * accounting keeps a client->shares table, those entries are deleted
    when the timer expires
 * maybe only consider deleting share when a crawler touches it
  * crawler checks: starter-lease timer, all account objects
  * account objects can hold a bloom filter or explicit list of SIs,
    veto deletion of each share at the moment of crawl
* Accounting / Leases / Cloud backends
 * Current work I know of is attached to 2237
 * Are these old tickets helpful or harmful?
  * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1818
  * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1819
  * No, close them.

tahoe-dev mailing list

Reply via email to