#docker-dev

/

      • titanous has quit
      • docker_bot joined the channel
      • docker_bot has quit
      • pblittle has quit
      • jeckersb is now known as jeckersb_gone
      • shykes
        joffrey: thanks!
      • gigetoo has quit
      • gigetoo joined the channel
      • ghostbar joined the channel
      • ghostbar_ has quit
      • proppy
        so, I thought about netns the other day
      • my understanding is that docker create one per container
      • is that right?
      • paultag: if you don't come, I will hunt you down
      • paultag: I can locate you as long as you wear your glasses
      • paultag
        :)
      • I want to
      • I really do
      • dockerbot joined the channel
      • dockerbot
        [docker] creack opened pull request #4395: Make the chan for utils.Go buffered in order to avoid goroutine leak (master...remove_goroutine_leak_test) http://git.io/_GlUow
      • dockerbot has left the channel
      • tianon
        yessir, he's a googler, he's scary
      • paultag
        I have a talk that saturday
      • proppy
        paultag: no: you *have* to
      • paultag: they are flying you back, that's cool
      • paultag
        I'm ultra tempted, really
      • proppy
        so it's not even the same day
      • paultag
        I've not said no yet, and I'm trying to work out logistics
      • proppy
        paultag: just book that plan already
      • so about netns
      • paultag
        :>
      • proppy
        would it make sense to have a way for 2 process to share the same netns?
      • s/process/container
      • would that means that 127.0.0.1 is the same for both?
      • or does that don't make any sense, and I should go back reading man netns
      • ?
      • crosbymichael joined the channel
      • shykes
        SO CLOSE
      • proppy: yes
      • it makes sense and yes I think that would be the resutl
      • what you can do is have a single process open sockets in N different namespaces
      • provided it has permissions to join the namespaces (and the kernel is recent enough to allow getting a hold of that fd)
      • then you could accept() / connect() to your heart content
      • the trick is that a process can only be part of 1 netns *at a time*, but can keep file descriptors created while in a netns even after it has joined another
      • if that makes sense
      • nick_schuich has quit
      • jpetazzo
        proppy: yes, that makes sense, and my friends at Yandex asked if we were considering that feature; if I remember well, to allow multiple containers to share a physical interface (to shave off a few cpu cycles of some critical paths)
      • proppy
        Yes and also to have some kind of -link for dummy
      • So you can just say this php frontend this mysql server and this reds share the same ns
      • And connect to 127.0.0.1 as you would do it naively in a single node
      • buckaroo joined the channel
      • crosbymichael has quit
      • I wonder what the UI could looks like
      • docker run -netns foo ?
      • With a get or create on the namespace
      • shykes
        proppy: that requires configuring your services to connect on localhost right?
      • proppy
        And maybe some dumb ref counting
      • shykes
        I think it's fine to have a way to adapt to existing applications which already connect to localhost on a hardcoded port
      • but in practice, it's not like all your applications all already configured this way
      • buckaroo has quit
      • you typically have a hodge podge of different methods
      • proppy
        shykes: a lot of people have apps and db collocated and single homed
      • Sure it doesn't scale but it does the work ;)
      • I think that's also interesting for the ambassador pattern
      • pmorie has quit
      • Since he container is just an encapsulation of a remote endpoint
      • buckaroo joined the channel
      • It sounds more dynamic than env var too
      • As container can comes and go in the same netns
      • shykes
        proppy: yes they are single homed but what does their code currently do for service discovery
      • proppy
        It has some limitations too, that would not be great for running multiple copy of the same image
      • shykes: mysql_connect('127.0.0.1:3306');
      • Its really similar to the jumper stuff
      • Just without the proxy
      • I wonder what the impact on the codebase would be
      • apow has quit
      • Maybe it could just be a flag with a nsname
      • That override the container namespace creation on run
      • shykes
        proppy: all your apps connecting to mysql currently use 127.0.0.1:3306?
      • apow joined the channel
      • proppy
        And the little ones are in bed ;)
      • shykes
        proppy: you still need a proxy in some cases, because of port conflicts
      • ie you want 2 databases
      • proppy
        shykes: most of the sample apps I look at yes
      • pmorie joined the channel
      • shykes
        I think we should support apps which already connect to 127.0.0.1 (or any other hardcoded IP), but we should not encourage it as a standard method of service discovery
      • because it doesn't work in many use cases
      • proppy
        Yes it all fall down when you have multiple local replica of the same logical container
      • vieux has quit
      • buckaroo has quit
      • shykes: I'm interested into the simple blog running on nodejs+mongo+redis, or php+mysql+memcache for example
      • proppy: Or just a prototype app,
      • I'd be great if it was just working
      • nick_schuch joined the channel
      • As people are used to when they develop on their bare VMs or laptop
      • vieux joined the channel
      • Maybe some tooling around docker could do the magic
      • But docker would just have to give you the named network namespace option
      • And the default would still be to create a new one per container
      • Gtg
      • arothfusz has quit
      • dockerbot joined the channel
      • dockerbot
        [docker] kzys opened pull request #4397: Add FreeBSD client support by reusing the work for OS X (master...darwin-bsd) http://git.io/0EoE6Q
      • dockerbot has left the channel
      • buckaroo joined the channel
      • vieux has quit
      • nick|lunch joined the channel
      • nick_schuch has quit
      • vieux joined the channel
      • joffrey has quit
      • buckaroo has quit
      • vieux is now known as zz_vieux
      • rasputnik has quit
      • jlhawn is now known as zz_jlhawn
      • thatcher is now known as zz_thatcher
      • rogaha has quit
      • steeve has quit
      • steeve joined the channel
      • crosbymichael joined the channel
      • pblittle joined the channel
      • jpetazzo is now known as zz_jpetazzo
      • julim has quit
      • pmorie has quit
      • michaelfavia joined the channel
      • michaelfavia has quit
      • kraman has quit
      • kraman joined the channel
      • enos joined the channel
      • enos has quit
      • 5EXAAPTXO has quit
      • jpoimboe is now known as jpoimboe_away
      • whenry joined the channel
      • pblittle has quit
      • lsm5_
      • whenry has quit
      • tianon
        yes?
      • lsm5_
        tianon: wondering about merge status/ETA for that :)
      • tianon
        heh, I have no idea :)
      • lsm5_
        tianon: aah nvm :)
      • tianon
        I think creack and crosbymichael are trying to make sure the basic libcontainer implementation is good before they venture into systemd
      • lsm5_
        ack
      • ghostbar_ joined the channel
      • kylemathews joined the channel
      • whenry joined the channel
      • kylemathews has quit
      • ghostbar has quit
      • dockerbot joined the channel
      • dockerbot
        [docker] philips opened pull request #4398: fix(api): serve until the "acceptconnections" job (master...fix-socket-activation) http://git.io/LNe99Q
      • dockerbot has left the channel
      • ghostbar_ has quit