Is Docker 0.9.1 "good enough"?

Rationale:

https://meta.discourse.org/t/how-to-update-to-discourse-1-0/19328/34?u=codinghorror

I was very disturbed to read this, and we officially tell people they should be on Docker 1.2.0 – but I don’t have enough technical knowledge about Docker to refute his position here.

Is Docker 0.9.1 “good enough” and bug / weirdness free enough to be supported for a long time? My gut says no, but this particular user is convinced.

What say you?

I agree that its disturbing. v0.9.1 was late March, 3 months before v1.0.0.

There have been numerous improvements to security and performance since then.

The fact that Dan hasn’t noticed any issues in v0.9.1 is one of those negative proofs - I’m not sure what value there is in that :/.

I bet we can find people that haven’t noticed any problems with their 2001 openSSL release - or still use Win95.

2 Likes

Hey guys. I’d like to contribute to this discussion, at least to raise my own concerns, and to point out that it’s not stubbornness holding me back. :slight_smile:

Being a fan of Docker from an early point, it has seen implementation into QA testing and experimentation in my place of work. It is already being considered for Production use, however this is when things get into the ‘stable’ argument.

What is stable?

As much as I hate the argument, stable seems to many companies to be “something that’s been around for a long time that isn’t completely broken, or at least has an expected failure rate”. I could give examples here of broken SNMP implementations, Perl4, etc. but the long and short of it is, we started with Docker 0.8, we’ll die with Docker 0.8.

More reasonable people that don’t live in denial might go for ‘vendor stable’. I think of this as “this set of software is the most tested with the rest”. I do not think it is more likely to work, and certainly not likely to be more bug free (no matter how much effort goes into backporting, that magical curse that makes the software even less tested than it’s bleeding edge counterpart)


My problems are not with Docker, or with each subsequent release my company feels the need to fully regression test each component, but that Ubuntu settled on v0.9.1. This has led to some people taking the line that 0.9.1 is a version that will be around for a long time, that it is ‘supported’, therefore it must be more stable. This affects people like

  • myself, who wants to spend less time running the servers/deployment and more time using the forum (discourse)
  • docker hosting services, where an expected failure rate and predictability are more important than new features

The only way I see this changing is if a subsequent point release of Ubuntu upgrades the Docker version that it ships with.

The thing I am especially struggling with here is that 0.9.x was always labeled not production ready

We used it cause we had no choice, there was no production ready Docker at the time.

Now, the argument that we should also support 1.0 is a bit stronger, but the 1.0 release had a few serious issues same goes for 1.0.1 and so on.

1.2 is by far the best Docker out there and a version I am comfortable “blessing” for our Docker installs, the restart policies are really a must for us given the way we depend on docker run -d

In say 3 years time I will be much more comfortable going with an old version of Docker (that has backported security fixes) but as of now I think it is far wiser to go with the stable edge.

I do wonder what @solomon thinks about all of this.

Trusty is getting 1.0.1 “soon”.

I think this viewpoint misses an important detail - the docker.io package comes from Universe which means:

Universe - Community maintained software, i.e. not officially supported software.

it isn’t actually in the spectrum of packages with the LTS guarantee. It’ll have updates (as proposed by the community) but there’s no promise as to API stability, etc.

It’s a shame people are not willing to move on to the v1.x just because ‘hey, 0.9 is easier to install and is “stable enough”, so why bother?’. Especially when installing the latest version is just a matter of downloading the binary via curl (it’s a single command as well if you use the script).
I used the pre-packaged version for a while, but upgrading to the latest was an easy decision, dictated by the great amount of ‘Fixed in 1.x.x’ posts I’d find when looking for solutions to various bugs

This is really important.

We are currently setting up a policy for update cadence, and are working with partners to keep the technology up to date downstream, or we will have to carry upstream.

More to be announced, but Canonical in particular has been very receptive to this. I would recommend at least 1.0.1, given it has the production ready moniker + fixes some major packaging issues with 0.9

1 Like