Documentation: commands: add image extract/render/show #649
Conversation
|
cc @jonboulle @bcwaldon thoughts? |
philips
force-pushed
the
rocket-extract-doc
branch
2 times, most recently
from
9e7eea5
to
dd4fa3e
Compare
| ### rkt image cat-file | ||
|
|
||
| For debugging or inspection you may want to extract an ACI manifest to stdout or any other file. | ||
| If you want a file other than the manifest provide it after the image argument. |
There was a problem hiding this comment.
I don't think this default behavior is really useful. I'd actually like to see a rkt image cat-file which has no default argument and pulls from the rootfs alongside a rkt image cat-manifest
There was a problem hiding this comment.
hrm, I made a typo in this but the idea was rkt image cat-file coreos.com/etcd rootfs/README.md and rkt image cat-file coreos.com/etcd manifest
There was a problem hiding this comment.
I assumed as much. I still like the idea of two commands so you don't have to worry about remembering rootfs/. Maybe that's not an issue, though.
There was a problem hiding this comment.
Yea, I don't know if it is an issue or not. As long as things are consistent.
|
This is not really rkt specific -- it's just ACI manipulation. Should it be in |
philips
force-pushed
the
rocket-extract-doc
branch
from
dd4fa3e
to
f6d18eb
Compare
|
@eyakubovich It is exporting stuff out of the CAS, it shouldn't fetch I don't think. |
|
@eyakubovich see previous discussion in #633, this should only be Rocket-specific stuff |
|
How is everyone feeling on this proposal turning into code at this point? @eyakubovich @jonboulle @bcwaldon ? |
|
Seems reasonable. Another useful sub-command would be to list contents. When working with tarballs, rpms, debs, I often just want to list the filenames in the package. |
|
cc @robszumski We need to think through the various subcommands in rkt a bit. Any thoughts on adding this sort of stuff? |
|
Subcommands aren't as discoverable but at some point you have so many commands that there isn't really a choice. A lot of tools pick tricky naming like |
|
As the cas can contain multiple images with the same name the user should be able to choose them in a more precise way. I propose to also standardize the URL like app name format. Ex. coreos.com/etcd:v2.0.5,os=linux,arch=amd64 So on the implementation side cas.GetACI can be directly used to find the best image. Additionally the cas can also contain images with completely identical name and labels. They can be distinguished by 2 criteria:
While the first is obviously just ready to get rendered the second will need a new function to find it. I think that the doc and future implementation should also handle these options. |
|
@sgotti it sounds like you want to formalise something like this? appc/spec#4 |
|
@jonboulle Yeah as it's probably going to be used by various commands. |
|
Do we expect users to type |
|
I agree with @robszumski that it would be nice to consider the number of subcommands we have and how they fit together. |
|
@philips Does this solve the |
@kelseyhightower os/arch would continue to be substituted in with defaults as they are today |
|
On Sun, Apr 12, 2015 at 6:32 PM, Kelsey Hightower
I think so. I don't know exactly what problem you are thinking of |
@kelseyhightower For image listing I opened #587. By now it's an In #603 there's image removal and in comment #603 (comment) @philips proposed to call it |
Replace getImageID() with getImageByName(), this can remove the dependency on rkt.store.
|
I am going to give |
|
I had the same concern as bcwaldon about the semantic, how about cat-manifest and cat-file (which does not require rootfs/ prefix) ? |
|
@jonboulle SGTM. Actually in the implementation, the manifest can be read from the store without rendering the ACI. And I think the manifest will be cat'd more frequently than some binary files in rootfs ... |
|
We'll handle this in #1098 |
|
woot woot! On Wed, Jul 8, 2015 at 3:07 AM, Iago López Galeiras <
|
Some initial thoughts to close out #633 and #645.