-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add create-layer sub command to create filesystem changeset #8
base: master
Are you sure you want to change the base?
Conversation
On Sat, Sep 17, 2016 at 09:05:40PM -0700, Lei Jitang wrote:
This pulls in the Linux → *Linux change from |
On Sat, Sep 17, 2016 at 09:05:40PM -0700, Lei Jitang wrote:
Pulling in containers/storage is much better than pulling in all of
Now just oci-create-layer. And you should add an |
} | ||
|
||
cmd := &cobra.Command{ | ||
Use: "create-layer [child] [parent]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably write the layer tar to stdout unless the user sets an option to write to a particular filename.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will write the layer tar to the pwd
.
Add an option to write to a particular filename is under working
// layer and its parent layer which may be "". | ||
func Diff(child, parent string) (arch archive.Archive, err error) { | ||
if parent == "" { | ||
archive, err := archive.Tar(child, archive.Uncompressed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current image-spec requires gzipped layers, although there is some talk of weakening that in opencontainers/image-spec#316 (I'm in favor of making compression optional).
I just want to avoid updating other packages when run
This is under working |
On Sat, Sep 17, 2016 at 11:20:18PM -0700, Lei Jitang wrote:
I think you can just roll back the packages you don't want to bump |
@wking thanks :) |
@coolljt0725 can't you just require a specific version of a library in glide.yaml? What's the point if having a field named version if we have to git reset and checkout what we don't need.. |
On Sun, Sep 18, 2016 at 12:23:48AM -0700, Antonio Murdaca wrote:
Ah, there's a config file for this thing? ;). That's definitely a |
187382c
to
664b97f
Compare
I am very up for sharing a single unpacking implementation! I am not sure if this implementation should live outside of an Also, having to pull the whole containers/storage and its dependencies in image-tools makes me a bit sad as it's way more than what we need. |
On 20/09/16 05:53 -0700, George Lestaris wrote:
This is the intention of having this repo in the opencontainers org.
perhaps there is a way to trim down that vendoring, such that only the |
@vbatts let me try to become more specific. Once this PR is accepted we will be using This is unfortunately asymmetric. So I am worried that the natural next step would be to use I may be overthinking this but it feels strange to see the layer creation be implemented in a different place than the layer unpacking. |
On Tue, Sep 20, 2016 at 09:53:40AM -0700, George Lestaris wrote:
I don't think it really matters where the reference implementation
I agree. |
@glestaris I'm agree what you said, I working on implementing the |
e76f92a
to
a8bafa4
Compare
update without vendorring third-party package except |
@@ -0,0 +1,283 @@ | |||
// Copyright 2016 The Linux Foundation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably want to revisit this header, especially if we're going to be copying large chunks of files from places like docker/docker's pkg/archive/changes.go
where the Linux Foundation is clearly not the primary copyright holder. How about:
Copyright 2016 The Linux Foundation and contributors
with the emphasis for this file being on “and contributors” ;).
And I'm still not wild about either forking these packages (like you're doing here) or vendoring huge external dependencies (like you were doing before). Is there really no interest inside Docker for moving this package out into a stand-alone docker/archive repository? Or in handing that off to us to develop as opencontainers/archive? I don't see docker/docker including github.com/opencontainers/image-tools/image to get this functionality back, but the other two solutions sound like they have a chance.
please rebase and address the |
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
Signed-off-by: Lei Jitang <[email protected]>
**oci-create-layer** [child] [parent] [flags] | ||
|
||
# DESCRIPTION | ||
`oci-create-layer` creates a filesystem changeset from two layers. It compares child with parent and generates a filsystem diff, pack the diff into a uncompressed tar archive. The output tar archive name is the child name with .tar suffix by default, use `--dest` to specify a custom one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we write to stdout by default? Then with #5 you could:
$ oci-create-layer child-dir parent-dir | gzip | oci-cas put image-layout-dir
to push a layer into CAS without landing the uncompressed layer tarball on the disk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wking How about write to the stdout by default and use --dest
to specify a custom destination?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that sounds good to me. Although I think --output
is a more popular name for this sort of thing than --dest
.
|
||
// CreateLayer cretes filesystem changset from child and parent | ||
func CreateLayer(child, parent, dest string) error { | ||
arch, err := Diff(child, parent) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would somewhat like to use @vbatts' go-mtree here. To be fair, I've been slacking on the required PRs to implement it, but would you be open to switching to go-mtree once it's up to snuff? The main benefit is that it has far more explicit design constraints about reproducibility and manifest verifiability than pkg/archive
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cyphar The main purpose to use pkg/archive
is it's well tested and have been used for a long time on docker. I'm personally ok to try to switch to go-mtree once it's up to snuff, but others may have different thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another benefit of go-mtree that I forgot to mention is that you could make it possible to create layers without needing to keep two copies of the tree -- since mtree generates a manifest that you can compare against. So you could do something like:
% go-mtree -c -K sha256sum -p rootfs/ > before.mtree
% # modify the rootfs
% oci-image-tool --base before.mtree rootfs > layer.tar
Signed-off-by: Lei Jitang <[email protected]>
I've been playing with this for a while, it works pretty nice (especially with the CAS PR). I'm going to write a PR after this is merged to use go-mtree. |
`oci-image-tool create` is confusing, rename it to `create-bundle`, and we may have `create-layer` in future which infligh in opencontainers#8, and we may have `create-image` in future. Signed-off-by: Lei Jitang <[email protected]>
`oci-image-tool create` is confusing, rename it to `create-bundle`, and we may have `create-layer` in future which is infligh in opencontainers#8 and we may have `create-image` in future. Signed-off-by: Lei Jitang <[email protected]>
Can you rebase this pr? |
This PR use a well tested pkg from github.com/containers/storage(which is forked from docker/docker)
from opencontainers/image-spec#280
here is an example: