In some test cases it would be nice to see how code performs when at a limited bandwidth, for example 28k, 56k, etc. Adding this ability to docker would make running these sort of tests easier.

It would also be handy from an administrator perspective as well.

Docker should be able to run in standalone mode, ie without a daemon running in the background. If possible the syntax should be the same in standalone mode and client mode.

For example: 'docker run -a base:e9cb4ad9173245ac /bin/ls' in standalone mode should fork and execute a new container, attach to it, and exit when it returns.

Of course detached mode would not be possible in standalone mode.

right now the logs command shows both the standard out and standard error combined, it would be nice if you can pass a flag and see just stdout or stderr. If no flag default to both.

This is helpful if you have a process that has lots of logs, and you really only want to see error messages.

If I am running 10000 copies of the same container across multiple machines but not each on its own machine, how can each container uniquely identify itself? How can I attach to (or otherwise manipulate) a specific copy of the container? Is there a way to broadcast instructions to all of them?

At what point does the AUFS file system become an IO burden instead of a benefit? That is, how many layers need to be tracked to resolve the final value of a byte in a file? What happens to files/bytes that will never be referenced because they are masked by something that has been written back to the file system?

Docker should be capable of restarting its child processes when they exit or are killed. This behavior should be optional: sometimes you don't want the process to be restarted (singleton jobs, interactive shells...)

This is a placeholder for @jpetazzo's adamant request for data volumes :)

Jerome, I will let you make your case in your own words. I agree with a lot of it, although we'll have to be careful how we distill it into the simplest possible API, and I'm not sure how early we want to do it.

Currently container logs are buffered in memory. If dockerd restarts, they are lost. They should be stored on disk instead.

Docker should not be responsible for managing rotation or other fancy log management strategies. It should expose a reasonable API for 3d-party logging tools to easily integrate with Docker (this will be the subject of another issue).

Docker already uses cgroups. Let's take advantage of this and enable per-container limits on ram usage.

Docker should expose the following per-container configuration:

• Memory hard limit
• Memory soft limit
• OOM behavior

right now there is no standard way on how to expose metric information about a container with docker. It would be helpful if there was some sort of metrics API, to make it easier to expose the metric information.

It would be a nice convenience if 'docker run' automatically tried downloading missing images before running.

With this feature, getting started with docker would be as simple as:

$ apt-get install docker
$ docker run base echo hello world

:)

We already build docker inside a docker container. If that container had the ability to run the test suite, then we could bootstrap a full CI environment on top of docker.

But that requires the ability to create containers within a docker container...

The containers system currently in production at dotCloud relies on a templating mechanism to setup a bunch of files before containers are actually started; namely:

• /etc/hostname
• /etc/network/interfaces
• ... some service-dependent configuration files ...
• /etc/resolv.conf

Almost all this templating magic can be waived a way or another (e.g., network configuration can be done "from outside" by Docker itself, instead of relying on inside-the-container distro scripts).

However, one item remains: /etc/resolv.conf. If we want the container to be able to do any kind of DNS resolution (and we probably do!) we need a valid /etc/resolv.conf.

Here are a few facts:

