Open Stack

Excerpts from Angus Lees's message of 2014-10-15 17:30:52 -0700:
> On Wed, 15 Oct 2014 09:51:03 AM Clint Byrum wrote:
> > Excerpts from Vishvananda Ishaya's message of 2014-10-15 07:52:34 -0700:
> > > On Oct 14, 2014, at 1:12 PM, Clint Byrum <clint at fewbar.com> wrote:
> > > > Excerpts from Lars Kellogg-Stedman's message of 2014-10-14 12:50:48 
> -0700:
> > > >> On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:
> > > >>> I think the above strategy is spot on. Unfortunately, that's not how
> > > >>> the
> > > >>> Docker ecosystem works.
> > > >> 
> > > >> I'm not sure I agree here, but again nobody is forcing you to use this
> > > >> tool.
> > > >> 
> > > >>> operating system that the image is built for. I see you didn't respond
> > > >>> to my point that in your openstack-containers environment, you end up
> > > >>> with Debian *and* Fedora images, since you use the "official" MySQL
> > > >>> dockerhub image. And therefore you will end up needing to know
> > > >>> sysadmin specifics (such as how network interfaces are set up) on
> > > >>> multiple operating system distributions.> >> 
> > > >> I missed that part, but ideally you don't *care* about the
> > > >> distribution in use.  All you care about is the application.  Your
> > > >> container environment (docker itself, or maybe a higher level
> > > >> abstraction) sets up networking for you, and away you go.
> > > >> 
> > > >> If you have to perform system administration tasks inside your
> > > >> containers, my general feeling is that something is wrong.
> > > > 
> > > > Speaking as a curmudgeon ops guy from "back in the day".. the reason
> > > > I choose the OS I do is precisely because it helps me _when something
> > > > is wrong_. And the best way an OS can help me is to provide excellent
> > > > debugging tools, and otherwise move out of the way.
> > > > 
> > > > When something _is_ wrong and I want to attach GDB to mysqld in said
> > > > container, I could build a new container with debugging tools installed,
> > > > but that may lose the very system state that I'm debugging. So I need to
> > > > run things inside the container like apt-get or yum to install GDB.. and
> > > > at some point you start to realize that having a whole OS is actually a
> > > > good thing even if it means needing to think about a few more things up
> > > > front, such as "which OS will I use?" and "what tools do I need
> > > > installed
> > > > in my containers?"
> > > > 
> > > > What I mean to say is, just grabbing off the shelf has unstated
> > > > consequences.
> > > 
> > > If this is how people are going to use and think about containers, I would
> > > submit they are a huge waste of time. The performance value they offer is
> > > dramatically outweighed by the flexibilty and existing tooling that exists
> > > for virtual machines. As I state in my blog post[1] if we really want to
> > > get value from containers, we must convert to the single application per
> > > container view. This means having standard ways of doing the above either
> > > on the host machine or in a debugging container that is as easy (or
> > > easier)
> > > than the workflow you mention. There are not good ways to do this yet, and
> > > the community hand-waves it away, saying things like, "well you could …”.
> > > You could isn’t good enough. The result is that a lot of people that are
> > > using containers today are doing fat containers with a full os.
> > 
> > I think we really agree.
> > 
> > What the container universe hasn't worked out is all the stuff that the
> > distros have worked out for a long time now: consistency.
> > 
> > I think it would be a good idea for containers' filesystem contents to
> > be a whole distro. What's at question in this thread is what should be
> > running. If we can just chroot into the container's FS and run apt-get/yum
> > install our tools, and then nsenter and attach to the running process,
> > then huzzah: I think we have best of both worlds.
> 
> Erm, yes that's exactly what you can do with containers (docker, lxc, and 
> presumably any other use of containers with a private/ephemeral filesystem).
> 

The point I was trying to make is that this case was not being addressed
by the "don't run init in a container" crowd. I am in that crowd, and
thus, wanted to make the point: this is how I think it will work when
I do finally get around to trying containers for a real workload.

> To others here:
> 
> There's a lot of strongly-held opinions being expressed on this thread, and a 
> number of them appear to be based on misinformation or a lack of understanding 
> of the technology and goals.  I'm happy to talk over IRC/VC/whatever to anyone 
> about why I think this sort of stuff is worth pursuing (and I assume there are 
> plenty of others too).  I'd also suggest reading docs and/or in-person at your 
> local docker/devops meetup would be a more efficient method of learning rather 
> than this to-and-fro on the os-dev mailing list...
> 

I think you may have been mistaken about the purpose of this list. It is
for openstack developers to discuss exactly the things you're talking
about not discussing on this list. You've done a great job of helping us
clear these things up. Don't turn around and tell us "now don't ever do
that again." just as we're about to understand. ;)