#docker-dev

I think you should also spare a second or two for nasrat's 2409 ;)

because right now, Ghost containers become unrestartable after being stopped

It may still need work. Some pointers to intent of Ghost welcome. AIUI for reparenting existing list containers

[docker] tianon force-pushed enable_sigproxy_default from af67913 to 02d93c5: http://git.io/ZRqgPg

docker/enable_sigproxy_default 02d93c5 Victor Vieux: Enable sig-proxy by default in run and attach

[docker] scottbessler opened pull request #2431: Expose {NAME}_IP env variable when linking, Closes #2430 (master...2430-links-ip-env) http://git.io/1MAS4A

:o hack/PACKAGERS.md doesn't mention libsqlite3!

for either building or for runtime

which it's technically building, but possibly runtime depending on compilation method

tianon: good catch

let's make it a build dependency

hey, that's what packagers relations is for, right? :)

it's implicit that if you're building dynamically, all lib dependencies will be required at runtime also

:

:)

true :)

do we have an explicit known minimum version?

no... I would tentatively put the latest stable release

lol ok :)

If that causes problems for a distro, we will figure out a solution

and by that you mean walk backwards until everyone is happy? :)

but sqlite3 is famous for its reliability, so I think using its latest stable release is a good bet

sounds good to me

I would say walk backwards until nobody can reasonably argue that they are unhappy

as a hack maintainer - lemme check real fast as PR :)

latest sqlite stable is 3.8.1, latest Gentoo stable is 3.7.17, wheezy is at 3.7.13, precise is at 3.7.9

f18 is at 3.7.13, f19/f20 are at 3.8.0

[docker] SvenDowideit opened pull request #2432: IRC: add SIGTERM and SIGKILL details to docker stop and kill docco (master...doc-stop-kill-details) http://git.io/L9Dw9A

nice

how old is 3.7.9?

well iOS 6 and 7 ship 3.7.13

and ios 5 ships 3.7.7

SQLite Release 3.7.9 On 2011-11-01

so I think 3.7.9 will be fine :)

SQLite Release 3.7.7 On 2011-06-24

:)

it seems like some of my changes to hack/PACKAGERS.md got lost somewhere on the way to master

I'm gonna have to dig a little, because I know I've fixed some of these inconsistencies somewhere :P

maybe in one of the rc branches?

or md?

dm

if it's dm you're safe, they will get merged eventually

yeah, I'm checking that now :)

if it's rc, make sure you save them, those are dead ends

tianon: git never lies

looks like they were in DM somehow :)

maybe you just think you did

oh, I so did, just not in links :)

crosbymichael, re 2431 i responded. we can talk here or there, whichever is more appropriate :)

here is fine

am i missing an obvious way to extract IP from the proto://ip:port env variable? regex works, but seems like it could be a common enough use case to make easier

parsing tcp://192.168.1.1:8080 is not very hard

yeah, in the situations i've wanted linking i've only needed the ip, so thought it would be a helpful addition

er, IP="${ADDR#tcp://}%%"; IP="${IP%%:*}"

because networking will be locked down to only the exposed ports

i also hope to see more client libs built for link support like what i did here https://github.com/crosbymichael/docker-py/blob...

so that applications just have to add something like this https://github.com/crosbymichael/docker-links-b...

we could write a few bash functions that can parse the addr

sure, but even in the example in the PR they first echo it out and then use just the ip to connect https://github.com/dotcloud/docker/pull/1907

[docker] tianon opened pull request #2433: Add SQLite dep to hack/PACKAGERS.md (master...sqlite-dep) http://git.io/r94d-A

that one's all on you, shykes ;)

if not adding name_IP i'd suggest at least adding an example with the working parsing example above, i cant imagine it wont be a common use case

tianon even messed it up first try, i can imagine inconsistent and possibly broken ways that people will do that

indeed, and my second try is even messed up a bit ;)

let me try to write some bash functions thatyou can source

tianon already appended to the PR

but isn't everyone gonna just add those to start up scripts all over the place?

humm

shykes: for the record, all these deleted lines make me one happy_panda -> https://github.com/tianon/docker-overlay/commit... :D

building docker outside docker for packaging is now easier than ever :D

and by easier, I include cleaner, because that Makefile was really heinous :D

next step: dynbinary for everyone

[o__o]: m tianon

[o__o]: !m tianon

You're doing good work, tianon!

dynbinary for everyone?

what 8|?

just a guess

shykes: are you finally giving up and letting everyone have a dynamic binary?

I suspect we'll get tired of supporting 2 different builds

I'm getting there... slowly...

I only see benefit for packaging, for what that's worth :P

those silly packagers

I think at the end of the day, the priority is quality adoption: make it easier for more people to have a quality installation of docker

shykes: I've realized something we didn't think about in our dynbinary "wrong dockerinit" error message

and by realized, I mean come across in my actual usage

it shouldn't be unexpected, but it can be surprising

whatever method gets quality builds of docker installed on more machines, consistently, gets my vote.

tianon: what's that?

if I have docker running with its sha1-paired dockerinit, and docker run is working like a charm, then if I ever update docker without restarting docker (ie, my dockerinit gets replaced and my docker gets replaced, but the running docker does not), I run into the error message and it seems nonintuitive because it claims my docker is compiled incorrectly

even just recompiling runs into that, because dockerinit doesn't recompile deterministically

so our sha1 changes, but the running docker doesn't necessarily

this is especially important on systems like Gentoo, where init stuff is all 100% manual, and the packager doesn't touch the running system except to update packages/files

but relevant anywhere init stuff is handled manually

or via a separate process

my only idea to solve it is that instead of bind-mounting the dockerinit directly from where it's at, we open it at docker start and bind-mount the opened file handle (like we do with docker itself via /proc)

scottbessler_: I'm still thinking

but that feels wrong and dirty

as does any manual touching of /proc

imo

[docker] hamo opened pull request #2434: rewrite protocol check with switch-case in daemon (master...unlink_err_v2) http://git.io/x4359Q

tianon: can we not use a shell script for dockerinit? i was not part of that discussion so I don't remember

[docker] hamo closed pull request #2388: check error when unlink unix socket file (master...unlink_err) http://git.io/rkIuOg

we could've before, but now that we use netlink instead of "ip" we can't

damnit

which is a major boon to images, since we no longer require /bin/ip hard-coded in every base image

shell script would've been dawesome, IMO, but netlink is much more awesome

crosbymichael, thanks for considering :)

also relevant, my current dockerinit binary is 3.7M ;)

not exactly slim, and would be a noticable impact on memory, especially somewhere like the basic digital ocean $5/mo package :)

(assuming it would be acceptable to just load it into memory and copy it directly from memory instead of from a file)

I need to head to bed, but will be happy to discuss more tomorrow :)

night all! :)

nite :)

sorry I was afk

tianon: for your reference tomorrow, I think there are 2 solutions

Solution 1) is to do what you describe - open dockerinit at startup, verify its checksum then, and find a way to mount-bind that every time after that

one way to do this is to reserve a special place for that /var/lib/docker

for example copy the correct dockerinit to /var/lib/docker/init/<checksum>

actually there's no solution 2 :)

you will need to copy, as I don't think there such a thing as mounting a file descriptor

scottbessler_: what happens when someone wants the protocol only?