[Tools-implementation] Revisiting whether we should continue using Docker as we currently do.

[Robert Sparks <[e-mail]>]

A few weeks ago, shortly after the yc.o team's work managed to crash the 
host they were working on through changing settings in a container, I 
proposed that we unroll the things we currently have in containers on 
production. At the time, Glen suggested we not do that. I'd like to ask 
the question again - I think we may have more to consider.

1. I remain uneasy about docker's implementation on OpenSuse. The 
container crash above, the issues we've run into with containers locking 
(and sometimes causing processes talking to them like apache) to hang 
are suspicious. That we've not been able to pin down what's really going 
on suggests to me the issue is in a place we can't really look, inside 
docker's interstitial networking or filesystem abstraction code perhaps.

2. Many of the containers we have (and in particular the one for the 
website) really need to be designed differently if they are going to 
remain deployed as containers. The amount of file-system mapping they do 
is not what the docker architects expect as a normal use-case. Mapping 
sockets in the way we do is also likely not something they focus on testing.

3. Docker is making Glen uncomfortable and the benefit for him 
(operationally) of the containerization is not proportional to the extra 
problems it is bringing.

So I again suggest that we unroll for the production deploys, at least 
for now. I think we can unroll everything at this point, but there might 
still be a hitch in unrolling the trac instances. Henrik - could you 
remind me what our thinking was with respect to those?

I do plan to keep up the pressure to have containerized versions of 
these services - this isn't a call to abandon Docker - but I suggest we 
need to change how we're currently using it.

RjS