devchat notes 08-Aug-2017
Brian Warner
warner at lothar.com
Tue Aug 8 20:09:23 UTC 2017
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
problem
* 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
"wormhole.leastauthority.com"
* 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.
More information about the tahoe-dev
mailing list