On Wed, 15 Oct 2014 09:02:03 PM Jay Pipes wrote: > On 10/15/2014 08:30 PM, Angus Lees wrote: > > 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... > > Actually, I'm learning quite a bit from the back and forth on the > mailing list. And I'm not keen to try and find a local "devops/docker" > meetup in Sarasota, Florida. ;) Hipsters and bad enough. Hip > replacements are another thing altogether. > > Also, the implication that anyone asking questions or disagreeing here > hasn't "gone and read the docs" is kinda annoying. There's absolutely > nothing wrong with asking questions on this mailing list.
Yeah, sorry I didn't mean to stifle questions, only to point out that "make statement, have statement corrected" works much better in concert with some structured learning material and using a lower-latency medium. If you'd prefer to continue as an email discussion, then we should continue. -- - Gus _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
