github/containerd
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

Fix sublist in dev report

Browse Source 
Also clean up some typos

Signed-off-by: Derek McGowan <derek@mcgstyle.net>
This commit is contained in:
Derek McGowan 2017-06-26 10:53:27 -07:00
parent a962ac9909
commit 21b0f1e285
No known key found for this signature in database
GPG Key ID: F58C5D0A4405ACDB
1 changed files with 29 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
reports/2017-06-23.md
View File

@ -28,7 +28,7 @@ $ ctr events
We added the syntax to use for filtration of items over the containerd API. The
`filter` package defines a syntax and parser that can be used across types and
use cases in a uniform manner. This will be used commonly across the api for
use cases in a uniform manner. This will be used commonly across the API for
images, containers, events, snapshots, etc.
The syntax is fairly familiar, if you've used container ecosystem
@ -78,7 +78,7 @@ the label `bar`:
name==foo,labels.bar
```
[#995: Add packge for filters](https://github.com/containerd/containerd/pull/995)
[#995: Add package for filters](https://github.com/containerd/containerd/pull/995)
[#1050: Container list filters](https://github.com/containerd/containerd/pull/1050)
@ -98,7 +98,7 @@ We added `ctr snapshot list` to snapshots from containerd. This will output all
snapshots, not just the active snapshots used by containers.
```
ctr snapshot list
$ ctr snapshot list
ID Parent State Readonly
registry2 sha256:dc22a13eb565d14bfe2b16f6fa731a05da0eeff02a52059c7b59cdc2c232a2b2 active false
registry3 sha256:dc22a13eb565d14bfe2b16f6fa731a05da0eeff02a52059c7b59cdc2c232a2b2 active false
@ -116,17 +116,17 @@ sha256:dc22a13eb565d14bfe2b16f6fa731a05da0eeff02a52059c7b59cdc2c232a2b2 sha256:d
As part of our API review process we have started implementing some changes to
make the API clearer and more consistent.
[#1040: Update grpc APIs](https://github.com/containerd/containerd/pull/1040)
[#1040: Update GRPC APIs](https://github.com/containerd/containerd/pull/1040)
[#1047: Rename execution service to tasks](https://github.com/containerd/containerd/pull/1047)
[#1059: enforce a character set for namespaces](https://github.com/containerd/containerd/pull/1059)
[#1052: version protof service packages](https://github.com/containerd/containerd/pull/1062)
[#1052: version protobuf service packages](https://github.com/containerd/containerd/pull/1062)
[#1072: move events types into service package](https://github.com/containerd/containerd/pull/1072)
[#1073: consolidate api types packages](https://github.com/containerd/containerd/pull/1073)
[#1073: consolidate API types packages](https://github.com/containerd/containerd/pull/1073)
[#1074: replace whale with D](https://github.com/containerd/containerd/pull/1074)
@ -140,34 +140,34 @@ discussed and everyone is encouraged to open issues and engage the community on
Slack.
* "What are the plans for a resolver-resolver and image reference namespacing?"
- Maintainers are trying to figure out what everyone’s plans/needs are for a resolver-resolver.
- A resolver-resolver allows configuring where push/pull happens. Could take in a configuration format which specifies how to push, pull, and authenticate. Needed in order to do discover of names to registry configurations.
- Stephen confirms we are thinking of more configuration driven rather programmatic. The resolver-resolver and any configuration is always client side, allowing the integrator to design any interface or configuration suits their needs. But we are also looking to define something that could be consistently applied by containerd clients.
- The resolver-resolver will be compatible with Docker, but could allow Docker to expand its resolution support.
- Maintainers are trying to figure out what everyone’s plans/needs are for a resolver-resolver.
- A resolver-resolver allows configuring where push/pull happens. Could take in a configuration format which specifies how to push, pull, and authenticate. Needed in order to do discover of names to registry configurations.
- Stephen confirms we are thinking of more configuration driven rather programmatic. The resolver-resolver and any configuration is always client side, allowing the integrator to design any interface or configuration suits their needs. But we are also looking to define something that could be consistently applied by containerd clients.
- The resolver-resolver will be compatible with Docker, but could allow Docker to expand its resolution support.
* "What is the plan for garbage collection?"
- Current design is oriented around being garbage collected. The data model is designed around references which are used to walk a root set. Everything unreferenced would be garbage collected.
- Another more complicated aspect of garbage collection is around policy, allowing to clean up resources based on age or client specified policies.
- Client side implementations would allow establishing policies.
- Containerd will require a stop the world to do the garbage collection.
- A heavy delete which does not garbage collect is an option and similar to to the interface today. The API does not guarantee that disk is cleaned up after a deletion, only that the resource is freed. Inline deletion would require reference counting to know when to delete. This would also require global locking to protect the references.
- How to handle content which is active but unreferenced, leasing vs pre-allocate. This has not been decided on.
- Current design is oriented around being garbage collected. The data model is designed around references which are used to walk a root set. Everything unreferenced would be garbage collected.
- Another more complicated aspect of garbage collection is around policy, allowing to clean up resources based on age or client specified policies.
- Client side implementations would allow establishing policies.
- Containerd will require a stop the world to do the garbage collection.
- A heavy delete which does not garbage collect is an option and similar to to the interface today. The API does not guarantee that disk is cleaned up after a deletion, only that the resource is freed. Inline deletion would require reference counting to know when to delete. This would also require global locking to protect the references.
- How to handle content which is active but unreferenced, leasing vs pre-allocate. This has not been decided on.
* "What will need to change in Docker in regards to graphdrivers for accommodating the containerd snapshotters?"
- The goal is to have graphdrivers be able to be used as snapshot drivers.
- To accomplish this graphdrivers need to be able to return mounts without needing to require action on unmount. Unmount will no longer contact the graphdriver since snapshotters to do not control the mount/unmount lifecycle.
- For implementation, in the repository tree only overlayfs and btrfs are supported. Everything else will be out of tree and require special builds or proxying.
- The goal is to have graphdrivers be able to be used as snapshot drivers.
- To accomplish this graphdrivers need to be able to return mounts without needing to require action on unmount. Unmount will no longer contact the graphdriver since snapshotters to do not control the mount/unmount lifecycle.
- For implementation, in the repository tree only overlayfs and btrfs are supported. Everything else will be out of tree and require special builds or proxying.
* "Version numbers on events and API objects"
- Are objects mutable? Some objects are mutable but not necessarily relevant to clients.
- Are containers mutable? It can have multiple tasks, can be started and stopped.
- We may need to have task id separate from the container to differentiate between tasks within a container.
- Tasks have a pid which could be used to identify the task. Someone had a customer that ran out of memory from running too many tasks, could be caused by repeated execs in the same container.
- Getting state of a containers task involves requesting containers and tasks, or just tasks could be listed.
- What are the API costs, is there measurements of the cost of API calls and comparisons with Docker? Calling docker ps can be expensive due to locks, containerd should be much cheaper and faster to call. This need to be verified and measurements added.
- Are objects mutable? Some objects are mutable but not necessarily relevant to clients.
- Are containers mutable? It can have multiple tasks, can be started and stopped.
- We may need to have task id separate from the container to differentiate between tasks within a container.
- Tasks have a pid which could be used to identify the task. Someone had a customer that ran out of memory from running too many tasks, could be caused by repeated execs in the same container.
- Getting state of a containers task involves requesting containers and tasks, or just tasks could be listed.
- What are the API costs, is there measurements of the cost of API calls and comparisons with Docker? Calling docker ps can be expensive due to locks, containerd should be much cheaper and faster to call. This need to be verified and measurements added.
* "How can clients understand the capabilities of the containerd instance it is talking to?"
- As an orchestrator, interested in understanding what can be done with the plugins. Example, docker log drivers change feature set but the log driver names do not change. Stuck on checking docker version.
- There have been problems in the past with requiring multiple clients of docker to handle changes.
- GRPC is adding introspection, plan is to wait for this work rather than making something ourselves.
- The maintainers would like to understand what were the really bad changes in Docker that caused problems with version support for users. Problems around needing to bump the whole API to get a new feature. Containerd API versions each service and v1 interface will be stable and supported.
- As an orchestrator, interested in understanding what can be done with the plugins. Example, docker log drivers change feature set but the log driver names do not change. Stuck on checking docker version.
- There have been problems in the past with requiring multiple clients of docker to handle changes.
- GRPC is adding introspection, plan is to wait for this work rather than making something ourselves.
- The maintainers would like to understand what were the really bad changes in Docker that caused problems with version support for users. Problems around needing to bump the whole API to get a new feature. Containerd API versions each service and v1 interface will be stable and supported.