Add create-layer sub command to create filesystem changeset

[coolljt0725]

This PR use a well tested pkg from https://github.com/docker/docker/tree/master/pkg/archive
here is an example:

$ oci-image-tool create-layer
One or two filesystems are required
Usage:
  oci-image-tool create-layer [parent] [child] [flags]

Flags:
  -h, --help   help for create-layer

$ tree rootfs-1
rootfs-1
├── bin
│   ├── my-app
│   └── my-tool
└── etc
    └── my-tool-cfg

2 directories, 3 files
[lei@fedora test]$ oci-image-tool create-layer rootfs-1
[lei@fedora test]$ ls
rootfs-1  rootfs-1.tar
[lei@fedora test]$ vim rootfs-1.tar
" tar.vim version v29
" Browsing tarfile /home/lei/test/rootfs-1.tar
" Select a file with cursor and press ENTER

bin/
bin/my-app
bin/my-tool
etc/
etc/my-tool-cfg
~

[lei@fedora test]$ cp -par rootfs-1 rootfs-1-s
[lei@fedora test]$ rm rootfs-1-s/bin/my-tool
[lei@fedora test]$ touch rootfs-1-s/bin/my-tool-1
[lei@fedora test]$ mkdir rootfs-1-s/etc/my-app-cfg.d
[lei@fedora test]$ touch rootfs-1-s/etc/my-app-cfg.d/cfg
[lei@fedora test]$ tree rootfs-1-s
rootfs-1-s
├── bin
│   ├── my-app
│   └── my-tool-1
└── etc
    ├── my-app-cfg.d
    │   └── cfg
    └── my-tool-cfg

3 directories, 4 files

[lei@fedora test]$ oci-image-tool create-layer rootfs-1-s/ rootfs-1
[lei@fedora test]$ ls
rootfs-1  rootfs-1-s  rootfs-1-s.tar  rootfs-1.tar
[lei@fedora test]$ vim rootfs-1-s.tar
" tar.vim version v29
" Browsing tarfile /home/lei/test/rootfs-1-s.tar
" Select a file with cursor and press ENTER

bin/
bin/.wh.my-tool
bin/my-tool-1
etc/
etc/my-app-cfg.d/
etc/my-app-cfg.d/cfg

Any feedback are welcome :)
ping @vbatts

[wking]

On Thu, Sep 08, 2016 at 06:59:30AM -0700, Lei Jitang wrote:

This PR use a well tested pkg from
https://github.com/docker/docker/tree/master/pkg/archive
…
A vendor/github.com/docker/docker/LICENSE (191)
A vendor/github.com/docker/docker/NOTICE (19)
A vendor/github.com/docker/docker/pkg/archive/archive.go (1157)
…

I'd rather not pull in all of Docker ;). In ocitools we've forked a
Docker package to avoid this import 1, although it's nicer if we can
avoid forking and move the package to a separate repository where both
Docker and OCI devs can share maintenance.

[jonboulle]

Either way, my preference would be to split the tooling out into another repo before dragging in a large amount of code.

[coolljt0725]

@wking Maybe we can use the repo https://github.com/containers/storage

[wking]

On Mon, Sep 12, 2016 at 07:02:54PM -0700, Lei Jitang wrote:

@wking Maybe we can use the repo https://github.com/containers/storage

Also pulls in Docker 1, no? This is not such a complicated idea,
and my preference for implementations is:

a. A stand-alone library (that pulls in no higher-level tooling) which
all parties can develop collaboratively without having to pull in
more than they want.
b. An OCI-specific library that implements the spec with a focus on
clarity and correctness, sacrificing performance where it would
require too much complexity.
c. Pulling in a giant, high-level package to just use a tiny portion
of it.

(c) leads to cyclic dependencies (using Docker code to certify Docker
compliance?) and complicates security auditing and such. (b) is easy
to do (fork the package out of a big repo), but wastes effort
duplicating maintenance of equivalent tooling. (a) is nice and
efficient, but the upstream authors have to change their workflow and
pull the package out of its current home.

[coolljt0725]

@wking

Also pulls in Docker [1], no?

I think it's pull from docker.

c. Pulling in a giant, high-level package to just use a tiny portion
of it.

I prefer this implementation, because https://github.com/containers/storage is pulled from docker and
the archive code is well-tested. And using glide to mange the vendor, we can avoid pulling a giant code because glide could remove the unused code and only keep the being used code.

[runcom]

Either way, my preference would be to split the tooling out into another repo before dragging in a large amount of code.

Strongly agree here, I would love to wait on this :(

[coolljt0725]

@runcom

Either way, my preference would be to split the tooling out into another repo before dragging in a large amount of code.
Strongly agree here, I would love to wait on this :(

I'm agree too, continue my work after split the tooling out into another repo

[coolljt0725]

move to image-tool