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!
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.
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 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.
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.
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
support for etcd v0.4.6
support for Ubuntu 14.04 LTS including an updated slug base image
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.
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.
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.