• if /etc/resolv.conf does not contain a "nameserver" entry (a fortiori if it's empty!), it will try to talk to the local DNS server (i.e. 127.0.0.1)
• the resolver behavior used to be override-able with e.g. RESOLV_HOST_CONF, but that was before the days of NSS
• /etc/resolv.conf can be itself completely bypassed by /etc/nsswitch.conf (the Name Service Switch master configuration file, which lets people enable NIS, LDAP, etc. for getpwnam, gethostbyaddr, and other resolving functions)
• AFAIK there is no default configuration for nsswitch.conf (i.e. if it's empty, the system will probably be unusable)

Its' safe that >99% of the systems out there are setup to use /etc/resolv.conf (with <1% with LDAP etc.), so the overwhelming majority of systems will work if we override /etc/resolv.conf. This can be done in multiple ways:

• if / is a writable (e.g. AUFS) filesystem, just overwrite /etc/resolv.conf
• if / is read-only, update the base image, so that /etc/resolv.conf will be a symlink to a writable place (e.g. /tmp/resolv.conf)
• bind-mount a pre-generated resolv.conf file over it (yes, you can bind-mount a file over another one!)
• make sure that /etc/resolv.conf doesn't exist, and setup "something" to listen on *:53 and relay DNS queries to a proper resolver

Generally speaking, the issue might arise with other configuration files. However, this should be fairly limited. There is a vast amount of knowledge out there about operation of disk-less UNIX systems, using e.g. read-only NFS root filesystems. Such methods exist since the 90s and all decent distros even have hooks to support read-only rootfs operation. I expect that exceptions would stem from brain-dead vendor binaries assuming some configuration file to be located in a hard-coded location (e.g. /etc/foo.conf or /opt/foo-1.0.42/etc/foo.conf).

For now, I tend to favor the bind-mount option, since:

• it doesn't involve AUFS
• it doesn't involve templating (the resolv.conf file ought to be the same for every container)
• it doesn't involve changing the base layer (as long as it contains a resolv.conf file)

If docker crashes while its child processes were running, it should be capable of seamlessly restoring its previous state when run again.

This means:

1. Re-attaching to child processes which are still running (or killing them if that's not possible)

2. Re-starting processes which were running at the time of the crash (eg. after a host reboot).

It would be nice if docker would track bandwidth usage for the containers.

right now the docker build files on the download server aren't very helpful, it would be nice to have names with more info, maybe date of build, or version number, this will make it easier t o pin to a specific version.

Docker keeps a lot of data on the disk. Basically one directory per command.

It's really important to hash the container directories in order to not reach a critical amount of directories inside /var/lib/docker/containers.

The problem with directory hashing is that it'll be more difficult to list the containers (without walking the whole filesystem). It's then mandatory to index the directories (using a sqlite db?) to keep the ps command fast (and to limit this command to a certain number of containers by default).

Currently, if you attempt to pull an existing image name with a non-existent revision, you receive the following error:

chooper@chimay:~/projects/docker/bin$ ./docker pull base:d34db33f
Downloading from base:d34db33f
Unpacking to base:d34db33f
curl: (6) Couldn't resolve host 'base'
base:d34db33f:e3b0c44298fc1c14
chooper@chimay:~/projects/docker/bin$ ./docker images
NAME                ID                               CREATED             PARENT
base:d34db33f       base:d34db33f:e3b0c44298fc1c14   2 minutes ago    

Allocating and configuring a tty ('docker run -t') works ok on a darwin client, but pretty badly on a linux client.

This is easy to reproduce with an interactive shell on the base image:

docker run -a -i -t base:e9cb4ad9173245ac /bin/bash

Currently, docker doesn't complain if you create an image with, for example, a colon in the name. However, if you then try to reference that image name, docker may believe you are pegging a specific version (since we use format $IMAGE_NAME:$REVISION) and certain commands will fail.

Validate and/or sanitize image names so, at the very least, they cannot contain colons.

It would be nice if container CPU usage was tracked and exposed in some way.

How sure are you of that checksum's "universal uniqueness"?
That seems like a much shorter UUID than any other I've seen, and assuming that a faulty checksum uniquely identifies a container could lead to some terrible collisions.

Anybody interested in contributing to Docker should be able to do it as easily as possible.

That means:

• accurate and simple instructions for setting up a dev environment
• contribution guidelines

Feature request from 1st meetup: "could you expose the size of images and containers on disk?"

Currently dockerd requires Ubuntu 12.10. What would it take to get it working on 12.04? @brianm notes that many shops are sticking to LTS, and therefore might not be able to adopt docker as easily.

If one of your container transfers large amounts of data over the network, Docker might be unable to start new containers, because of a kernel bug [1]

I have hit this on a Quantal host. A fix is available in linux 3.5.0-21.32

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065434

What steps will reproduce the problem?

  $ C=$(docker run base:e9cb4ad9173245ac /bin/sh -c "echo hello > /foo")
  $ IMG_ADDED=$(docker commit $C _/tmp/testrm)
  $ C=$(docker run $IMG_ADDED /bin/rm /foo)
  $ IMG_REMOVED=$(docker commit $C _/tmp/testrm)
  $ docker run -a $IMG_REMOVED /bin/cat /foo

What is the expected output?

  /bin/cat: /foo: No such file or directory

What do you see instead?

  hello

"docker web" looks for dockerweb.html in the current working directory, which isn't currently installed anywhere. Make dockerweb.html part of the install. It could be placed in /var/lib/docker for now

Many commands are missing from "dotcloud help" (with no args). Without much official documentation, this makes the UX difficult.

Containers inherit their environment from dockerd. They shouldn't.

We need 1) a minimal, predictable default environment for all containers, and 2) a mechanism for injecting new variables on a per-container basis (probably a new flag to docker run)

We are keeping Docker private while it incubates, but it is destined to be open-sourced. Under which licence should we do that?

Our priority in choosing a licence should be adoption. It should be as easy as possible for as many people as possible to use Docker.

When I create a new container and run the command '/bin/cat /dev/zero' inside it, it runs for approximately 2-5 seconds, then Docker prints 'Signal 9' and exits.

I could reproduce this reliably with the same command, but could not reproduce it with any other command. In particular, short-lived commands (eg. '/bin/touch /foobar') run properly without crashing, as well as other long-lived commands (eg. '/bin/sleep 10').

Our current base image is a vanilla quantal base image, built with the following command:

debootstrap quantal ./base

The resulting image is 194MB uncompressed.

We could make that image smaller by using a "minbase" variation:

debootstrap --variant=minbase quantal ./minbase

The resulting image is 105MB uncompressed, 34MB gzipped.

It would be awesome to be able to install the latest version of docker on Ubuntu with simply "apt-get install docker".

Add support for UDP port allocation

'docker pull' should behave more like 'git pull', and download multiple versions of an image, along with basic metadata eg. parent, creation date etc.

I don't really now if we can test the client, but for sure, we can and we should add a server_test.go to test all the server commands

Docker should be dead-simple to get working on EC2. The README should include instructions for this - 1 or 2 commands at most.

This could work with simply a custom .deb and ppa. But that might require installing a new kernel and rebooting. It would be nice to have instructions that don't require any reboot. Maybe with a custom AMI, or a pre-existing base AMI which has the kernel we need?

Note: this probably belongs in a helper tool, rather than docker core.

Authoring AMIs is a pain in the ass. The best solution to the problem is to install docker on EC2, and never author an AMI again.

But sometimes installing docker is not an option - maybe you depend on a kernel which isn't supported by docker, or your workflow is locked into the EC2 toolchain, or maybe you're happy with your existing process manager.

In this case, wouldn't it be cool to still author your filesystem images with 'docker commit', then export them to create AMIs effortlessly?

Inspiration: https://bitbucket.org/dotcloud/vm2vm/src

Will layers store whiteouts (a list of files to remove) in addition to added files?

If I remove /foo in a container, and export those changes into a new layer, what happens when I run a new container using that layer? Either a) /foo will be present (whiteouts are not stored in the layer), or b) /foo will not be present (whiteouts are stored in the layer).

