If/When discuss this project under OCI's public thread

[xiekeyang]

We have discussed and implemented OCI image discovery for some weeks. Currently we have a draft specification and experimental framework of discovery. While private discussion is becoming limited effect, we should consider to open a public discussion on OCI thread (I prefer @dev firstly), to talk if/when contribute this to OCI incubated project. Meanwhile we want OCI developers and users to express their opinions, making this project workable and acceptable by OCI ecosystem.

I present the initial demonstration as the below. If you think somewhere should be improved, or it is not the right time to discuss publicly, please put up directly.

Initial Discussion:

The main goal of project oci-discovery 1 is to demonstrate a mechanism to discover OCI images through a name delegation server by the below ways:

• Host-Based Image Names Delegation;
• Image Reference Engine Protocol;
• OCI canonical protocol template;
• Definition of merkle root object for a CAS discovery engine;
• An experiment of the discovery workflow;

As a supplement to OCI ecosystem, this just want to achieve canonicalization of image discovery and name delegation, and excludes topics of canonicalization about distribution out of the scope. We want that thread to be talked and addressed in another story.

While this project define OCI expected protocols, it allows consumers to register and make use of existing HUB based protocols such as Docker. Consumers just need to implement the protocol engine.

Contributing this to be an incubated project under OCI might be a considerable approach. It can help the iteration to going on, and make sure it on the right direction with developers contribution.

While there are some other good alternative such as parcel 4, ABD 5, etc, we may discuss here which is more slectable, or to take mixture among them. (During working on oci-discovery, we have get much great advice from the authors.)

[wking]

On Wed, Sep 20, 2017 at 12:26:57AM -0700, xiekeyang wrote:

…I prefer @dev…

Sounds good to me, although this will eventually be a TOB decision.

Meanwhile we want OCI developers and users to express their opinions…

I expect TOB movement to be slow (e.g. see opencontainers/tob#32), but this is a benefit to an earlier dev@ mention. I'd mention in the dev@ thread that this project is young and positioning itself for an eventual place as an OCI Project (or a component of image-spec, as the TOB sees fit). But I'd emphasize that we're currently looking for feedback, and will consider asking to become a (sub)Project if we get enough positive feedback.

The main goal of project oci-discovery 1 is to demonstrate a mechanism to discover OCI images through a name delegation server by the below ways…

These are not parallel ways; the way we're specifying is the Ref-Engine Discovery specification (which is one of possibly many ref-engine discovery protocols). The remaining micro-specs and protocol registries support the Ref-Engine Discovery spec, but are separate to allow easy re-use in other third-party specs.

• Definition of merkle root object for a CAS discovery engine;

The Merkle-root glossary entry 1 explicitly points out that Merkle roots may have different media types. The current Go interface that we define happens to use Descriptor for roots, but it could be made more generic, and other folks are free to write ref-engines that return other types.

As a supplement to OCI ecosystem, this just want to achieve canonicalization of image discovery and name delegation, and excludes topics of canonicalization about distribution out of the scope.

None of these specs aims to be canonical. The only canonical things are the protocol registries, and then only within the context of refEngines and casEngines. Consumers should be able to replace any component with another and still have a functioning system.

The scope table recognizes this by making “Canonical namespace” and “Standardizing on a particular Distribution method” both explicitly out of scope 2. The only thing these specs are trying to do is provide one possible spec for “DNS based naming” 2, registries for different distribution protocols, and one way for DNS-based names to discover the associated host's distribution preferences.

[wking]

Also, if you open this thread before it happens, mention that @cyphar is planning on picking parcel back up in the next few weeks 1 and that there is significant overlap between the two projects. My impression is that the planned parcel updates will make parcel's spec(s) very similar to what we have here now, but until there are public commits with the planned parcel changes it's hard to tell.

Once @cyphar open parcel back up for comments 2, I'm planning to open parcel issues to try and reduce the gaps between the two projects (the early discussion in #9, before we got sidetracked discussing parcel plans, is one example of discussion about a current difference between parcel and this repo).

[wking]

Closable now that there is a dev@ thread?

[xiekeyang]

closed by https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/ZwX6CwrCiK4