Proposal: discuss an OCI image format

[Brandon Philips]

Hello TOB-

For our first TOB meeting I would like to propose we discuss adding the AppC ACI image format[1] (or equivalent) to the OCI family of specs.

The question of whether the OCI will standardize a signable, transportable, and discoverable image format has been a pressing one for our stakeholders but something the OCI hasn't tackled thus far because of varying dissenting/approving opinions in the TDC. There have been discussions about image formats but, I believe, the ambiguous state the TDC is in about this question has led to light participation and no resolution[2][3]. Resolving this discussion is part of the TOB's responsibility for setting scope (OCI 6.b) and our explicit duty[4][5] as an organization.

I think the threshold for acceptance of any OCI image format is whether it can support the UX that users have come to expect from container engines like Docker and rkt. Namely the ability to pull human names with implied context (OS, arch, etc) and have them run:

    docker run example.com/org/app:v1.0.0

    rkt run example.com/org/app,version=v1.0.0

The second consideration should be supporting self-contained externally hostable assets that contains all relevant data and have that image be externally signed. This would allow people to host an asset on any URL/transport/etc and restore the same state:

    $ curl http://example.com/app.aci

    $ curl http://example.com/app.aci.asc

    $ rkt fetch app.aci

    rkt: using image from file /home/user/app.aci

    rkt: signature verified:

      Release <r...@example.com>

    sha512-938efe

    $ rkt image list

    ID NAME

    sha512-938efe example.com/app:v1.0.0

This style of import/export and external trust is perhaps less common than the first example but is a clear use case presented from a number of people when naming was last discussed on the OCI dev mailing list[6].

If the members of the OCI TOB, after discussion, find that adding AppC ACI (or equivalent) to the OCI specs isn't reasonable then I propose we should instead resolve to strike or clarify all language about standardizing and harmonizing image formats in OCI materials to permanently resolve confusion and ambiguity in discussions moving forward. 

tl;dr We should either start this image format work with earnest with an agreed upon reasonable completion date (March 30th?) or set the expectation to the wider community that the OCI is not handling the image effort at all.

Thank You,

Brandon 

[1] https://github.com/appc/spec/blob/master/spec/aci.md

[2] https://github.com/opencontainers/specs/pull/293 

[3] https://github.com/opencontainers/specs/issues/11

[4] https://www.opencontainers.org/news/faqs/what-are-top-specific-duties-oci

[5] https://groups.google.com/a/opencontainers.org/d/msg/dev/uo11avcWlQQ/EzQVIGhhEAAJ

[6] https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/ziEwxasyFQAJ

[Greg KH]

On Wed, Feb 10, 2016 at 02:15:29AM +0000, Brandon Philips wrote:
> Hello TOB-
>
> For our first TOB meeting I would like to propose we discuss adding the AppC
> ACI image format[1] (or equivalent) to the OCI family of specs.

I'd like to "second" this proposal. I don't think we have any other
"formal" way to ask for things to be on the agdenda at this point in
time than this.

Any objections?

thanks,

greg k-h

[Greg KH]

Oops, I forgot that we need 2/3 approval to add things to the agenda, so
consider this my vote for "yes" for that.

thanks,

greg k-h

[vbatts]

Right, so this is for "the distributable format", as "the format" up to this point has been the concerned for the runtime execution only.

I'm +1 to this discussion.

vb

[chrisw]

On Tuesday, February 9, 2016 at 6:15:40 PM UTC-8, Brandon Philips wrote:

For our first TOB meeting I would like to propose we discuss adding the AppC ACI image format[1] (or equivalent) to the OCI family of specs.

+1

This is an important fundamelt discussion for OCI

[Jason Bouzane]

I'm +1

> --
> You received this message because you are subscribed to the Google Groups
> "Technical Oversight Board" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tob+uns...@opencontainers.org.

[vbatts]

Mulling on this further.

Image format has been contentious for whatever reasons, but it was decided at the last F2F that image format is wanted for 1.0.

The current proposal (#293) really is only a first building block. It does not address discoverability; it could allow for signing, but doesn't dictate it; and it does not dictate conveying publisher identity. I look forward to these things having common standards.

Looking back at such threads as https://groups.google.com/a/opencontainers.org/forum/#!msg/dev/OqnUp4jOacs/ziEwxasyFQAJ
I'm reminded how ambiguous and non-conclusive they were.

If the list to discuss here is a signable, transportable, and discoverable image format,
then it should be chiseled away as such, because these can be orthogonal to each other.

There are solutions for these in the appc/spec, as well as in docker.
There is the need for a common standard.

My open question is: To have an actual technical conversation, what is the best step forward to have a common standard on a signable, transportable, and discoverable image format?

vb

On Tuesday, February 9, 2016 at 9:15:40 PM UTC-5, Brandon Philips wrote:

[Greg KH]

On Wed, Feb 17, 2016 at 04:52:47PM -0800, vbatts wrote:
> My open question is: To have an actual technical conversation, what is the best
> step forward to have a common standard on a signable, transportable, and
> discoverable image format?

You usually need to start with a proposal and work from there. Do we
have such a thing anywhere that is any shape to be molded into a final
solution?

thanks,

greg k-h