Support App Container images in the Docker Engine #10776

Closed
wants to merge 2 commits into
from

Projects

None yet
@jonboulle
Contributor

This PR should be considered a proof of concept, intended to start the discussion about appc support in Docker. Please consider it closely in tandem with #10777, which more broadly discusses implementation of appc in the context of Docker.

We do not expect this to land as-is, for various reasons, but wish instead to demonstrate the feasibility of supporting ACIs in Docker. The code here might be a starting point for future integration.

Overview

This PR provides simple, functional support for the App Container Spec within the Docker Engine. Specifically, it implements the ability to natively run App Container Images (ACIs) and also to perform image discovery to retrieve images. It achieves this with a minimally invasive patch which preserves the Docker user experience.

Examples

The following examples demonstrate basic usage of Docker with ACI support.

An ACI can be directly pulled by Docker using image discovery:

  # docker pull --format aci coreos.com/etcd:v2.0.0

Alternatively, ACIs can be imported to Docker from a file on disk or directly from an http URL:

  # docker pull --format aci file:///tmp/aciexamples-1-linux-amd64.aci
  # docker pull --format aci http://example.com/aciexamples-1-linux-amd64.aci

Listing images, including ACI images, works as expected:

  # docker images

ACIs can be run directly; referencing an image by its name will transitively perform image discovery if necessary:

  # docker run --format aci coreos.com/etcd

ACIs can also be referenced by their Image ID:

  # docker run --format aci fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df
  # docker run --format aci fa1cb92dc276

Docker create/start is also supported:

  # docker create --format aci coreos.com/etcd
  b2eb6289ced6506316b31daac101e3f3143f11ff96d046aca3338c9b9de934dc
  # docker start -i -a b2eb6289ced6506316b31daac101e3f3143f11ff96d046aca3338c9b9de934dc

Finally, deleting ACI images:

  # docker rmi --format aci coreos.com/etcd

How it works

An ACI image contains a rootfs directory and a manifest file. When an ACI image is pulled, the rootfs is converted to layer.tar. layer.tar and the manifest are then stored in the normal Docker graphstore. For example:

  # ls -l /var/lib/docker/graph/fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df/
  total 12364
  -rw-r--r-- 1 root root 12653824 Feb 13 11:24 layer.tar
  -rw-r--r-- 1 root root      228 Feb 13 11:24 manifest
  #

The directory name is the sha512sum of the ACI image (its imageID) truncated to 64 characters.

A new entry in the local image repository (/var/lib/docker/repositories-*) is created. For example:

  "ACIRepo" : {
      "coreos.com/etcd" : "fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df",
      "github.com/endocode/aciexamples" : "e3cd06d49820d9457115536ddbf2f05c4247d22190abed8f1c70551149add72f"
   }

