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. _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev