Define image-related action nomenclature

[stevvooe]

The image-tools repository has a few different terms that are being applied to image layouts that seems unintuitive or confusing. To ensure that tools have operational parity, it seems like a solid idea to define the terminology for this common operations.

Specifically, we should define the high-level terms for "unpack", "create", "pack", "verify" (?).

This will make it clear what functionality the specification actually provides.

[wking]

On Fri, Nov 18, 2016 at 12:30:13PM -0800, Stephen Day wrote:

Specifically, we should define the high-level terms for "unpack",
"create", "pack", "verify" (?).

+1 to defining these sorts of terms.

The spec already uses “applying changesets” 1 for the operation that
image-tools describes as “unpack”. And it uses something like
“creating” 2 or “representing changes” 3 for the inverse.
(Un)packing sounds more specific to me, so I'm in favor of adopting
(and defining) (un)packing in the spec.

I'm not aware of clear wording in the spec analagous to image-tool's
“create” (and the spec is weak on config translation in general, see
#454).

“verify” seems pretty clear to me, and the spec's key words 4 and
in-flight compliance language (#432) cover most of what I'd like to
see there.

[wking]

I've taken a stab at this in #554.

[vbatts]

so we want to go with "pack" and "unpack" vs "create" and "apply"?
honestly, cleaning up the current wording is a separate task from switching to new terms. These new terms are more confusing in the sense of sounding like regular tar archives, which they aren't.

[wking]

On Wed, Mar 08, 2017 at 11:18:56AM -0800, Vincent Batts wrote: so we want to go with "pack" and "unpack" vs "create" and "apply"? honestly, cleaning up the current wording is a separate task from switching to new terms. These new terms are more confusing in the sense of sounding like regular tar archives, which they aren't.

I don't think you need new words to distinguish from regular tar archives. (un)packing can be generic words that apply to any media type (which is what I'm aiming at in #554), and how they are implemented should clearly (I hope) depend on the media type being handled. Is there a reason to expect the application/x-tar algorithms to apply out of the box to application/vnd.oci.image.layer.v1.tar blobs? I don't think so. If that did work, we'd have just used application/x-tar as our layer media type.

[RobDolinMS]

Should we close this issue and move discussion to PR #554 ?

[stevvooe]

@RobDolinMS I'm not sure that #554 covers what I was looking for. I think this one is on my plate, but it will have to come after 1.0.

[tianon]

https://github.com/opencontainers/image-tools is mostly unmaintained, and quite a few "image" tools have been created in the interim (crane, regctl, etc). The lack of standard terms between them is unfortunate, but I'm afraid is pretty firmly in the "sailed ship" camp - any objections to closing out this now outdated issue?