github.com/portworx/docker@v1.12.1/ROADMAP.md (about)

     1  Docker Engine Roadmap
     2  =====================
     3  
     4  ### How should I use this document?
     5  
     6  This document provides description of items that the project decided to prioritize. This should
     7  serve as a reference point for Docker contributors to understand where the project is going, and
     8  help determine if a contribution could be conflicting with some longer terms plans.
     9  
    10  The fact that a feature isn't listed here doesn't mean that a patch for it will automatically be
    11  refused (except for those mentioned as "frozen features" below)! We are always happy to receive
    12  patches for new cool features we haven't thought about, or didn't judge priority. Please however
    13  understand that such patches might take longer for us to review.
    14  
    15  ### How can I help?
    16  
    17  Short term objectives are listed in the [wiki](https://github.com/docker/docker/wiki) and described
    18  in [Issues](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our
    19  goal is to split down the workload in such way that anybody can jump in and help. Please comment on
    20  issues if you want to take it to avoid duplicating effort! Similarly, if a maintainer is already
    21  assigned on an issue you'd like to participate in, pinging him on IRC or GitHub to offer your help is
    22  the best way to go.
    23  
    24  ### How can I add something to the roadmap?
    25  
    26  The roadmap process is new to the Docker Engine: we are only beginning to structure and document the
    27  project objectives. Our immediate goal is to be more transparent, and work with our community to
    28  focus our efforts on fewer prioritized topics.
    29  
    30  We hope to offer in the near future a process allowing anyone to propose a topic to the roadmap, but
    31  we are not quite there yet. For the time being, the BDFL remains the keeper of the roadmap, and we
    32  won't be accepting pull requests adding or removing items from this file.
    33  
    34  # 1. Features and refactoring
    35  
    36  ## 1.1 Runtime improvements
    37  
    38  We recently introduced [`runC`](https://runc.io) as a standalone low-level tool for container
    39  execution. The initial goal was to integrate runC as a replacement in the Engine for the traditional
    40  default libcontainer `execdriver`, but the Engine internals were not ready for this.
    41  
    42  As runC continued evolving, and the OCI specification along with it, we created
    43  [`containerd`](https://containerd.tools/), a daemon to control and monitor multiple `runC`. This is
    44  the new target for Engine integration, as it can entirely replace the whole `execdriver`
    45  architecture, and container monitoring along with it.
    46  
    47  Docker Engine will rely on a long-running `containerd` companion daemon for all container execution
    48  related operations. This could open the door in the future for Engine restarts without interrupting
    49  running containers.
    50  
    51  ## 1.2 Plugins improvements
    52  
    53  Docker Engine 1.7.0 introduced plugin support, initially for the use cases of volumes and networks
    54  extensions. The plugin infrastructure was kept minimal as we were collecting use cases and real
    55  world feedback before optimizing for any particular workflow.
    56  
    57  In the future, we'd like plugins to become first class citizens, and encourage an ecosystem of
    58  plugins. This implies in particular making it trivially easy to distribute plugins as containers
    59  through any Registry instance, as well as solving the commonly heard pain points of plugins needing
    60  to be treated as somewhat special (being active at all time, started before any other user
    61  containers, and not as easily dismissed).
    62  
    63  ## 1.3 Internal decoupling
    64  
    65  A lot of work has been done in trying to decouple the Docker Engine's internals. In particular, the
    66  API implementation has been refactored and ongoing work is happening to move the code to a separate
    67  repository ([`docker/engine-api`](https://github.com/docker/engine-api)), and the Builder side of
    68  the daemon is now [fully independent](https://github.com/docker/docker/tree/master/builder) while
    69  still residing in the same repository.
    70  
    71  We are exploring ways to go further with that decoupling, capitalizing on the work introduced by the
    72  runtime renovation and plugins improvement efforts. Indeed, the combination of `containerd` support
    73  with the concept of "special" containers opens the door for bootstrapping more Engine internals
    74  using the same facilities.
    75  
    76  ## 1.4 Cluster capable Engine
    77  
    78  The community has been pushing for a more cluster capable Docker Engine, and a huge effort was spent
    79  adding features such as multihost networking, and node discovery down at the Engine level. Yet, the
    80  Engine is currently incapable of taking scheduling decisions alone, and continues relying on Swarm
    81  for that.
    82  
    83  We plan to complete this effort and make Engine fully cluster capable. Multiple instances of the
    84  Docker Engine being already capable of discovering each other and establish overlay networking for
    85  their container to communicate, the next step is for a given Engine to gain ability to dispatch work
    86  to another node in the cluster. This will be introduced in a backward compatible way, such that a
    87  `docker run` invocation on a particular node remains fully deterministic.
    88  
    89  # 2 Frozen features
    90  
    91  ## 2.1 Docker exec
    92  
    93  We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a
    94  *debugging* feature, as well as being strongly dependent on the Runtime ingredient effort.
    95  
    96  ## 2.2 Dockerfile syntax
    97  
    98  The Dockerfile syntax as we know it is simple, and has proven successful in supporting all our
    99  [official images](https://github.com/docker-library/official-images). Although this is *not* a
   100  definitive move, we temporarily won't accept more patches to the Dockerfile syntax for several
   101  reasons:
   102  
   103    - Long term impact of syntax changes is a sensitive matter that require an amount of attention the
   104      volume of Engine codebase and activity today doesn't allow us to provide.
   105    - Allowing the Builder to be implemented as a separate utility consuming the Engine's API will
   106      open the door for many possibilities, such as offering alternate syntaxes or DSL for existing
   107      languages without cluttering the Engine's codebase.
   108    - A standalone Builder will also offer the opportunity for a better dedicated group of maintainers
   109      to own the Dockerfile syntax and decide collectively on the direction to give it.
   110    - Our experience with official images tend to show that no new instruction or syntax expansion is
   111      *strictly* necessary for the majority of use cases, and although we are aware many things are
   112      still lacking for many, we cannot make it a priority yet for the above reasons.
   113  
   114  Again, this is not about saying that the Dockerfile syntax is done, it's about making choices about
   115  what we want to do first!
   116  
   117  ## 2.3 Remote Registry Operations
   118  
   119  A large amount of work is ongoing in the area of image distribution and provenance. This includes
   120  moving to the V2 Registry API and heavily refactoring the code that powers these features. The
   121  desired result is more secure, reliable and easier to use image distribution.
   122  
   123  Part of the problem with this part of the code base is the lack of a stable and flexible interface.
   124  If new features are added that access the registry without solidifying these interfaces, achieving
   125  feature parity will continue to be elusive. While we get a handle on this situation, we are imposing
   126  a moratorium on new code that accesses the Registry API in commands that don't already make remote
   127  calls.
   128  
   129  Currently, only the following commands cause interaction with a remote registry:
   130  
   131    - push
   132    - pull
   133    - run
   134    - build
   135    - search
   136    - login
   137  
   138  In the interest of stabilizing the registry access model during this ongoing work, we are not
   139  accepting additions to other commands that will cause remote interaction with the Registry API. This
   140  moratorium will lift when the goals of the distribution project have been met.