2013 10 01

      • danderson
        if you pass a custom lxc config to docker, I think preserving CAP_SYS_RESOURCE would let you set limits
      • (and also mess with various things in /proc, so root-equivalent in some ways)
      • dsal
        Can I launch it with a higher rlimit somehow?
      • josh-k has quit
      • bencaron joined the channel
      • danderson
        doesn't look like it
      • I don't even see that option in plain LXC
      • dsal
        It's a doc problem for me, then. 🙂
      • dsissitka is now known as dsissitka|away
      • Taldrain joined the channel
      • btubbs has quit
      • danderson
        no reason why it's theoretically impossible, immediately after entering the container the initial process still has full root capabilities
      • Dude-X joined the channel
      • stephenjudkins has quit
      • Taldrain has left the channel
      • dsissitka|away is now known as dsissitka
      • dsissitka
        dsal: https://groups.google.com/forum/#!topic/docker-... might be of some interest to you.
      • jayd3e has quit
      • jimt_ joined the channel
      • wyaeld has quit
      • vwoo_ joined the channel
      • sfz joined the channel
      • kklimonda joined the channel
      • BRMatt joined the channel
      • danderson
        so, is 0.7 going to have pluggable containerization, or is that deferred to later?
      • jimt has quit
      • shykes
        not in 0.7. The focus for this release is interconnection of containers, running on mainline kernels, and integration with process supervisors
      • there is a branch for adding libvirt as an execution backend
      • nathanstitt joined the channel
      • so I'm tentatively going to put it in the 0.8 window
      • dsal
        dsissitka: Thanks. I do want to stay kind of vanilla. Telling people to restart their dockers would be unfortunate.
      • dsissitka
        Just curious, was device-mapper implemented via plugin?
      • danderson
        shykes: thanks.
      • shykes
        dsissitka: no, it started out as a branch to inform the development of the plugin
      • kklimonda_ has quit
      • half-way through we realized it made more sense to merge it in as the default
      • since getting docker to run on mainline kernels is more urgent than plugins
      • bodna007 has quit
      • danderson
        I ask because I just found my container.c, a tiny implementation of lxc-start that only depends on the kernel
      • the day container plugins happen, I'd kinda like to hook it up and use it (assuming it still actually works)
      • shykes
        separately from plugins, there's also the question of what to use as the default for containerization
      • shelling out to lxc-start is not ideal
      • danderson
        is the desire still to have something as lightweight as LXC?
      • dsissitka
        So what are the big features of 0.7? I believe there's device-mapper, getopt, host integration, links.
      • danderson
        or are we talking switching to VMs?
      • rdw200169 joined the channel
      • shykes
        dsissitka: links, host integration, mainline kernel support (via device-mapper)
      • danderson
        unfortunately, starting the container isn't implementable in Go, because the requisite occult syscall dance completely messes up anything multithreaded
      • digitalsanctum has quit
      • dsissitka
        Can't wait. 😀
      • shykes
        danderson: that can be worked around with some C and appropriate synchronization around it
      • tongueroo has quit
      • but it makes it slightly less trivial for sure
      • georgebashi has quit
      • danderson
        shykes: iirc, the problem at the time was entering the namespaces. Some of them you could only enter through clone(), at which point you've lost all other threads, and the Go runtime brains itself
      • JamieH has quit
      • proppy has quit
      • `3rdEden has quit
      • shykes
        danderson: I think the main problem is the codepath between fork() and clone()
      • danderson
        that said, it seems all namespaces can now be unshare()d, so that might solve that
      • mdxprograms joined the channel
      • aanand has quit
      • ultramur_ has quit
      • akipp has quit
      • ultramurph joined the channel
      • oh, actually, no. Seems you can't unshare the I/O namespace
      • nexxy
        hypothetically speakingl; if I were to attempt to start a container that was built/configured with docker, could I do so with just lxc?
      • jaytaylor has quit
      • neomindryan joined the channel
      • keeb
        nexxy: sure
      • bfirsh has quit
      • nexxy
        keeb, sweet! I don't suppose you have any pointers for me? 😀 #lazyweb
      • keeb
        nexxy: start a container through docker, then `ps -ef | grep lxc-attach`
      • there's the command line that was run
      • nexxy
        keeb, so good. thank you very much!
      • keeb
        the problem is, there's a lot you don't get via that approach, mainly networking
      • io_syl joined the channel
      • nexxy
      • that might be a problem
      • danderson
        shykes: what's the problem between fork() and clone() ?
      • keeb
        but it's a good jump off point
      • lerc joined the channel
      • nexxy
      • the other alternative would be
      • possibly
      • figuring out when/if those "don't use in production" warnings will go away ;3
      • danderson
        looking at my code, the tricky bit was adding the cloned child to cgroups before letting it fork further, which a simple signalling pipe fixed just fine
      • acrocity joined the channel
      • ultramurph has quit
      • mdxprograms has left the channel
      • stoned75 joined the channel
      • rgbkrk has quit
      • rdw200169 has quit
      • Dude-X has quit
      • cookednoodles has quit
      • shykes
        danderson: I mean in Go. You simply can't Fork() (or Clone) safely, which is why it is not exposed in the stdlib
      • kaspergrubbe joined the channel
      • jipiboily joined the channel
      • rgbkrk joined the channel
      • unbracketed has quit
      • crashsystems has quit
      • stoned75 has quit
      • jaytaylor joined the channel
      • kaspergrubbe has quit
      • asmyers joined the channel
      • Joel_re_ joined the channel
      • danderson
        shykes: right. I should add that my problem was that I was trying to assume nothing about the files in the container, so the containerizing binary did everything, rather than exec some other helper
      • that complicates things a little bit. If I did something like docker and added a sysinit helper in the container, probably most of it could be go, except for the clone+exec
      • and that can be a trivial C or asm binding
      • Joel_re has quit
      • mramm has quit
      • qwerty_nor joined the channel
      • svenfuch_ joined the channel
      • mramm joined the channel
      • svenfuchs has quit
      • zz_jpetazzo is now known as jpetazzo
      • MattJ has quit
      • petejkim has quit
      • redbeard2 joined the channel
      • miquella joined the channel
      • groundwater has quit
      • miquella_ joined the channel
      • smw_ joined the channel
      • josephho_ joined the channel
      • josephholsten has quit
      • tylerstalder has quit
      • tylerstalder joined the channel
      • bencaron has quit
      • miquella has quit
      • crosbymichael is now known as zz_crosbymichael
      • mattapperson has quit
      • mattapperson joined the channel
      • vieux is now known as zz_vieux
      • BRMatt has quit
      • mattapperson has quit
      • sfz has quit
      • c4milo has quit
      • Symian joined the channel
      • mihasya has quit
      • Dude-X joined the channel
      • garrettux joined the channel
      • dysinger joined the channel
      • loladiro has quit
      • garrettux has quit
      • vcoisne has quit
      • btubbs joined the channel
      • robbyt joined the channel
      • jfoy has quit
      • jayd3e joined the channel
      • btubbs has quit