Update the Roadmap

As part of the Moby transition (see moby#35115), update the Roadmap to
reflect the new priorities. Also just update it as it was written
a while back, and we made some progress in areas such as `containerd`.

Signed-off-by: Justin Cormack <[email protected]>

Author: justincormack

ROADMAP.md

@@ -1,118 +1,68 @@
-Docker Engine Roadmap
-=====================
+Moby Project Roadmap
+====================
 
 ### How should I use this document?
 
 This document provides description of items that the project decided to prioritize. This should
-serve as a reference point for Docker contributors to understand where the project is going, and
-help determine if a contribution could be conflicting with some longer terms plans.
+serve as a reference point for Moby contributors to understand where the project is going, and
+help determine if a contribution could be conflicting with some longer term plans.
 
 The fact that a feature isn't listed here doesn't mean that a patch for it will automatically be
-refused (except for those mentioned as "frozen features" below)! We are always happy to receive
-patches for new cool features we haven't thought about, or didn't judge priority. Please however
-understand that such patches might take longer for us to review.
+refused! We are always happy to receive patches for new cool features we haven't thought about,
+or didn't judge to be a priority. Please however understand that such patches might take longer
+for us to review.
 
 ### How can I help?
 
-Short term objectives are listed in the [wiki](https://github.com/docker/docker/wiki) and described
-in [Issues](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our
+Short term objectives are listed in
+[Issues](https://github.com/moby/moby/issues?q=is%3Aopen+is%3Aissue+label%3Aroadmap). Our
 goal is to split down the workload in such way that anybody can jump in and help. Please comment on
-issues if you want to take it to avoid duplicating effort! Similarly, if a maintainer is already
-assigned on an issue you'd like to participate in, pinging him on IRC or GitHub to offer your help is
+issues if you want to work on it to avoid duplicating effort! Similarly, if a maintainer is already
+assigned on an issue you'd like to participate in, pinging him on GitHub to offer your help is
 the best way to go.
 
 ### How can I add something to the roadmap?
 
-The roadmap process is new to the Docker Engine: we are only beginning to structure and document the
+The roadmap process is new to the Moby Project: we are only beginning to structure and document the
 project objectives. Our immediate goal is to be more transparent, and work with our community to
 focus our efforts on fewer prioritized topics.
 
 We hope to offer in the near future a process allowing anyone to propose a topic to the roadmap, but
-we are not quite there yet. For the time being, the BDFL remains the keeper of the roadmap, and we
-won't be accepting pull requests adding or removing items from this file.
+we are not quite there yet. For the time being, it is best to discuss with the maintainers on an
+issue, in the Slack channel, or in person at the Moby Summits that happen every few months.
 
 # 1. Features and refactoring
 
 ## 1.1 Runtime improvements
 
-We recently introduced [`runC`](https://runc.io) as a standalone low-level tool for container
-execution. The initial goal was to integrate runC as a replacement in the Engine for the traditional
-default libcontainer `execdriver`, but the Engine internals were not ready for this.
+We introduced [`runC`](https://runc.io) as a standalone low-level tool for container
+execution in 2015, the first stage in spinning out parts of the Engine into standalone tools.
 
 As runC continued evolving, and the OCI specification along with it, we created
-[`containerd`](https://containerd.tools/), a daemon to control and monitor multiple `runC`. This is
-the new target for Engine integration, as it can entirely replace the whole `execdriver`
-architecture, and container monitoring along with it.
+[`containerd`](https://github.com/containerd/containerd), a daemon to control and monitor `runC`.
+In late 2016 this was relaunched as the `containerd` 1.0 track, aiming to provide a common runtime
+for the whole spectrum of container systems, including Kubernetes, with wide community support.
+This change meant that there was an increased scope for `containerd`, including image management
+and storage drivers.
 
-Docker Engine will rely on a long-running `containerd` companion daemon for all container execution
+Moby will rely on a long-running `containerd` companion daemon for all container execution
 related operations. This could open the door in the future for Engine restarts without interrupting
-running containers.
+running containers. The switch over to containerd 1.0 is an important goal for the project, and
+will result in a significant simplification of the functions implemented in this repository.
 
-## 1.2 Plugins improvements
+## 1.2 Internal decoupling
 
-Docker Engine 1.7.0 introduced plugin support, initially for the use cases of volumes and networks
-extensions. The plugin infrastructure was kept minimal as we were collecting use cases and real
-world feedback before optimizing for any particular workflow.
+A lot of work has been done in trying to decouple Moby internals. This process of creating
+standalone projects with a well defined function that attract a dedicated community should continue.
+As well as integrating `containerd` we would like to integrate [BuildKit](https://github.com/moby/buildkit)
+as the next standalone component.
 
-In the future, we'd like plugins to become first class citizens, and encourage an ecosystem of
-plugins. This implies in particular making it trivially easy to distribute plugins as containers
-through any Registry instance, as well as solving the commonly heard pain points of plugins needing
-to be treated as somewhat special (being active at all time, started before any other user
-containers, and not as easily dismissed).
+We see gRPC as the natural communication layer between decoupled components.
 
-## 1.3 Internal decoupling
+## 1.3 Custom assembly tooling
 
-A lot of work has been done in trying to decouple the Docker Engine's internals. In particular, the
-API implementation has been refactored, and the Builder side of the daemon is now
-[fully independent](https://github.com/docker/docker/tree/master/builder) while still residing in
-the same repository.
-
-We are exploring ways to go further with that decoupling, capitalizing on the work introduced by the
-runtime renovation and plugins improvement efforts. Indeed, the combination of `containerd` support
-with the concept of "special" containers opens the door for bootstrapping more Engine internals
-using the same facilities.
-
-## 1.4 Cluster capable Engine
-
-The community has been pushing for a more cluster capable Docker Engine, and a huge effort was spent
-adding features such as multihost networking, and node discovery down at the Engine level. Yet, the
-Engine is currently incapable of taking scheduling decisions alone, and continues relying on Swarm
-for that.
-
-We plan to complete this effort and make Engine fully cluster capable. Multiple instances of the
-Docker Engine being already capable of discovering each other and establish overlay networking for
-their container to communicate, the next step is for a given Engine to gain ability to dispatch work
-to another node in the cluster. This will be introduced in a backward compatible way, such that a
-`docker run` invocation on a particular node remains fully deterministic.
-
-# 2. Frozen features
-
-## 2.1 Docker exec
-
-We won't accept patches expanding the surface of `docker exec`, which we intend to keep as a
-*debugging* feature, as well as being strongly dependent on the Runtime ingredient effort.
-
-## 2.2 Remote Registry Operations
-
-A large amount of work is ongoing in the area of image distribution and provenance. This includes
-moving to the V2 Registry API and heavily refactoring the code that powers these features. The
-desired result is more secure, reliable and easier to use image distribution.
-
-Part of the problem with this part of the code base is the lack of a stable and flexible interface.
-If new features are added that access the registry without solidifying these interfaces, achieving
-feature parity will continue to be elusive. While we get a handle on this situation, we are imposing
-a moratorium on new code that accesses the Registry API in commands that don't already make remote
-calls.
-
-Currently, only the following commands cause interaction with a remote registry:
-
-  - push
-  - pull
-  - run
-  - build
-  - search
-  - login
-
-In the interest of stabilizing the registry access model during this ongoing work, we are not
-accepting additions to other commands that will cause remote interaction with the Registry API. This
-moratorium will lift when the goals of the distribution project have been met.
+We have been prototyping the Moby [assembly tool](https://github.com/moby/tool) which was originally
+developed for LinuxKit and intend to turn it into a more generic packaging and assembly mechanism
+that can build not only the default version of Moby, as distribution packages or other useful forms,
+but can also build very different container systems, themselves built of cooperating daemons built in
+and running in containers. We intend to merge this functionality into this repo.