Open Stack

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 <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).
> > 
> > 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