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

One of the reasons that we went to containers was to isolate some python2 from python3.  Will we just use virtual environment for that?

Russ

> On Sep 9, 2020, at 12:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
> 
> 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
> 
> 
> -- 
> Tools-implementation mailing list
> Tools-implementation@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-implementation