add layer names in inspect output

[raharper]

The current stacker inspect output prints a summary of image layers for example (only showing the layer parts)

ubuntu-minimal
    layer 0: 4e47402319bc... (128 MB, application/vnd.oci.image.layer.v1.tar+gzip)
...
u3
    layer 0: 4e47402319bc... (128 MB, application/vnd.oci.image.layer.v1.tar+gzip)
    layer 1: f8c5ad09a689... (62 MB, application/vnd.oci.image.layer.v1.tar+gzip)
...

Would it be possible to include the layer name along with the shorten hash; as a human, comparing the layer names is preferential when trying to understand the composition of an image; something like

ubuntu-minimal
    layer 0: ubuntu-minimal  (4e47402319bc..., 128 MB, application/vnd.oci.image.layer.v1.tar+gzip)
...
u3
    layer 0: ubuntu-minimal  (4e47402319bc..., 128 MB, application/vnd.oci.image.layer.v1.tar+gzip)
    layer 1: u3              (f8c5ad09a689..., 62 MB, application/vnd.oci.image.layer.v1.tar+gzip)
...

[tych0]

This would be neat; what about when two tags point to the same layers? I guess render them both?

[tych0]

So I wrote an implementation of this, and it turns out the answer is "no, only the first image with these layers should represent them"; that's in e.g.;

base:
  from:
    type: docker
    url: docker://ubuntu:latest
child:
  from:
    type: built
    tag: base
  run: |
    touch /foo

You'll get output like this:

