#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.
Please remember that there are now 2 meetings, one in an Asia-Pacific timezone, and this one in the SF timezone.
Adding custom bridge support to docker run: moby/moby#6704
shykes asked about its effect on the --link functionaity, vish) indicated he would do some testing.
Also brought up the desire for bi-directional linking.
We're going to trial breaking our work into 4 rought areas: Runtime, Orchestration, Distribution, Trust
- Runtime is actual execution of the application, and all the system machinery involved. Roughly speaking: libcontainer and how Docker uses it. it also includes the system networking stack. Including the custom bridge topic brought up by vish_ for example
- Orchestration: multiple containers on multiple machines, talking to each other, and all the complicatins associated with tha
- Distribution: the packaging and shipping of digital content used by your application image format, registry API
- Trust is authentication and authorization. auth in the remote API, auth between engine and registry, delegation and storage of user credentials, key management etc
Big topic which affects Orchestration + Runtime: links
Big topic which affects Trust + Distribution: signed images
Wwhen possible we try to tag ongoing IRC discussions, and GitHub issues/PR's with #distribution or #runtime etc
- on distribution side, dmp42 and joffrey are the most active and vbatts|work
- Orchestration: erikh and vieux have started working on upgrading links, which is a big part of it. aanand, bfirsh and dmcg have been very active on libswarm
- Trust is mostly dmcg and jlhawn who have been working on key management for Docker.
- Most of the action on Runtime is with crosbymichael vmarmol and the libcontainer crew
And example of a Design proposal is something like this: gh#6802 docker prune: garbage collection of unreachable filesystem layers:
erikh is going to be owner for this new process - see gh#7091
vieux noted that we changed the company name from docCloud to docker, and need to move the docker repository.
The move was trialed with gordon (and boot2docker Sven) and most things are redirected by GitHub.
If there are no issues with moving sent to vieux by the weekend, He'll move the docker project to the docker organisation next week.
At the same time, some investigation will be done to see if we can set up a shorter golang import path
in the context of our shiny new #distribution group (cc vbatts|work dmp42 joffrey) there are a few improvements to the image system which we can start rolling out pretty quickly I'm just going to list what they are so that people know what's coming, and anyone interested can join the fun
- gh#6802 docker prune: garbage collection of unreachable filesystem layers
- gh#6805 Self-describing images
- gh#6906 Squash build dependencies
self-describing images has a dependency on image signature, which has a dependency on key management on each Docker engine (so that it has something to sign with) Anybody interested in these improvements: configure your irc client to highlight on "#distribution" and use it in this channel to get the attention of people in the group One big topic is: how much of all this can we do without breaking the image format and registry API The plan is to do as much as possible without changing the format, incrementally. Then, if there's anything left that really can't be done without a format change, we will think long and hard about the best possible change, and do it once. There is still plenty of time to discuss that.
The primary goal is to take the existing source of trust (the name of your Hub account) and make it less dependent on storing your image on the Hub. And the second goal is to allow setting up your own trust.
(read the IRC logs to follow the more detailed discussions)
The networking model of Docker needs a serious upgrade I'm seeing lots of tools bypass links completely and re-implement their own networking model These are mutually incompatible and introduce fragmentation for the developers So I would like to add to Docker's model what is missing My best summary of the requirement is: inter-container links should work as advertised to the developer, AND still allow arbitrary customization of the system networking stack: bridges, firewalling, macvlan, tunnels etc
basically right now I see 2 mutually exclusive tracks on networking + docker
- track 1: using and improving links
- track 2: bypassing and breaking links via low-level customization of the IP stack
right now the people who are interested in improving links, and the people who are interested in getting $next_escape_valve almost don;t overlap I would like to change that, because they are not 2 different topics
erikh: I have been working on a RFC for links
(again, much more detail in the logs)
Violent agreement ensues, with a resolution got @fkautz to add documentation
shykes: not much to discuss, I'm ok to merge, just wanted an extra pair of eyes on it for regressions
tibor is taking this over to get to merge.
dwalsh: Cap has made it into the docker, but I want to know the state of the namespace patches. shykes: I'm +1 on the design, already discussed with crosbymichael and vieux, I'm ok with whatever they're comfortable merging dwalsh: We are getting lots of interest in "Super" priv container. Which would be just --namespace=mnt -v /:/sysimage or something like that. dwalsh: I like the --ns-add --ns-remove idea. mrunalp: dwalsh: AFAIK we haven't done much on libcontainer side for --namespace. crosbymichael can correct me. exec/init will have to be modified to not do certain steps depending on what namespaces were specified. crosbymichael: yes, pid will just work but some of the other namespaces need support from libcontainer tianon: like --ns-add or --ns-remove ? dwalsh: tianon, Right I was wondering if there are patches already for this and are they hung up for some reason. crosbymichael: so maybe a general --namespace flag is not the best and we need something like --pid=false
crosbymichael: lets just keep this simple, what we had in the issues was on/off of namespaces, --ns-pid would be a good start because there is already support for dropping this and it makes sense using monitorying tools
Implement --cap and --namespace flags for better control
(and alot more discussion)