#docker-dev meetings are held twice a week in the #docker-dev irc group on Freenode. This irc channel is logged all the time, so you can always refer to it.
Held at 2:30pm Wednesday, Brisbane time.
Please remember that there are now 2 meetings, this one, and the one in the SF timezone.
To give us some breathing space to focus more on PRs and issues, make things more async etc
It looks to me like we'll be having that monthly meeting at the begining of the month thus coinciding with, or just after the .0 release if you have opinions, please discuss, as we can push that to the US meeting
lk4d4:
- I don't know, alexlarsson won't be happy :) he hardly can push his PRs flow with weekly meetings
- I also needed 7 weeks to find shykes on meeting
I think that PR pushing is intended to become more async, but that is something that needs to be worked out
we'll also be experimenting for the next week with a lighter LGTM rule: only 1 LGTM required per subsystem, instead of majority
There was quite a bit of discussion after last week's meeting - see https://botbot.me/freenode/docker-dev/msg/18953120/
and then because I moved to the next topic too quickly, there is more at the EOM
#topic - back to : we'll also be experimenting for the next week with a lighter LGTM rule: only 1 LGTM required per subsystem, instead of majority
-
first up - its a week long experiment, so imo not scary
-
it may mean that each maintainer that does review is much more careful in that PR
-
or it may result in stalemates, where no-one wants to accidentally miss something
-
so it will be interesting to see how it goes (in the non-negative, i have no data, kind of way)
-
lk4d4: can we block self-LGTM?
-
SvenDockerInc: as far as i know, a self LGTM is invalid
-
lk4d4: maybe, but shykes did this in libchan :D
-
SvenDockerInc: which makes it fun for tianon when he's making PR's where he's the only maintainer
-
lk4d4: and was successful
-
SvenDockerInc: its worth adding to the ruleset for the experiment - tianon can you please add to the meeting?
Esentially the speed of Dockers push and pull is becoming a real blocker for us, using docker to push / pull the speed seems to be limited to around 3-5MB/s, even over a 2Gbit link. when you curl a layer directly, you can get the layers at around 110MB/s
- shykes: sammcj yeah we're on that. Seems to be a buffering issue cc backjlack lk4d4 And cc dmp42 also Help welcome
backjlack: I'm working on this. The problem is mostly caused by IO stalls introduced by syscalls and disk IO. This problem is less noticeable on systems with very fast disk IO. Coming up with a fix which improves this in ~20-40% of the cases is simple. Those cases usually involve short stalls and it's easy to get around using larger buffers.
- ross_w: we do have relatively slow disks, but we can still curl the layers, to disks, at 110MB/s
- SvenDockerInc: good point - backjlack ? why is curl doing so much better of a job?
- backjlack: The problem isn't just about being able to write at 100MB/s. The system has to be able to create files, directories and do many other fun syscalls in the process.
- ross_w: theres been some suggestions the slowdowns were causing the tcp window to shrink back to initial
- backjlack: The TCP congestion et all start hammering down the transfer, that's right, but that's a side effect of the problem, IMHO.
- ross_w: as mentioned, it is causing us fairly considerable pain -so if you need us to test anything let us know and we are very happy to help
- backjlack: Thanks for offerring! Fortunately, we can reproduce this and test potential improvements. The problem is being worked on. Please let me know if I should ping you on GitHub so you can keep track of this.
mwhudson:
i work on arm server stuff and people keep asking me about docker there are two problems: 1) we only have gccgo on arm64 for now 2) docker things all the world is an amd64
1 is the sort of thing i have been doing for a while now 2 is not :) to some extent this is a registry thing really clearly images and layers are arch specific but how far up the stack does the arch specificness go?
to me it seems like it would make sense for repos to be able to contain images for multiple arches so you can say docker pull ubuntu on any platform
but well i dunno, i'm not really a docker user :)
There is a group working on distribution stuff - see https://github.com/docker/irc-minutes/blob/master/docker-dev/2014-07-17--17-30.md#topic-update-on-the-working-groups---orchestration-distribution-runtime-trust-shykes
the distribution working group are the guys dmp42 and joffrey
basically, b2d will autogenerate the tls certs, send them to the right place and use it if all goes well, the user UX will be identical, just the docker port will change from 2375 to 2376
I'm planning to add a simple samba mount on OSX that will be mounted in the b2d VM and that can then be docker run -v /docker-share:/somethng mounted into a container My plan is to default to sharing ~/docker-share, so that the user has to intentionally share it from their OSX box (or windows, or linux) so that we have some safety - but 'default' also means users will be able to change it to give containers full access to their desktops
at the same time, we're expecting some more progress on the fuse in docker work, but its not going to happen as quickly
we have a cut of hyper-v support and are expecting to see vmware support in (and qemu support) around the 1.3.0 timeframe too so boot2docker is becoming much more vmserver independant and we finally have some of the underlying b2d functionality at a point where we /should/ be able to add file sharing support without falling over