Flynn Progress: Week Ending Nov. 9, 2014

Last week was all about our primary goal: making Flynn stable.

As always, we are continuing to close issues, but we want to make it easier for you to follow along with our progress. So we are working towards a release mechanism for nightly builds. We plan to ship that next week!

§ Changes

§ Notable Enhancements

§ Major Bugs Fixed

  • Job errors are propagated via the attach protocol and container setup errors are properly handled. (#406)
  • Intermittent container EBADF failures. (#402)
  • PHP HHVM support. (#365)

§ What’s Next

Flynn is moving towards production stability at a consistent pace. We expect to have nightly builds available next week. We continue to work hard on improving our test suite, documentation, and stability.

§ Stay in Touch

Scary How Much We Fixed Last Week!

We made another major docs push to Flynn this week. We’ve started our How to Deploy series with the most-requested languages from the community.

We also pushed a major feature (custom builds) and solved some annoying bugs–PHP support is fixed! As always, we are continuing to close issues and make Flynn more stable.

§ Changes

§ New Documentation

We’ve launched a series of Language Guides to help you deploy your favorite language to Flynn:

§ Notable Enhancements

  • We’ve added support for releasing custom builds. This allows you to customize Flynn and test it out on your servers without merging your changes upstream first. We’ve expanded our Development Documentation to walk you through these improvements.
  • We re-wrote the log handler to improve reliability.
  • We updated to Go 1.4beta1 to improve reliability and security. This may also improve performance as development continues.

§ Major Bugs Fixed

  • Fixed PHP support (#360)
  • Fixed log decoding crash (#92)
  • Fixed build dependency tracking (#374)

§ What’s Next

Flynn is moving towards production stability at a consistent pace. We continue to work hard on improving our test suite, documentation, and stability.

§ Stay in Touch

Recently in Flynn

We’re starting to report regularly on changes and new features in Flynn.

Flynn is a big project that spans a wide section of technology which makes it hard to tell what’s new when you visit the website or GitHub repo. Posts like this will condense the most recent news so you can see what’s happening without diving deep into the code.

If you have questions, suggestions, or other issues that aren’t addressed here, we want to know about them! Please share through IRC, GitHub, or email.

§ Summary

Our focus continues to be stability for core features (rather than adding new ones). Since the beta release this summer we’ve been hard at work fixing bugs, writing tests, and making Flynn easier to use.

§ Changes

§ New Documentation

§ Notable Enhancements

  • Add subcommands to the flynn-host binary (#181)
  • Add utility for uploading debug info (#233)
  • Add app delete command to CLI (#214)
  • Allow overriding entrypoint in flynn run (#193)
  • Scale apps to web=1 on first push (#208)
  • Add support for wildcard routes (#281)

§ Major Bugs Fixed

  • Blobstore transaction status idle (#101)
  • Various etcd usage issues (#39, #48, #76, #187)

§ Summary

We’ve closed over 280 issues and pull requests and made over 440 commits since the beta release.

§ What’s Next

Flynn is moving towards production stability at a consistent pace.

In addition to stability improvements, expect Flynn to become easier to use, install, and understand.

Flynn Beta

Flynn is now in beta.

This release represents over a year of design and development and is the last stage before production release candidates begin shipping.

The first beta release includes:

  • a pluggable containerization backend with support for Red Hat’s libvirt-lxc and Docker 1.1
  • deterministic releases using image IDs (currently libvirt only)
  • flap detection in the controller scheduler
  • multi-node support
  • support for etcd v0.4.6
  • support for Ubuntu 14.04 LTS including an updated slug base image
  • deployment instructions
  • and numerous bug fixes for all major components.

This release also ships as a single repo for the first time. Components are still modular, but everything is located at

Now is an excellent time to set up a Flynn cluster for development, testing, and staging environments. We need your help to find bugs and discover edge cases so we can expand the test suite and improve the system.

Development is still in a feature freeze until the planned production-ready release this fall. With the exception of the appliance framework, no new features will be added until the first production stability release candidate.

Thank you for your continued support and enthusiasm.

— The Flynn Team

Container Independence

One of our highest priorities is modularity.

We are pleased to announce Pinkerton, a tool for using Docker images with other container runners.

Users should have complete control over their dependencies and environments. Many users have experimented with Docker’s initial iteration, but we believe the story of containers, which began over a decade ago with FreeBSD jails and Solaris zones, remains in its infancy. Docker, Inc. introduced many web developers to containers, first through LXC, and powered more recently by Docker, Inc’s own libcontainer.

Many projects in this space are moving quickly, turning compatibility and stability into great challenges, especially for projects that push the limits of these tools, like Flynn.

We have run into more than our share of problems with all of our dependencies, including Docker, which has caused us to redouble our commitment to interoperability and modularity.

Our users should not be tied to Docker, Inc. or any other company.

Pinkerton guarantees container independence permanently.

We are hard at work switching Flynn’s container runner to leverage more mature container solutions that guarantee operators the reliability, stability, and performance in production that we demand and users require of all our dependencies.

We have more to say about container runners, stability, and performance (backed by extensive benchmarks and tests). We are evaluating both Red Hat’s libvirt and Google’s lmctfy, which are used by the industry’s most demanding users in production at companies like Google and projects like OpenStack.

We will provide you with the greatest possible stability in production. Our commitment to this is unwavering.

Initially, Flynn’s container runner was one of the few components that did not support user-swappability out of the box. Correcting this is currently our highest development priority and a necessity for production stability. Alternative runners are already in development on GitHub.

We expect to announce Flynn Beta, suitable for internal services and non-production traffic in the next several weeks. Flynn 1.0 will follow by the end of the summer. Flynn will be the most reliable tool you use.

We look forward to exceeding your expectations.

Because of your support, Flynn will be the single tool that solves ops. Thank you as always for your continued support, enthusiasm, and interest.

–The Flynn Team

p.s. We are in the San Francisco Bay Area for the summer and available to discuss the particular needs of users until the end of August. Let us know if you’d like to meet.


Mailing List