<div dir="ltr"><div dir="ltr" class="gmail_msg">Some observations.<br class="gmail_msg"><br class="gmail_msg">#Improving the usability of the Docker containers<br class="gmail_msg"><br class="gmail_msg">So there are basically two ways of configuring Docker containers<br class="gmail_msg"><br class="gmail_msg">1. Environment Variables<br class="gmail_msg">2. Configuration files<br class="gmail_msg"><br class="gmail_msg">I believe Tahoe is all yaml configuration files. Typically you overwrite those configuration files with mounts from the host machines. It would be nice to have the paths for config files that should be mounted from outside the image in the documentation.<br class="gmail_msg"><br class="gmail_msg">Depending on requirements you probably want a read/write mount where persistent storage is as well from the image.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">#Use cases.<br class="gmail_msg"><br class="gmail_msg">I have something in progress that feels like a potential Tahoe use case.<br class="gmail_msg"><br class="gmail_msg">Here is the shape it.<br><br>You have a deployment of many on premise server applications. Each isolated instance may need to create a shared scratch pad with many other servers. They use a cloud service to obtain the scratchpad. The scratchpad should only be accessible. The servers can choose which scratchpad to write to based on what other servers need.<br><br>I'm looking at a couple of different options for this. Galois has a thing called 





<p class="inbox-inbox-p1"><span class="inbox-inbox-s1"><a href="http://tozny.com">tozny.com</a>. There are messaging oriented crypto systems that might work like matrix.<br><br>But I do this Tahoe fits.</span></p><br><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Dec 13, 2016 at 12:16 PM Brian Warner <<a href="mailto:warner@lothar.com" class="gmail_msg" target="_blank">warner@lothar.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
Tahoe-LAFS devchat 13-Dec-2016<br class="gmail_msg">
<br class="gmail_msg">
* attendees: corbin, meejah, warner, exarkun, cypher<br class="gmail_msg">
<br class="gmail_msg">
Release stuff<br class="gmail_msg">
-------------<br class="gmail_msg">
<br class="gmail_msg">
I tagged beta1 last night. The plan is to tag the final 1.12.0 release<br class="gmail_msg">
next weekend.<br class="gmail_msg">
<br class="gmail_msg">
Docker: We automatically generate a Docker image with each commit, which<br class="gmail_msg">
makes it easier for folks (in Docker-capable environments) to run Tahoe<br class="gmail_msg">
without compiling anything. However the current image tries to keep all<br class="gmail_msg">
its NODEDIR state inside the container, which is not good Docker<br class="gmail_msg">
practice (containers are ephemeral, so it's easy to lose your rootcaps<br class="gmail_msg">
or stored shares). Exarkun will file some PRs to improve this, by<br class="gmail_msg">
keeping the state on the host filesystem (mounted by, but not living<br class="gmail_msg">
inside, the container).<br class="gmail_msg">
<br class="gmail_msg">
He'll also take a look at our DockerHub presence<br class="gmail_msg">
(<a href="https://hub.docker.com/r/tahoelafs/" rel="noreferrer" class="gmail_msg" target="_blank">https://hub.docker.com/r/tahoelafs/</a>) and make sure we're providing<br class="gmail_msg">
something useful.<br class="gmail_msg">
<br class="gmail_msg">
This might be aided by landing the PR for #2848, which adds arguments to<br class="gmail_msg">
"tahoe create-client" that sets the shares.needed/required/happy in the<br class="gmail_msg">
generated tahoe.cfg (as opposed to editing tahoe.cfg after node<br class="gmail_msg">
creation). It's kind of last-minute, but the PR is pretty small, so I<br class="gmail_msg">
think we can safely land it.<br class="gmail_msg">
<br class="gmail_msg">
OS-X: our buildbot creates OS-X .dmg packages with each commit (see<br class="gmail_msg">
<a href="https://tahoe-lafs.org/source/tahoe-lafs/tarballs/OS-X-packages/" rel="noreferrer" class="gmail_msg" target="_blank">https://tahoe-lafs.org/source/tahoe-lafs/tarballs/OS-X-packages/</a>), which<br class="gmail_msg">
put a binary in /usr/bin/tahoe (but maybe you need to be an admin to run<br class="gmail_msg">
it?). The package includes a .app application (with icon and stuff), but<br class="gmail_msg">
it doesn't actually do anything. So these "packages" aren't exactly<br class="gmail_msg">
useful.<br class="gmail_msg">
<br class="gmail_msg">
We're going to leave this builder in place for now and let it create a<br class="gmail_msg">
1.12 package, but then we'll dismantle it after 1.12 is done and replace<br class="gmail_msg">
it with cypher's "frozen binaries" tooling. He's got a buildbot<br class="gmail_msg">
(<a href="https://buildbot.gridsync.io/waterfall" rel="noreferrer" class="gmail_msg" target="_blank">https://buildbot.gridsync.io/waterfall</a>) which generates single-file<br class="gmail_msg">
executables for both OS-X and windows, which sounds like the preferred<br class="gmail_msg">
way to distribute Tahoe until we get a full real GUI application (which<br class="gmail_msg">
he is also working on). After 1.12 is done, we'll work to merge this<br class="gmail_msg">
buildbot in with our main one (#2729), possibly taking over the worker<br class="gmail_msg">
machines too (having the Tahoe org host them, instead of using Cypher's<br class="gmail_msg">
personal machines, and/or using our Appveyor config to build some). Then<br class="gmail_msg">
we'll distribute these executables on the main web site next to the<br class="gmail_msg">
source tarballs. We might also manually generate executables for 1.12<br class="gmail_msg">
and copy them into place.<br class="gmail_msg">
<br class="gmail_msg">
Windows: We've got no packaging changes for Windows: I think we're only<br class="gmail_msg">
offering "pip install" and some extra instructions. Post-1.12 we'll add<br class="gmail_msg">
frozen binaries.<br class="gmail_msg">
<br class="gmail_msg">
We need to remember to send the final release announcement to tor-dev,<br class="gmail_msg">
or maybe tor-talk, to let the Tor community know of our new integration<br class="gmail_msg">
features, and solicit feedback. We know of some Tor and I2P "community<br class="gmail_msg">
grids", and we need to make sure their maintainers know about the<br class="gmail_msg">
release, but they probably do already.<br class="gmail_msg">
<br class="gmail_msg">
We noticed that GitHub automatically generates source-tree tarballs (via<br class="gmail_msg">
"git archive"), and on other projects this sometimes causes confusion.<br class="gmail_msg">
We declared the signed sdist tarballs/wheels on PyPI to be the<br class="gmail_msg">
"official" release artifact, rather than GitHub's auto-tarballs. But our<br class="gmail_msg">
release checklist will include copying the official tarballs to GitHub's<br class="gmail_msg">
"releases" page, so anyone who sees the auto-tarball will also see the<br class="gmail_msg">
(signed) real tarballs, to reduce confusion.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Science!<br class="gmail_msg">
--------<br class="gmail_msg">
<br class="gmail_msg">
We talked about more "productized" deployments, catching Cypher and<br class="gmail_msg">
Corbin up on discussions we had at the Summit in November. Cypher is<br class="gmail_msg">
working on a deployable GUI as a Least Authority project, and Corbin is<br class="gmail_msg">
building a commercial service around Tahoe, so both are really<br class="gmail_msg">
interested in where we go with Accounting and node provisioning.<br class="gmail_msg">
<br class="gmail_msg">
Some use cases we discussed:<br class="gmail_msg">
<br class="gmail_msg">
* "enterprise" deployment: an admin decides on the storage servers<br class="gmail_msg">
  (local or cloud), pays for them, installs the server app. Later the<br class="gmail_msg">
  admin approves each new client and authorizes them to use the existing<br class="gmail_msg">
  servers. This wants enough Accounting for the admin to find abuse (or<br class="gmail_msg">
  cost-overruns) and enforce rough usage policies, but client machines<br class="gmail_msg">
  should not be directly paying for storage, and users should be unaware<br class="gmail_msg">
  of where the storage is held.<br class="gmail_msg">
<br class="gmail_msg">
* "friendnet": group of friends share locally-hosted space with each<br class="gmail_msg">
  other. No central admin, no payment, but enough Accounting for each<br class="gmail_msg">
  server node to know who is using space, how much, and to be to push<br class="gmail_msg">
  back (notify or suspend service) if someone uses too much. Wants more<br class="gmail_msg">
  "social" tools.<br class="gmail_msg">
<br class="gmail_msg">
* paid grid: individual client pays someone else for storage, either in<br class="gmail_msg">
  dollars or a cryptocurrency. Storage might be hosted directly by<br class="gmail_msg">
  provider, or backed by a commodity/cloud service, but client only<br class="gmail_msg">
  interacts with the provider (both for config and payment).<br class="gmail_msg">
<br class="gmail_msg">
Cypher's prototype uses a Magic-Wormhole -based provisioning flow:<br class="gmail_msg">
clients launch the app, which asks them to get a wormhole code from<br class="gmail_msg">
their admin. The payload delivered via this code provides the<br class="gmail_msg">
introducer.furl and encoding settings. In the future, this could also<br class="gmail_msg">
transfer pubkeys or certificates that authorize the new client to<br class="gmail_msg">
consume space on the storage servers (which might be locally-hosted<br class="gmail_msg">
machines, or cloud storage, but are under the control of the same<br class="gmail_msg">
admin).<br class="gmail_msg">
<br class="gmail_msg">
Corbin's work is likely to depend on a better Helper, to reduce cost and<br class="gmail_msg">
improve performance. We currently only have a Helper for immutable<br class="gmail_msg">
uploads, and it's been neglected for several years. In 2017 we hope to<br class="gmail_msg">
give some love to the Helper, adding the immutable-download side, and<br class="gmail_msg">
then their mutable counterparts.<br class="gmail_msg">
<br class="gmail_msg">
One interesting question is how storage authority should be handled: in<br class="gmail_msg">
one approach, all storage authority comes from the client, which<br class="gmail_msg">
delegates some small portion (restricted to a specific file, for a<br class="gmail_msg">
limited time) to the helper. In another approach, the Helper can pose as<br class="gmail_msg">
anyone they like, but notifies storage servers of the account label that<br class="gmail_msg">
should be applied to any shares being uploaded.<br class="gmail_msg">
<br class="gmail_msg">
At the Summit we discussed a "full agoric" approach, in which clients<br class="gmail_msg">
learn about servers from some sort of "yellowpages" directory, decide<br class="gmail_msg">
individually which ones they like, establish accounts with them, deposit<br class="gmail_msg">
some BTC to get started, and then upload shares. I still think that's a<br class="gmail_msg">
cool thing, but most of the use cases we looked at today wouldn't use it<br class="gmail_msg">
(they'd want more curated selection of storage servers, and in many of<br class="gmail_msg">
them the payment is coming from a central admin rather than individual<br class="gmail_msg">
clients).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Links<br class="gmail_msg">
-----<br class="gmail_msg">
<br class="gmail_msg">
#2848: <a href="https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2848" rel="noreferrer" class="gmail_msg" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2848</a><br class="gmail_msg">
#2729: <a href="https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2729" rel="noreferrer" class="gmail_msg" target="_blank">https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2729</a><br class="gmail_msg">
Magic-Wormhole: <a href="http://magic-wormhole.io/" rel="noreferrer" class="gmail_msg" target="_blank">http://magic-wormhole.io/</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
cheers,<br class="gmail_msg">
 -Brian<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
tahoe-dev mailing list<br class="gmail_msg">
<a href="mailto:tahoe-dev@tahoe-lafs.org" class="gmail_msg" target="_blank">tahoe-dev@tahoe-lafs.org</a><br class="gmail_msg">
<a href="https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br class="gmail_msg">
</blockquote></div></div>