Monthly status report, April 2013

More partnerships, bottlenecks resolved, repositories with bounties, and ideas matured.

EJTP

This was a slow month. Very little of the stuff we were planning to get done actually got done - partly from one unfinished renovation blocking everything else, and partly from general burnout for our high-volume contributors.

  • Fixed the hacks we were using to support Python 2.5, which we dropped support for being so old.
  • EJTP can now be installed via pip, including test suite support.
  • Test suite supports running specific tests now, for when you don’t want to run the whole suite.
  • Benchmarking utilities and performance improvements.

Version 0.9.5 will hopefully involve completing the big stuff that was slated for 0.9.4. Our biggest priority is finally getting #66 done.

CPS

Was completely overhauled this month. It’s a lost more modular, a lot better thought-out, and available via PyPI/pip. The API was broken in the process, but probably for the last time. The whole project is now correctly licensed as LGPL, set up with Tox and Travis-CI for testing, and has a new JSON file sink that will allow us to prototype and test DEJE document bootstrap without Kademlia support. The new modular system also made multi-encryptor-filtering a transparent and simple mechanism. The following stuff is planned:

  • Multiplexer filter, which allows seamless and simple caching (still not done).
  • Multiprocessing filter, for sending requests across process boundaries.
  • Conditional Twisted support, allowing you to run all your Twisted backends in the same process (if your project uses Twisted) or an external one via the multiprocessing filter.
  • Kademlia support via Entangled (Congress is just not mature enough to use).

While there aren’t any paid issues right now, I’m planning to delegate some of those features that way within the week.

DEJE

CPS is finally in a state where I’ve been able to get DEJE running in Python 2.6-3.3, working via Tox and Travis-CI, and ready for paid development. I have two issues open, one of which is vital to moving forward in the project.

In case you’re wondering if you’ve already seen those before, you probably haven’t. This is the official announcement that DEJE is now in paid development mode!

DJDNS should be able to move forward in primitive prototype-y ways as soon as #33 is done, but will likely inspire a fresh rash of paid development in DEJE. So look forward to that too.

Hardware design

Danry25 has become the hero of RI’s Hardware division. Not only is he now fully in charge of the guide repository - and doing a fantastic job, I might add - we’ve worked out a deal where he’ll be modifying OmniTIK routers with the POE mod, and I’ll be buying those from him at an appropriate markup. This works out for everyone perfectly! I’m not a hardware guy, and I don’t have the time or inclination to become one. And I’m happy to pay a great and trusted member of Project Meshnet to fill that role for me.

When I finally have some appropriate firmware to put on these, the actual process of assembling and flashing towers should go pretty fast. I have most of the parts I need, but I’m holding out for the last bits until I have ADRIS-T (the distro for RITowers) in a somewhat working state in VMs, which is currently a matter of developing a bunch of component parts like puppet-cjdns, puppet-openvpn, and the CVI Gateway.

Store and gateway

Not only made a lot of conceptual progress this month (weird as this sounds, I have a better layout of the API than what I want to call it, I’ve been in talks with a fellow called tdolsen, who will be working on his own CVI service on the same software stack, in parallel to me. This is fantastic news, because we’re going to be building and improving the same products, in exactly the sort of cooperative-competition way I’d always envisioned.

tdolsen is planning to help work on the Store API server, which will be separate from the HTML frontend. This distinction is much cooler than it sounds - it means that the same open source backend server can be used by any frontend, whether it’s a console client or a production HTTP server or the lightweight web-based config wizard that comes with RILink devices. Anyone can make a client for that common base, and anyone can run their own instance of the base software - an interoperability that can only come with open standards. The RI Store repository is going to be an RI-themed HTTP frontend to the API server. While I’m making the RI Store, tdolsen will be building the frontend for his business in more or less the same way, to communicate with the API software, and likely with the same CVI gateway software polling the API for service information.

For more information, read the Store Concepts on Google Docs. And please, for the love of god, someone give me some feedback on the name thing. It’s driving me insane.

General puppetization

I’m not going for anything absurdly fancy this month. I just want to retrofit my GNU Mediagoblin installation scripts to Puppet, and make it a standalone service, running on a separate VM and reverse proxied through nginx. The intention is to, piece by piece, break off the different services running on my primary VM until it’s a very minimal set of software, for security reasons. That way a compromise in one bit of experimental software doesn’t compromise every service running on roaming-initiative.com, or the main site that reverse-proxies all of it. If I can have all my primary traffic through a thin, secure VM, it will give me a lot of peace of mind, and make it much simpler to set up Travis-CI and VirtualBox testing for the individual services.

This will have the interesting side effect of testing out how to migrate a Mediagoblin installation from one machine to another. I expect to be simultaneously useful and annoying to their IRC channel toward the end of this process.