When creating a container based on an ACI image, its configuration file /var/lib/docker/containers/<container_id>/config.json is generated from the manifest file and the command line parameters. For example, when the manifest contains:

   "app": {
        "exec": [
             "/etcd"
        ],

Docker will generate config.json with the following entrypoint:

     "Entrypoint" : [
         "/etcd"
      ],

Known Limitations

The following are known limitations with the current state of this patch.

  • labels: the ACI discovery mechanism defines various labels (for example: version, os, and arch). They are not stored in the Docker repository, so two versions of an ACI image with the same name cannot be stored at the same time.
  • isolators: isolators specified in the manifest of an ACI are ignored. However, options such as --cap-add, --cap-drop, --privileged should still work when used on an ACI.
  • dependencies: an ACI image can depend on other images in a similar way to layers in Docker. This is not implemented yet. Only ACI images without dependencies are supported.
  • unix group: a manifest can specify to run the program in the container as a specific unix group. This is not implemented yet.
  • unix user or group referring to a file: instead of specifying a uid/gid or username/groupname, a manifest can request to use the owner and group of an file found at an absolute path inside the rootfs. This is not implemented yet.
  • mount points and ports specified in the manifest are ignored. This is not implemented yet.

We would really love to solve all of these limitations over time. But, before we put in a substantial amount of work we wanted to have a wider design proposal. So, please consider this in tandem with #10777 which more broadly discusses implementation of appc in the context of Docker.

@GordonTheTurtle

Can you please sign your commits following these rules:

https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work

The easiest way to do this is to amend the last commit:

$ git clone -b "aci_in_docker" git@github.com:coreos/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f
@alban @jonboulle alban Include appc/spec v0.3.0
Signed-off-by: Jonathan Boulle <jonathanboulle@gmail.com>
c824463
@jonboulle
Contributor

@GordonTheTurtle oops, done - thanks for the tip!

@jessfraz jessfraz added 1-design-review and removed 0-triage labels Feb 13, 2015
@alban @jonboulle alban Support ACI images in the Docker Engine
== Overview

This PR provides simple, functional support for the App Container Spec within
the Docker Engine. Specifically, it implements the ability to natively run App
Container Images (ACIs) and also to perform image discovery to retrieve images.
It achieves this with a minimally invasive patch which preserves the Docker
user experience.

== Examples

The following examples demonstrate basic usage of Docker with ACI support.

An ACI can be directly pulled by Docker using image discovery:
  # docker pull --format aci coreos.com/etcd:v2.0.0

Alternatively, ACIs can be imported to Docker from a file on disk or directly
from an http URL:
  # docker pull --format aci file:///tmp/aciexamples-1-linux-amd64.aci
  # docker pull --format aci http://example.com/aciexamples-1-linux-amd64.aci

Listing images, including ACI images, works as expected:
  # docker images

ACIs can be run directly; referencing an image by its name will transitively
perform image discovery if necessary:
  # docker run --format aci coreos.com/etcd

ACIs can also be referenced by their ImageID:
  # docker run --format aci fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df
  # docker run --format aci fa1cb92dc276

Docker create/start is also supported:
  # docker create --format aci coreos.com/etcd
  b2eb6289ced6506316b31daac101e3f3143f11ff96d046aca3338c9b9de934dc
  # docker start -i -a b2eb6289ced6506316b31daac101e3f3143f11ff96d046aca3338c9b9de934dc

Deleting ACI images:
  # docker rmi --format aci coreos.com/etcd

== How it works

An ACI image contains a rootfs directory and a manifest file. When an ACI image
is pulled, the rootfs is converted to layer.tar. layer.tar and manifest are
then stored in the normal Docker graphstore. For example:

  # ls -l /var/lib/docker/graph/fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df/
  total 12364
  -rw-r--r-- 1 root root 12653824 Feb 13 11:24 layer.tar
  -rw-r--r-- 1 root root      228 Feb 13 11:24 manifest
  #

The directory name is the sha512sum of the ACI image truncated to 64
characters.

A new entry in the image repository (/var/lib/docker/repositories-*) is
created. Example:

  "ACIRepo" : {
      "coreos.com/etcd" : "fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df",
      "github.com/endocode/aciexamples" : "e3cd06d49820d9457115536ddbf2f05c4247d22190abed8f1c70551149add72f"
   }

When creating a container based on an ACI image, its configuration file
/var/lib/docker/containers/<container_id>/config.json is generated from the
manifest file and the command line parameters. For example, when the manifest
contains:

   "app": {
        "exec": [
             "/etcd"
        ],

Docker will generate config.json will have the following entrypoint:

     "Entrypoint" : [
         "/etcd"
      ],

== Known Limitations

The following are known limitations with the current state of this patch.

- **labels**: the ACI discovery mechanism defines various labels (for example:
version, os, and arch). They are not stored in the Docker repository, so two
versions of an ACI image with the same name cannot be stored at the same time.

- **isolators**: isolators specified in the manifest of an ACI are ignored.
However, options such as --cap-add, --cap-drop, --privileged should still work
when used on an ACI.

- **dependencies**: an ACI image can depend on other images in a similar way to
layers in Docker. This is not implemented yet. Only ACI images without
dependencies are supported.

- **unix group**: a manifest can specify to run the program in the container as
a specific unix group. This is not implemented yet.

- **unix user or group referring to a file**: instead of specifying a uid/gid
or username/groupname, a manifest can request to use the owner and group of an
file found at an absolute path inside the rootfs. This is not implemented yet.

- **mount points** and **ports** specified in the manifest are ignored. This is
not implemented yet.

We would really love to solve all of these limitations over time. But, before
we put in a substantial amount of work we wanted to have a wider design
proposal. So, please consider this in tandem with the issue on
http://github.com/docker/docker/issues which more broadly discusses
implementation of appc in the context of Docker.

Signed-off-by: Jonathan Boulle <jonathanboulle@gmail.com>
7409894
@duglin
Contributor
duglin commented Feb 13, 2015

Haven't looked at all yet but the first thing that jumps out at me as I scan the PR text is that this seems to have a lot of similar aspect to the issues we're seeing when we want to support non-x86 architectures. In other words, when I see things like:

docker run --format aci ...

I want to try to hide the --format flag from the user. There's work going on to have arch and OS support for images and registries, and I hope, to keep that as hidden from the user as possible. I wonder if something similar here could be done. For example, could Docker/registry know that the image is in ACI format instead of Docker's and then take the appropriate actions. I think keeping the end user unaware of the specific format would be a good thing from a usability perspective - if that's possible.

@damm
damm commented Feb 13, 2015

Having docker/registry know the image is an ACI and fetch it sounds horrible. That's like changing the streams and not telling the end-user you just did something it didn't expect.

That almost comes close to a lie to the end user? unless you have output to tell them what your doing and then everything I said is moot.

@thaJeztah
Member

Haven't looked into the proposal in depth, but naming this option --format might not be wise, given that Docker already has a --format option for other commands, with a different meaning (for reference, see docker inspect --format)

@shykes
Contributor
shykes commented Feb 13, 2015

Can someone explain to me how the user benefits from this? Are we talking about improving the image distribution system with cryptographic signature and better mapping to the DNS namespace? Then send a patch to improve the existing image system, or even better, join the ongoing effort to do exactly that. If you don't think it's worth your effort to improve Docker's system, that's fine, just do it in your own project and let the best project win. But guys, you have to choose one or the other. This whole masquerade about "protecting the community" with made-up standards sounds great in the press, good for you. But here, we care about the users. And it makes no sense for the user to have to deal with 2 incompatible universes of images with the same tool. It creates artificial constraints and solves zero problems. These 2 formats are almost completely identical, and the differences will only diminish as we progress on our respective roadmaps.

Please, if you want to change my mind, walk me through a concrete user scenario where the user is better off dealing with 2 "standards" instead of simply continuing to improve the one we have.

Otherwise, I beg you, stop the charade, and let's go back to competing normally like the rest of the open-source world does.

@preillyme

Maybe there should be an open container summit or something to address all these issues in the open.

@digital-wonderland

@shykes My, as in a users, advantage would be, that I would be able to run ACI images on docker.

If the image handling is properly abstracted (don't know enough about the code to judge) the ability to handle different image formats is an awesome feature, since it would allow/force different backends to compete (i.e. imagine a backend with cryptographically signed/encrypted images delivered via bittorrent - think something along the lines of twitters murder) - same goes for custom registries.

From a users perspective it then shouldn't matter if one runs an ACI or Docker image since that could be handled via the registry & dockers image handling layer.

IMHO this PR is really great (if it sucessfully manages to introduce some image layer) cause that would separate the image handling from the runtime and that separation is a great choice to have.

And if nothing else comes out from it, than a merge of ACI & Docker image formats, then even better.

So, if this PR introduces an acceptable start of an image handling layer, which is good for above reasons, why should it be bad?

@duglin
Contributor
duglin commented Feb 14, 2015

I wasn’t clear. Let me try this way…when I see:
docker pull --format aci http://example.com/aciexamples-1-linux-amd64.aci
what I would prefer to see is just:
docker pull http://example.com/aciexamples-1-linux-amd64.aci
and via the metadata around what is downloaded the Docker daemon would detect that it needs to convert it into a Docker image format. From them on the user can do:
docker run
and it would be run just like any other Docker image/container. That’s what I meant by its hidden from the user. The daemon knows what it can support and it should know what is being downloaded (if not then there’s something wrong with the incoming data). No real need for the user to get involved via --format flags.

My point is that I viewed this as more like an import feature, but perhaps I was over simplifying it or missing something.

-Doug

On Feb 13, 2015, at 4:43 PM, Scott M. Likens notifications@github.com wrote:

Having docker/registry know the image is an ACI and fetch it sounds horrible. That's like changing the streams and not telling the end-user you just did something it didn't expect.

That almost comes close to a lie to the end user? unless you have output to tell them what your doing and then everything I said is moot.


Reply to this email directly or view it on GitHub #10776 (comment).

@damm
damm commented Feb 14, 2015

perhaps --format is overloaded in Docker; --type would be just as much of a winner (imo).

You shouldn't hide it from the end user however @duglin. If you are going to run a container in a different format than the typical it should require extra work to get there.

It's not what your typical end users are going to be doing; and you don't want to make it too hard to start up as a new user as well. The balance typically is in a 'custom' setting(knob?) somehow achieved.

but docker pull ubuntu:12.04 should still work like normal but docker run --format aci http://example/influxdb.aci should tell it that it's not the default and it may need to 'load' something for it to work.

As I said --format is overloaded so maybe a different name or a different way to achieve it. But it should not be transparent or magical.

@blakelapierre

If one format has advantages over another, it would be nice to be able to use that new format without having to use yet another application, rewrite scripts, test scripts, etc. It seems there could be an advantage to being able to run multiple formats. As a user, pretty much the last thing I want to be dealing with is trying to figure out how start a program. It looks like Docker is being given an opportunity to be that platform, and the code is coming for free.

I haven't read through the 38k+ lines of code here, but if it works, I would appreciate the merge. If it is preferred that people use standard Docker format, throw up a big banner warning for the user when they run an image with the contributed code. It sounds like the --format flag might need to be changed. I also agree with @duglin that the user shouldn't need to do anything different to run images in different formats.

I don't see being able to run even more software as something that Docker should be trying to avoid. Is there something deficient with the images that this PR allows to be run?

@ncoghlan

As an end user, I'd really prefer people (including me) just convert ACIs to Docker images if they really want to use them with Docker and the publisher doesn't provide a Docker image themselves.

This PR is like giving yum the ability to install deb packages or apt-get the ability to install RPMs, rather than working on making it easier for software publishers to easily provide both formats, so we as end users can choose the ecosystem we prefer without needing to worry about the competition as part of the day-to-day operation of our systems.

A registry PR to translate ACIs to Docker images on upload might make sense, but please don't let the argument over image format details propagate to my servers by adding ACI support directly to the Docker client. If I actually want to run ACIs myself, I'll install Rocket.

@jcfr
jcfr commented Feb 14, 2015

@ncoghlan 👍

I guess the mirror tool to docker2aci would have to be created.

@viktortnk

Agreed with @ncoghlan

I don't think Docker (community, maintainers and organisation behind it) should have any responsibility with plugging in and maintaining another technology which is about the same.

At first, CoreOS strongly criticise many aspects of Docker, but still want to use it's establishment to promote alternative solution out of the box. I don't see here any benefit for end user.

If one day I fall in love with AppContainer and put some effort to port part of my services there, I wouldn't mind to much installing Rocket

@timothysc

As a user and clustering guy, I would like this capability.

In clustering it would be ideal to just have one tool that ran many formats, this would be in a similar vein to libvirt.

@preillyme

@timothysc — I agree with you 100%. But do you think it's Docker's responsibility to provide that abstraction layer?

@thaJeztah
Member

I've browsed through the changes in this proposal and am -1 on this;

  • This change brings a lot of additional dependencies (38000 new lines of code!), which doesn't benefit the standard Docker user in any way.
  • I don't like the way it's implemented; having "if format is aci then ..." sprinkled throughout the code is (imo) just messy. If it would be implemented, I think some refactoring is required to better separate the code paths. Right now, it feels like a "quick hack".
  • Given that there's no full feature parity between ACI and Docker, this will not be a good user experience for people trying to run ACI images in Docker. People encountering such issues ("my image doesn't run properly") will easily blame Docker, whereas it's just because both formats have different features. I think it's highly unlikely that Docker will have full feature-parity with ACI because that would imply ACI "dictating" what features to implement in Docker. Also, that would require a lot more contributions of the App Container/CoreOS developers to Docker and a dedication from them to maintain the code.
  • Looking at the commits, the code for this was created 18 days ago (assuming GitHub shows this correctly), but (afaik) not discussed, nor was an actual pull-request created until the accompanying "press release" was published on the CoreOS website. I'd like to be proven otherwise, but if the App Container/CoreOS team really wanted this implemented, it would have been better to discuss this first and check what the posibilities were of having this integrated, before "going public".

To summarise my thoughts/opinion;

  • I don't think this belongs in the core functionality of Docker, especially because it's an incomplete implementation that would create more issues thank it would solve.
  • If App Container/CoreOS wants to bring support for ACI to Docker, implementing a counterpart to docker2aci (as suggested by @jcfr) is a good alternative that would directly benefit users that have a need to run ACI images on Docker.
  • There are still plans to implement a "plugin" system in Docker. I'm not sure if this area will be part of this, but possibly this could be implemented as a plugin. This would keep a clear separation of responsibilities and enable users to run ACI images without requiring code changes to the Docker core.
@vidarh
vidarh commented Feb 14, 2015

As a user, what appeals to me with this is getting the DNS based federation and content-addressability, as well as signed images. I don't care about the image formats. But the suggestions of conversion tools in particularly does not address the federation support, which is the most important one to me.

@preillyme

I'm also 👎 on this change for many of the same reasons as @thaJeztah. As far as @vidarh's comment about DNS based federation and content-addressability; I agree those pieces of functionality are much needed in Docker but they should be handled in a different way in my opinion. Forcing App Container on people isn't the answer. Docker is docker and CoreOS Rocket is Rocket stop trying to build a bridge that no one is requesting.

@vidarh
vidarh commented Feb 14, 2015

@preillyme until Docker actually has that functionality, I for one am requesting this bridge.

@preillyme

@vidarh but couldn't it be handled in a different way with less modification to Docker itself?

@vidarh
vidarh commented Feb 14, 2015

@preillyme It certainly can, and if that can be added in a similar timeframe to getting this PR or the associated proposal to an acceptable state, then that may very well be the best situation. But the presence or absence of federation and content-addressability is likely to be a large part of the deciding factor for me on whether to deploy Docker or another tool on future projects. Much more so than which image format it's based on.

@thaJeztah
Member

@vidarh I know there's a lot of ongoing work to improve this. Partly, this will also depend on changes to the registry, because that's the distribution mechanism used by Docker; Keeping backwards-compatible with older Docker clients is an important issue here, so those changes cannot be done "overnight".

If you're not doing so already, you may be interested in subscribing to the docker/distribution repository, because that's where a lot of these changes are currently taking place. A number of goals for that project are outlined in the Kick-off document, which you may want to read as well.

I think the Docker maintainers are well aware there are improvements to be made in that area, but it takes time to make sure it's implemented the right way. Docker has a large use base; they don't want to break their setups because if this, and want to offer a fluent migration-path to them.

@philips
Contributor
philips commented Feb 14, 2015

This PR is meant to be a proof-of-concept to help the discussion of a shared standard in the #10777 proposal.

The appc spec does have a number of desirable attributes that people have asked for in Docker including: DNS based federation and content-addressability. The docker/distribution Dec 29th kickoff doc shows that our goals are similar.

We have similar technical goals and the appc code is here so we can play with the ideas. Ideally we get to a place where the standard is shared and useful for everyone.

@thockin
Contributor
thockin commented Feb 14, 2015

@preillyme

@timothysc https://github.com/timothysc -- I agree with you 100%. But do
you think it's Docker's responsibility to provide that abstraction layer?

I interpret that as "everyone who cares about any aspect of ACI should use
a wrapper that hides docker". That seems bad for docker. Here I see a
chance for docker to answer some of the issues that rocket brings up, while
continuing to own the UX.

I did not review the code, but conceptually this makes two layers - the UX
and the image format. That is a pretty nice split.

Without such a change (perhaps not literally this one, if actual technical
issues exist), a wrapper will emerge, and docker loses a (small) bit of its
position.
On Feb 14, 2015 9:15 AM, "Sebastiaan van Stijn" notifications@github.com
wrote:

@vidarh https://github.com/vidarh I know there's a lot of ongoing work
to improve this. Partly, this will also depend on changes to the registry,
because that's the distribution mechanism used by Docker; Keeping
backwards-compatible with older Docker clients is an important issue here,
so those changes cannot be done "overnight".

If you're not doing so already, you may be interested in subscribing to
the docker/distribution https://github.com/docker/distribution
repository, because that's where a lot of these changes are currently
taking place. A number of goals for that project are outlined in the
Kick-off
https://github.com/docker/distribution/blob/master/doc/opensprint/kickoff.md
document, which you may want to read as well.

I think the Docker maintainers are well aware there are improvements to be
made in that area, but it takes time to make sure it's implemented the
right way. Docker has a large use base; they don't want to break their
setups because if this, and want to offer a fluent migration-path to them.

Reply to this email directly or view it on GitHub
#10776 (comment).

@damm
damm commented Feb 14, 2015

I think there is too much negativity in this issue and not enough collaboration or trying to work together. In a way it's like looking at a bunch of Teenagers nitpicking someones outfit instead of saying it looks nice.

I would like to see more constructive criticism and helpful suggestions.

@ncoghlan

I suspect the following parts are items folks can agree on:

  • DNS based federation is good, and we'd like to see that in Docker itself
  • content addressability is good, and we'd like to see that in Docker itself
  • decoupling the container format from the container management UX is at least potentially beneficial to end users

It doesn't follow that accepting this PR is the correct way to address those needs, as the negative consequences for long term usability and maintainability may be significant. What the PR does show is that it's at least possible to do that within the context of Docker as it exists today, even if the implementation details and the UX consequences make this specific approach a bad idea.

For users that want this kind of capability in the near future, a higher level container orchestration system like Kubernetes can probably abstract away the details of Docker invocation more easily than Docker can abstract away the details of its image format (Note: a container abstraction at the k8s layer will cover my own use cases if the need to use ACIs directly came up for some reason, so it's worth factoring that in when I say that I consider direct support for Rocket-in-Docker to be redundant and not something I want on my servers)

I'd personally prefer that the Docker and Rocket teams take the time to focus on the hard work of collaborating on a shared image format standard in the interests of their respective users. Let folks that decide they really need to run both in the interim be the ones that incur the maintenance overhead of doing so, rather than inflicting it on the core Docker project.

@vidarh
vidarh commented Feb 15, 2015

@ncoghlan I agree with the first parts of what you write. A couple of comments: I use Docker, and I want these features, but tools like Kubernetes tends to make a lot of architectural assumptions. If they work for you, great, but Kubernetes for example is not at all attractive for me for the same reasons that Docker is: It's way too complicated for my typical use cases. I think that will apply for a lot of Docker users.

Being able to get this functionality in a more focused tool is a large part of the appeal with support for the mentioned functionality directly in Docker. I also don't think it'd be good for Docker for the default choice for a large part of user to be to either consume Docker containers via Rocket (Rocket has added support for Docker images), or wrap Docker in a higher level interface just to get this functionality.

(Also, just to avoid confusion: this PR is about adding support for ACI, specifically not Rocket, which is one of multiple implementations of ACI.)

But even if this PR is not suitable, together with the associated proposal it provides workable example code of how to achieving this. I would hope that that at least gets a serious look. For starters, there are elements there that ought to be fairly simple and possible to to agree on a shared approach with ACI/Rocket, such as a content signature.

Even just having Docker and ACI images share the same algorithm for determining a content hash, and for Docker to make it possible to operate on images (run, reference from Dockerfile etc.) by hash would be a big step forwards on it's own. That, coupled with an interface to importing layers into Docker from the file-system (possibly lifted from this PR) would seem to be sufficient to make it possible to implement your own pull mechanism for ACI images "on the side" of Docker.

So perhaps it might be possible to extract some very limited pieces of functionality here that would add real benefits in the short term, and allow those who want it to interop more easily with ACI (or other tools/formats) without taking the whole thing.

@thockin
Contributor
thockin commented Feb 15, 2015

FWIW work has already begun (also by CoreOS folks) to make kubernetes
support ACI, so that will soon be an option for many people. But for those
people who don't want/need Kubernetes something else will be needed.
On Feb 14, 2015 8:01 PM, "ncoghlan" notifications@github.com wrote:

I suspect the following parts are items folks can agree on:

  • DNS based federation is good, and we'd like to see that in Docker
    itself
  • content addressability is good, and we'd like to see that in Docker
    itself
  • decoupling the container format from the container management UX is
    at least potentially beneficial to end users

It doesn't follow that accepting this PR is the correct way to address
those needs, as the negative consequence for long term usability and
maintainability may be significant. What the PR does show is that it's at
least possible to do that within the context of Docker as it exists today,
even if the implementation details and the UX consequences make this
specific approach a bad idea.

For users that want this kind of capability in the near future, a higher
level container orchestration system like Kubernetes can probably abstract
away the details of Docker invocation more easily than Docker can abstract
away the details of its image format (Note: a container abstraction at the
k8s layer will cover my own use cases if the need to use ACIs directly came
up for some reason, so it's worth factoring that in when I say that I
consider direct support for Rocket-in-Docker to be redundant and not
something I want on my servers)

I'd personally prefer that the Docker and Rocket teams take the time to
focus on the hard work of collaborating on a shared image format standard
in the interests of their respective users. Let folks that decide they
really need to run both in the interim be the ones that incur the
maintenance overhead of doing so, rather than inflicting it on the core
Docker project.

Reply to this email directly or view it on GitHub
#10776 (comment).

@wyaeld
wyaeld commented Feb 17, 2015

Posturing aside, I would love to see an impartial breakdown of the differences in Appc vs Docker's image spec, and the changes they are making in docker/distribution, and pro/cons of the technical merits of choices.

I don't mind seeing differences where companies are forging around with using their UX to add value. I don't want to see meaningless differences about things like how to hash a tarsum because no-one wanted to discuss the options, since then every toolmaker has to compensate for the differences, and you slow down the entire ecosystem unnecessarily

@philips
Contributor
philips commented Feb 17, 2015

@wyaeld This is a good suggestion. There are a number of outstanding proposals against Docker that appc might be able to show a concrete implementation for and that is described in the proposal on #10777.

To start a discussion I wrote-up a description of how the image manifests differ between appc and Docker v1 and how we can work together: #10777 (comment)

@spf13
Contributor
spf13 commented Feb 19, 2015

@philips As you stated that this is a proof of concept and not intended for merging it doesn't really make sense as an open pull request. I would like to suggest you close this and we continue to have a discussion on the proposal issue #10777. As a closed PR it can still serve as a good reference for the proposal which you stated was the intent in the first place.

@philips
Contributor
philips commented Feb 19, 2015

@spf13 seems reasonable. Looking forward to continuing the discussion in #10777.

@spf13
Contributor
spf13 commented Feb 19, 2015

Sorry, didn't acknowledge that @jonboulle opened it initially. @jonboulle can you close?

Appreciate it @philips & @jonboulle and likewise looking forward to the discussion in #10777.

@jonboulle jonboulle closed this Feb 19, 2015
@dmp42 dmp42 removed the 1-design-review label Feb 19, 2015
@tlyng
tlyng commented Feb 25, 2015

They say you can judge how free a society is by how it's treating it's dissidents, how free are you docker? When someone submit a PR containing 38,000 lines of code you show gratitude - quality and if it solves some problem doesn't matter - you show gratitude! The hostility and shitkid attitude in some of the comments are just embarrasing.

My two cents.

@TheDong
TheDong commented Feb 25, 2015

@tlyng I wish people would quit quoting that '38kloc' number like it was anything close to correct.

That's just so large because of how Go code vendoring works. If you run git diff --stat 8b010d9f $(ls | grep -v 'vendor') on this PR, you get a much clearer picture of "14 files changed, 942 insertions(+), 24 deletions(-)".

Just because he pulled in 37kloc of dependencies (and testdata with those dependencies) does not mean the code is instantly worthy of gratitude.

The discussion above about why this PR should not really be open is fine and logical; the code indeed is not something that is worth merging in its current state, and if someone improves it sufficiently a new PR could be opened.

The real crime docker is committing here, IMO, is the complete lack of discussion on the proposal #10777... That's where things could actually begin to change, but they appear to just be stonewalling it.

@damm
damm commented Feb 25, 2015

It doesn't matter the thousands of lines of code; what matters is how people respond to a pull request.

I wish I could get the Docker team to read this and follow it.
http://www.defmacro.org/2013/04/03/issue-etiquette.html

They just closed an issue where a container failed to restart between 0.10.0 and 1.0.0 as it's pre 1.0.

If we cannot guarantee the container restarting between major and minor versions; why are we using Docker?

@tlyng
tlyng commented Feb 26, 2015

@TheDong the LOC doesn't really matter. If you manage an opensource project and third party people / organizations -choose- to contribute (shit or not) you show gratitude for their efforts. That's my opinion atleast.

I can understand that developers may be somewhat sensitive to this PR, both Docker developers and the CoreOS team. Anyway for me as an end user I want support for those images atleast, I don't want to be locked in to any particular technology. I utilize docker for running images, not scheduling and similar - not orchestration and on-demand server creation. I'm basically looking for a tool which does one thing really good, launch images. There will be many container formats in the coming years, a tool that understand several will be a better choice than a tool that understand one.

@md5
Contributor
md5 commented Feb 26, 2015

@tlyng (and others) I'm not sure why trying to push for cross-framework image standardization now should be expected to result in a better container ecosystem down the road. Perhaps it's premature to try to standardize these things up front, given how raw the ecosystem still is and how many gotchas likely still lurk.

There seems to be some assumption by a few of the commenters on this issue that there is malice or intentional neglect behind the lack of discussion on this proposal, but my opinion is that people are just busy with more important stuff.

Personally, I don't feel like choosing to work with Docker is locking me in to anything. I'm confident that the work I'm doing now with Docker will translate easily to future container systems and I see this PR as a bit of a distraction, particularly due to the peanut-gallery sniping by people who aren't doing anything productive to address the problem they're complaining about themselves. Honest discussion toward actually advancing this proposal is one thing, but questioning people's motives is an entirely different thing.

@wyaeld
wyaeld commented Feb 27, 2015

Given the great work that the clusterhq guys have been doing with
Powerstrip to make plugins possible to the core docker engine, I wonder if
@philips could provide a pluggable (via powerstrip) way for people that
want to test out app container support.

On Fri, Feb 27, 2015 at 3:38 AM, Mike Dillon notifications@github.com
wrote:

@tlyng https://github.com/tlyng (and others) I'm not sure why trying to
push for cross-framework image standardization now should be expected
to result in a better container ecosystem down the road. Perhaps it's
premature to try to standardize these things up front, given how raw the
ecosystem still is and how many gotchas likely still lurk.

There seems to be some assumption by a few of the commenters on this issue
that there is malice or intentional neglect behind the lack of discussion
on this proposal, but my opinion is that people are just busy with more
important stuff.

Personally, I don't feel like choosing to work with Docker is locking me
in to anything. I'm confident that the work I'm doing now with Docker will
translate easily to future container systems and I see this PR as a bit of
a distraction, particularly due to the peanut gallery sniping by people who
aren't doing anything productive to address the problem they're complaining
about themselves. Honest discussion toward actually advancing this proposal
is one thing, but questioning people's motives is an entirely different
thing.


Reply to this email directly or view it on GitHub
#10776 (comment).

@tlyng
tlyng commented Feb 27, 2015

As a side note, instead of using --format I suggest using --foreign or something similar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment