vbatts/containerd
1
0
Fork 0
Code Pull requests Releases Activity

Rewrite imports for new github org

Browse source 
This rewrites the Go imports after switching to the new github org.

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This commit is contained in:
Michael Crosby 2017-04-03 13:14:15 -07:00
parent 0521958ac0
commit 4f2b443a27
101 changed files with 540 additions and 543 deletions
Download patch file Download diff file Expand all files Collapse all files

12
reports/2017-01-13.md
View file

@ -8,8 +8,8 @@ I wanted to try something different for this project during its development by g
This week we merged PRs adding a quick start guide with build instructions to help get new contributors onboard quicker. We also merged a vendoring PR so everyone has the same revision of packages for the project. It can add a little burden on development having vendoring at this early stage, especially the way we have to do vendoring in Go, but it ensures that everyone contributing has a consistent environment.
* https://github.com/docker/containerd/pull/400
* https://github.com/docker/containerd/pull/390
* https://github.com/containerd/containerd/pull/400
* https://github.com/containerd/containerd/pull/390
## Milestones
@ -19,7 +19,7 @@ We are currently in the bootstrap phase. Much of the design work, getting the p
The milestones will give you the most up-to-date view on the project and what is being worked on when.
* https://github.com/docker/containerd/milestones
* https://github.com/containerd/containerd/milestones
## Networking
@ -29,18 +29,18 @@ Networking means many different things today and is becoming more software based
I personally feel like this is a good move for the project. We have good primitives at the runtime level with the create/start split that allows a container's network namespace to be created and time for a network plugin to create and add interfaces to the container before the user's process is started. We also have the ability for containers to join pre-existing network namespaces that have already been populated by a networking implementation.
* https://github.com/docker/containerd/issues/362
* https://github.com/containerd/containerd/issues/362
## Runtime and Shim
We finished porting over the shim from the existing containerd implementation that is being used today. This makes sure that the containers are not tied to the daemon's lifecycle. This allows containerd to reattach to the STDIO and receive exit events for the containers when it is no longer the parent of these processes.
* https://github.com/docker/containerd/pull/417
* https://github.com/containerd/containerd/pull/417
## Whats Next?
Next week we will be working towards a full PoC with the runtime, storage, and fetching of images. Getting the core functionality up and running quickly is important to us to ensure that integration between the different subsystems in the core flow well together. We want to make sure the responsibilities of pulling an image from a remote source do not spill into the storage layer and vice-versa.
We still have more documentation work to do on the design and lifecycle of components in the core which is another focus for next week. You can find the current design docs in the [repo here](https://github.com/docker/containerd/tree/master/design).
We still have more documentation work to do on the design and lifecycle of components in the core which is another focus for next week. You can find the current design docs in the [repo here](https://github.com/containerd/containerd/tree/master/design).
I hope this status report helps. If you are looking for ways to contribute, check out the issues on the current milestone.

2
reports/2017-01-20.md
View file

@ -6,7 +6,7 @@ This week we worked on refactoring the storage and runtime aspects of containerd
@stevvooe started work on a `dist` tool for fetching images and other distribution aspects. One of the problems we wanted to solve with containerd is the ability to decouple the fetch of image contents, the unpacking of the contents, and the storage of the contents. Separating these lets us download content as non-root on machines and only elevate privileges when the contents need to be unpacked on disk.
* https://github.com/docker/containerd/pull/452
* https://github.com/containerd/containerd/pull/452
## Shim Work

12
reports/2017-01-27.md
View file

@ -9,7 +9,7 @@ container-shim, which is used for robust container management.
## Maintainers
* https://github.com/docker/containerd/pull/473
* https://github.com/containerd/containerd/pull/473
Derek McGowan will be joining the containerd team as a maintainer. His
extensive experience in graphdrivers and distribution will be invaluable to the
@ -17,7 +17,7 @@ containerd project.
## Shim over GRPC
* https://github.com/docker/containerd/pull/462
* https://github.com/containerd/containerd/pull/462
```
NAME:
@ -86,9 +86,9 @@ events, start containers, start exec processes.
## Distribution Tool
* https://github.com/docker/containerd/pull/452
* https://github.com/docker/containerd/pull/472
* https://github.com/docker/containerd/pull/474
* https://github.com/containerd/containerd/pull/452
* https://github.com/containerd/containerd/pull/472
* https://github.com/containerd/containerd/pull/474
Last week, @stevvooe committed the first parts of the distribution tool. The main
component provided there was the `dist fetch` command. This has been followed
@ -221,7 +221,7 @@ To get access to the layers, you can use the path command:
```
$./dist path sha256:010c454d55e53059beaba4044116ea4636f8dd8181e975d893931c7e7204fffa
sha256:010c454d55e53059beaba4044116ea4636f8dd8181e975d893931c7e7204fffa /home/sjd/go/src/github.com/docker/containerd/.content/blobs/sha256/010c454d55e53059beaba4044116ea4636f8dd8181e975d893931c7e7204fffa
sha256:010c454d55e53059beaba4044116ea4636f8dd8181e975d893931c7e7204fffa /home/sjd/go/src/github.com/containerd/containerd/.content/blobs/sha256/010c454d55e53059beaba4044116ea4636f8dd8181e975d893931c7e7204fffa
```
This returns the a direct path to the blob to facilitate fast access. We can

2
reports/2017-02-10.md
View file

@ -5,7 +5,7 @@ This week we will go over what happened last week and this week.
## Snapshot Design Changes
* https://github.com/docker/containerd/pull/496
* https://github.com/containerd/containerd/pull/496
After receiving feedback on the `snapshot.Driver` interface, now known as the
`Snapshotter`, it was found that the behavior of active and committed snapshots

2
reports/2017-02-24.md
View file

@ -46,7 +46,7 @@ These are just simple examples and much of the format will be left up to the cli
Looking at the latest Go 1.8 release plugins looked like a perfect solution for extending containerd by third parties. However, after discussions at the summit and with help from Tim to get clarification on the feature from the Go team it does not not look very promising in terms of implementation. We currently have the code for plugins via go 1.8 merged into master but we will have to rethink our extension method going forward.
https://github.com/docker/containerd/issues/563
https://github.com/containerd/containerd/issues/563
## Storage and Distribution Breakout Session

10
reports/2017-03-10.md
View file

@ -19,11 +19,11 @@ package main
// register containerd builtins here
import (
_ "github.com/docker/containerd/linux"
_ "github.com/docker/containerd/services/content"
_ "github.com/docker/containerd/services/execution"
_ "github.com/docker/containerd/snapshot/btrfs"
_ "github.com/docker/containerd/snapshot/overlay"
_ "github.com/containerd/containerd/linux"
_ "github.com/containerd/containerd/services/content"
_ "github.com/containerd/containerd/services/execution"
_ "github.com/containerd/containerd/snapshot/btrfs"
_ "github.com/containerd/containerd/snapshot/overlay"
)
```

4
reports/2017-03-17.md
View file

@ -6,7 +6,7 @@ Thanks to @gianarb for starting the discussion around a test and CI plan for con
Testing a project like containerd is always a challenge because of the systems that it needs to support. ARM, Windows, Linux, and Power (as well as many more variations) are all examples of platforms that we support today and will need a CI.
You can view the issue and contribute to the testing plan [here](https://github.com/docker/containerd/issues/634).
You can view the issue and contribute to the testing plan [here](https://github.com/containerd/containerd/issues/634).
## Windows Runtime
@ -104,7 +104,7 @@ There should be a PR up soon so that we can discuss the metrics and label names.
## Image Pull
* https://github.com/docker/containerd/pull/640
* https://github.com/containerd/containerd/pull/640
We now have a proof of concept of end to end pull. Up to this point, the
relationship between subsystems has been somewhat theoretical. We now leverage

8
reports/2017-03-24.md
View file

@ -2,7 +2,7 @@
## Container Level Metrics
* https://github.com/docker/containerd/pull/646
* https://github.com/containerd/containerd/pull/646
We merged a PR to add our first pass of container level metrics to our
prometheus output in containerd. We still have to review the metric names and
@ -18,7 +18,7 @@ and figure out where the implementation gaps are.
### Image to OCI Spec
* https://github.com/docker/containerd/pull/660
* https://github.com/containerd/containerd/pull/660
We merged support for getting an image config that was pulled off of a registry
and generating a spec based on the image properties in the `ctr` command. This
@ -39,7 +39,7 @@ sudo ctr run --id redis -t docker.io/library/redis:alpine
### Image handlers
* https://github.com/docker/containerd/pull/638
* https://github.com/containerd/containerd/pull/638
We refactored the fetch command into a more generic image handler interface. As
we look forward to supporting the full oci image spec as well as the Docker
@ -56,7 +56,7 @@ docker.io/library/redis:latest application/vnd.docker.distribution.manif
## Snapshot driver improvements
* https://github.com/docker/containerd/pull/635
* https://github.com/containerd/containerd/pull/635
The `overlay` and `btrfs` driver implementations are now fully implemented and
share an implementation for metadata storage. This new metadata storage package