github.com/lalkh/containerd@v1.4.3/reports/2017-02-10.md (about)

     1  # Development Report for Feb 10, 2017
     2  
     3  Sorry for slacking off last week on the report.  We totally spaced it.
     4  This week we will go over what happened last week and this week.
     5  
     6  ## Snapshot Design Changes
     7  
     8  * https://github.com/containerd/containerd/pull/496
     9  
    10  After receiving feedback on the `snapshot.Driver` interface, now known as the
    11  `Snapshotter`, it was found that the behavior of active and committed snapshots
    12  was confusing.  Specifically, it was hard to tell which methods to use based on
    13  the state of the snapshot. It was also confusing which identifier to use based
    14  on the state.
    15  
    16  To clean this up, we moved to using "Active" and "Committed" as the type of a
    17  snapshot, as opposed to the state of the snapshot. These lifecycle
    18  relationships are such that "Active" snapshots can only be created from a
    19  "Committed" snapshot and "Committed" snapshots must come from an "Active"
    20  snapshot. We retain the concept of a parent for "Active" and "Committed"
    21  snapshots, but clarified that only "Committed" snapshots can be a parent.
    22  
    23  
    24  As part of this, we unified the keyspace of snapshots. For common operations,
    25  such as removal and stat, we only have a single method that works for both
    26  active and committed snapshots. For methods that take one or the other, the
    27  restriction is called out. `Remove` and `Delete` were consolidated as part of
    28  this. This also makes it easier to handle scenarios that use the snapshot
    29  identity as a lock to coordinate multiple writers.
    30  
    31  `Exists` and `Parent` have also be consolidated into single `Stat` call. This
    32  returns an `Info` structure which includes information about state and
    33  parentage. We also simplify the `Walk` method as part of this.
    34  
    35  Effectively, we now have snapshots that are either active or committed and a
    36  much smaller interface!
    37  
    38  ## Bundles Bundles Bundles
    39  
    40  We spend time talking with people implementing Windows support as well as a few other users.
    41  One the major issues with our current approach was that bundles were a central part of our architecture.
    42  The content and storage subsystems would produce bundles and the execution subsystem would consume them.
    43  However, with a bundle being on the filesystem, having this concept does not work as smoothly on Windows
    44  as it would for Unix platforms.
    45  
    46  So the major design change is that bundles will be an implementation detail of the runtime and not a core
    47  part of the API.  You will no longer pass the bundle path to containerd, it will manage bundles internally
    48  and the root filesystem mounts along with the spec, passed via the `Any` type, will be API fields for the 
    49  create request of a container.
    50  
    51  ## Runtimes
    52  
    53  With the bundles change above we also need to make sure changes for where containers are created and who
    54  does the supervision after creation.
    55  
    56  The runtimes in containerd, things such as Linux, Windows, and Solaris, will be responsible for the 
    57  creation of containers and loading of containers when containerd boots.
    58  
    59  The containerd core will be responsible for interfacing with the GRPC API and managing a common `Container` 
    60  interface that the runtimes produce.  The supervision of containers will be handled in the core. 
    61  This is not much of a change from today, just refining where responsibilities lie. 
    62  
    63  ## Progress and POC
    64  
    65  Overall design has been a large focus for us at the moment.  While containerd can run containers today it 
    66  is not optimized in terms of speed or design.  With the work we did this week to make sure that containerd 
    67  will work across many different platforms with first class support, not as an after thought, we are in a good 
    68  position to really start on the development work and get a POC out within the next few weeks.  
    69  
    70  This POC should give you a good idea of what containerd can do, its APIs, and how users will interact with
    71  its various subsystems.