base
	layer 0: base, child da7391352a9b... (29 MB, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 1: base, child 14428a6d4bcd... (847 B, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 2: base, child 2c2d948710f2... (162 B, application/vnd.oci.image.layer.v1.tar+gzip)
child
	layer 0: base, child da7391352a9b... (29 MB, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 1: base, child 14428a6d4bcd... (847 B, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 2: base, child 2c2d948710f2... (162 B, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 3:       child 08a88e848b6e... (100 B, application/vnd.oci.image.layer.v1.tar+gzip)

Which is confusing, but correct, since child is a tag that points to those base layers.

[raharper]

So I wrote an implementation of this, and it turns out the answer is "no, only the first image with these layers should represent them"; that's in e.g.;

base:
  from:
    type: docker
    url: docker://ubuntu:latest
child:
  from:
    type: built
    tag: base
  run: |
    touch /foo

You'll get output like this:

base
	layer 0: base, child da7391352a9b... (29 MB, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 1: base, child 14428a6d4bcd... (847 B, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 2: base, child 2c2d948710f2... (162 B, application/vnd.oci.image.layer.v1.tar+gzip)
child
	layer 0: base, child da7391352a9b... (29 MB, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 1: base, child 14428a6d4bcd... (847 B, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 2: base, child 2c2d948710f2... (162 B, application/vnd.oci.image.layer.v1.tar+gzip)
	layer 3:       child 08a88e848b6e... (100 B, application/vnd.oci.image.layer.v1.tar+gzip)

Which is confusing, but correct, since child is a tag that points to those base layers.

This is very confusing to me. Why isn't it like this?

base
  layer 0: base ....
child:
  layer 0: base ...
  layer 1: child

AFAICT, we only have two layers:

da7391352a9b, 29MB which is (and I think should be described wth url, docker://ubuntu:latest)
08a88e848b6e, 100B which is (child.run which does touch /foo)

What's 14428a6d4bcd and 2c2d948710f2 and why are they there?

If these two layers represent something stacker is doing, (like from, import
or run) I think they should get annotated as such.

base
  layer 0: base <hash1> <from: docker://ubuntu:latest> (size, type)
  layer 1: base <hash2> <repack of layer0 by stacker>  (size, type)  # or whatever this layer is
  layer 2: base <hash3> < whatever this layer is>      (size, type)
child:
  layer 0: base <hash1> <from: base>
  ...
  layer 3: child <hash4> <run script> (size, type)

child is a tag that points to those base layers

I don't think it's useful to repeat the tags of the image being built, rather
pointing where it came from provides me with what I'd like to see. That is

base:
  layer0: base (...)

Which is true, but not as informative as something that give me an
understanding of how this oci is composed (without having the stacker.yaml)

base:
  layer0: from: docker://ubuntu:latest (...)
  layer1: run:

[tych0]

What's 14428a6d4bcd and 2c2d948710f2 and why are they there?

They are shipped as part of ubuntu://latest (aka, it is a collection of three layers and not one)

don't think it's useful to repeat the tags of the image being built,

I agree :) The question is how to actually derive the result we want. If someone has done an umoci tag foo bar, it seems like the output should reflect that.

Which is true, but not as informative as something that give me an understanding of how this oci is composed (without having the stacker.yaml)

Sure, we could probably do some fancier introspection like that. Perhaps I'll punt on this for now then, since it looks like more than just a quick hack. Here's my implementation if anyone wants to use it as a base for future work: tych0@a929382

[raharper]

What's 14428a6d4bcd and 2c2d948710f2 and why are they there?

They are shipped as part of ubuntu://latest (aka, it is a collection of three layers and not one)

Interesting. I wonder if there are some patterns to follow here; for example
in bzr, one could pass the -n parameter to bzr log and it would show all of
the commits from a branch rather than the top-level/merge commit which was
typically a summary.

Generally, I don't need to know how many layers my from: or import: image uses
but at times one may want "full disclosure" output.

don't think it's useful to repeat the tags of the image being built,

I agree :) The question is how to actually derive the result we want. If someone has done an umoci tag foo bar, it seems like the output should reflect that.

The umoci tag to me is just like a symlink; so I'd display those just like
symlinks are in the filesystem (bar -> foo).

Which is true, but not as informative as something that give me an understanding of how this oci is composed (without having the stacker.yaml)

Sure, we could probably do some fancier introspection like that. Perhaps
I'll punt on this for now then, since it looks like more than just a quick
hack. Here's my implementation if anyone wants to use it as a base for
future work:
tych0@a929382

OK. I'll see if I can pull together some more examples from layers we're
building so we can see what output looks good and how to provide clean, clear
output and allow users to drill down for more information.

[tych0]

Generally, I don't need to know how many layers my from: or import: image uses but at times one may want "full disclosure" output.

IMO, invocation of stacker inspect is one of those times. I originally wrote it as a debugging tool for when I was building stacker, in case the code had gotten the layer list wrong somehow. I guess you don't necessarily care about things at that level, but mostly care about the more semantic "how did stacker build this thing", in which case it may be useful to have both options (or indeed, just drop the existing semantics of stacker inspect all together since it really could live in umoci, and use your semantics instead).

The umoci tag to me is just like a symlink; so I'd display those just likesymlinks are in the filesystem (bar -> foo).

The problem is there's no way to tell which direction the symlink points.

[raharper]

The umoci tag to me is just like a symlink; so I'd display those just likesymlinks are in the filesystem (bar -> foo).

The problem is there's no way to tell which direction the symlink points.

That's a bug in umoci then; Do we not have timestamps for when the tag reflink was added? No. =( It appears that oci dir index.json is append ordered; but likely order is not specific/required. Maybe we should avoid using umoci and implement the few things we use it for in stacker and utilize the more detailed actions that stacker tracks. I guess that won't help with oci images that aren't built with stacker.

I guess we would have to include all refs to the hash, like git tags, git log shows all tags for a ref.

[raharper]

Generally, I don't need to know how many layers my from: or import: image uses but at times one may want "full disclosure" output.

IMO, invocation of stacker inspect is one of those times. I originally wrote it as a debugging tool for when I was building stacker, in case the code had gotten the layer list wrong somehow. I guess you don't necessarily care about things at that level, but mostly care about the more semantic "how did stacker build this thing", in which case it may be useful to have both options (or indeed, just drop the existing semantics of stacker inspect all together since it really could live in umoci, and use your semantics instead).

Either is fine. I'm not really tied to the 'inspect' sub command; that can continue to be debug layer tool; I'm looking for a higher level (assume the layers are built correctly) way to reason about what is and is not in an image.