Question 1: are whiteouts needed? Are certain use cases only possible with whiteouts?

Question 2: if we do need whiteouts in layer, what format should we use? We could use AUFS's convention - effectively making aufs part of the api, instead of just an implementation detail. Do we want that?

right now there is no easy way to know what version of docker you have installed, please add a --version flag.

When running IsMounted() on a stopped container, Docker will sometimes crash with "stale NFS file handle".

https://github.com/dotcloud/docker/blob/6df37208be269540a6f291448491bf5de9f46c96/filesystem.go#L59

Currently 'docker pull' must perform a full download before it can determine which images it already has. The download protocol should support checking for available versions, and only downloading missing versions.

This is especially interesting when downloading many images derived from the same base. Typically the base is much larger than the changes, so download times are vastly reduced.

If you can manipulate docker from inside docker, what is the authentication model?
How do I keep other containers from messing with me, cloning me, starting me, stopping me?
Or how do I give them permission to do so?

The "run -t" flag correctly allocates a pseudo-terminal and maps it to the process' stdin, stdout and stder. If that process opens /dev/tty, the correct behavior would be to return a file descriptor to the same pseudo-terminal. Eg. writing to it should produce output in the docker client, and reading from it should yield what was input on the docker client.

Instead, it returns a descriptor on the controlling termimal of dockerd. Eg output appears in the terminal which started dockerd. If dockerd doesn't have a controlling terminal, opening /dev/tty will fail altogether.

'docker push' should allow publishing images on a public mirror so that any other docker user can use them.

Images would be available under a namespace similar to github: username/project

usernames could be reserved with a builtin signup/login system, similar to 'npm adduser'.

In previous conversations I think we agreed that the ability to tag containers would be nice, but there was no compelling reason to add it to the core. Especially with globally unique IDs, it's super easy for a user to store all the metadata he needs himself: users, applications, services, versions, source repository, source tag, whatever.

However there is one thing that is only possible in the core: atomic operations on a set of containers matching certain tags. In the future that might be a necessary feature, for a number of reasons:

a) Performance (to avoid running 200 duplicate commands for 200 containers)
b) Reliability (eg. less moving parts when coordinating many dockers)
c) Ease of development

I don't have a set opinion, but wanted to write this down for later discussion.

Expose an API to allow programmatic interaction with docker over the network.

cc @aluzzardi @progrium feel free to record your preferences here for design, technology choices etc.

Make go test to download the unit test image instead of have to do it manually