github.com/rumpl/bof@v23.0.0-rc.2+incompatible/ROADMAP.md (about)

     1  Moby Project 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 Moby contributors to understand where the project is going, and
     8  help determine if a contribution could be conflicting with some longer term 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! We are always happy to receive patches for new cool features we haven't thought about,
    12  or didn't judge to be a priority. Please however understand that such patches might take longer
    13  for us to review.
    14  
    15  ### How can I help?
    16  
    17  Short term objectives are listed in
    18  [Issues](https://github.com/moby/moby/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 work on 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 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 Moby Project: 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, it is best to discuss with the maintainers on an
    32  issue, in the Slack channel, or in person at the Moby Summits that happen every few months.
    33  
    34  # 1. Features and refactoring
    35  
    36  ## 1.1 Runtime improvements
    37  
    38  Over time we have accumulated a lot of functionality in the container runtime
    39  aspect of Moby while also growing in other areas. Much of the container runtime
    40  pieces are now duplicated work available in other, lower level components such
    41  as [containerd](https://containerd.io).
    42  
    43  Moby currently only utilizes containerd for basic runtime state management, e.g. starting
    44  and stopping a container, which is what the pre-containerd 1.0 daemon provided.
    45  Now that containerd is a full-fledged container runtime which supports full
    46  container life-cycle management, we would like to start relying more on containerd
    47  and removing the bits in Moby which are now duplicated. This will necessitate
    48  a significant effort to refactor and even remove large parts of Moby's codebase.
    49  
    50  Tracking issues:
    51  
    52  - [#38043](https://github.com/moby/moby/issues/38043) Proposal: containerd image integration
    53  
    54  ## 1.2 Image Builder
    55  
    56  Work is ongoing to integrate [BuildKit](https://github.com/moby/buildkit) into
    57  Moby and replace the "v0" build implementation. Buildkit offers better cache
    58  management, parallelizable build steps, and better extensibility while also
    59  keeping builds portable, a chief tenent of Moby's builder.
    60  
    61  Upon completion of this effort, users will have a builder that performs better
    62  while also being more extensible, enabling users to provide their own custom
    63  syntax which can be either Dockerfile-like or something completely different.
    64  
    65  See [buildpacks on buildkit](https://github.com/tonistiigi/buildkit-pack) as an
    66  example of this extensibility.
    67  
    68  New features for the builder and Dockerfile should be implemented first in the
    69  BuildKit backend using an external Dockerfile implementation from the container
    70  images. This allows everyone to test and evaluate the feature without upgrading
    71  their daemon. New features should go to the experimental channel first, and can be
    72  part of the `docker/dockerfile:experimental` image. From there they graduate to
    73  `docker/dockerfile:latest` and binary releases. The Dockerfile frontend source
    74  code is temporarily located at
    75  [https://github.com/moby/buildkit/tree/master/frontend/dockerfile](https://github.com/moby/buildkit/tree/master/frontend/dockerfile)
    76  with separate new features defined with go build tags.
    77  
    78  Tracking issues:
    79  
    80  - [#32925](https://github.com/moby/moby/issues/32925) discussion: builder future: buildkit
    81  
    82  ## 1.3 Rootless Mode
    83  
    84  Running the daemon requires elevated privileges for many tasks. We would like to
    85  support running the daemon as a normal, unprivileged user without requiring `suid`
    86  binaries.
    87  
    88  Tracking issues:
    89  
    90  - [#37375](https://github.com/moby/moby/issues/37375) Proposal: allow running `dockerd` as an unprivileged user (aka rootless mode)
    91  
    92  ## 1.4 Testing
    93  
    94  Moby has many tests, both unit and integration. Moby needs more tests which can
    95  cover the full spectrum functionality and edge cases out there.
    96  
    97  Tests in the `integration-cli` folder should also be migrated into (both in
    98  location and style) the `integration` folder. These newer tests are simpler to
    99  run in isolation, simpler to read, simpler to write, and more fully exercise the
   100  API. Meanwhile tests of the docker CLI should generally live in docker/cli.
   101  
   102  Tracking issues:
   103  
   104  - [#32866](https://github.com/moby/moby/issues/32866) Replace integration-cli suite with API test suite
   105  
   106  ## 1.5 Internal decoupling
   107  
   108  A lot of work has been done in trying to decouple Moby internals. This process of creating
   109  standalone projects with a well defined function that attract a dedicated community should continue.
   110  As well as integrating `containerd` we would like to integrate [BuildKit](https://github.com/moby/buildkit)
   111  as the next standalone component.
   112  We see gRPC as the natural communication layer between decoupled components.
   113  
   114  In addition to pushing out large components into other projects, much of the
   115  internal code structure, and in particular the
   116  ["Daemon"](https://godoc.org/github.com/docker/docker/daemon#Daemon) object,
   117  should be split into smaller, more manageable, and more testable components.