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 <cl...@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). 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... > To the container makers: consider that things can and will go wrong, > and the answer may already exist as a traditional tool, and not be > "restart the container". > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- - Gus _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
