[From Trevor]: A proposal to use CAS and ref engine to describe discovered object

From: W. Trevor King [mailto:[email protected]]
Date: 2017年9月1日 6:42
To: xiekeyang
CC: Aleksa Sarai
Subjectiscovery of OCI image

On Thu, Aug 31, 2017 at 10:45:25AM +0000, xiekeyang wrote:

As to your review suggestion, I discuss with Aleksa…

It's probably time to move this into a public repo or PR somewhere.
Developing a spec via email is going to get confusing ;).

On Thu, Aug 30, 2017 at 19:33, Aleksa Sarai wrote:

"Discovery URI" is something like opensuse.org/leap.

"Distribution URI" is more like

https://download.opensuse.org/some/project/some-manifest.json.

However, as I mentioned previously, I have a much nicer version of the
document that uses "Template Descriptors". It might be possible for
the Distribution URI to be removed without losing the functionality.

I think a discovery/distribution distinction is important to separate mutable references from CAS blobs. Aleksa has some motivation in 1, and the opening point in #11 is about delegating image hosting 2.
The discovery resource is easy to host locally where clients can find it, and then you can point at any distribution resource you like (your own and/or several third parties). Distribution is via CAS and Merkle links, which is much easier to cache and verify, even over untrusted channels and from untrusted souces. Having some trust in the discovery provider helps avoid getting sent down a malicious Merkle tree (although with something like 3 you could protect against that too). So there are maybe three services in play:

1. The CAS engine which will eventually serve the image blobs 4.
2. A ref engine which resolves the name into an initial descriptor.
   For example, and index.json 5 and index 6 parser.
3. A way to find 1 and 2 starting from the user-supplied name.

Say example.com wants to delegate both 1 and 2 to a third party.
Aleksa's discovery and distribution services [7,8] are something like that, although they don't let you delegate to the Docker regsitry API 9, etc. He assumes that at some point you'll be fetching OCI index JSON (indexuris), and that the blobs will be available via a blob URI
(bloburis) 10. And his distribution object delegates both the ref engine and CAS engine at the same time.

I'd rather update our descriptor format to allow for CAS engine hinting. We currently have ‘urls’ 11, but that's a direct location for that blob. I want ‘casEngines’ or some such, which identifies CAS engines which likely hold that blob and its descendants. Something
like:

  {
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "size": 7143,
    "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
    "platform": {
      "architecture": "amd64",
      "os": "linux"
    },
    "annotations": {
      "org.opencontainers.image.ref.name": "coreos.com/etcd:1.0.0",
    },
    "casEngines": [
      {
        "protocol": "docker",
        "uri": "https://quay.io/coreos/etcd:1.0.0"
      },
      {
        "protocol": "oci-template-v1",
        "uri": "https://cas.coreos.com/{algorithm}/{encoded}"
      },
      {
        "protocol": "oci-template-v1",
        "uri": "https://docker.com/cas/{algorithm}/{encoded:2}/{encoded}"
      }
    ]
  }

That doesn't assume anything about the CAS protocol, it just gives you enough information to fetch sha256:e69… and it's descendants from quay.io if you understand the Docker registry protocol 9, or from coreos.com or docker.com if you understand the oci-template-v1 protocol 4. You can also extend the casEngines entries if you need to supply additional data (e.g. auth credentials).

RFC 6570 doesn't seem to have a way to remove the leading two chacters 12, so the template forms are not flexible enough to handle sharding cleanly 13.

With casEngines, anyone providing a descriptor can help with discovering CAS engines.

Next you need a ref engine protocol. You can do something clever here, but I'm not really interested in the specifics. Minting a new protocol for “fetch an index 6 over HTTPS” lets Aleksa's undexuri be more generic, making room for other ref engine protocols in the future. Let's call that protocol oci-index-template-v1 and use URI templates again. There are many other ways you could handle this, just give those alternatives their own protocol name.

Going back to my service enumeration, the only thing we still need is a way to get from 3 (the name) to 2 (a ref engine, or set of ref engines). Let's call this ref-engine discovery. One approach to this would be to declare a well-known URI
(https://{authority}/.well-known/oci/ref-engines) with content like:

  {
    "refEngines": [
      {
        "protocol": "oci-index-template-v1",
        "uri": "https://{authority}/ref/{name}"
      },
      {
        "protocol": "oci-index-template-v1",
        "uri": "https://oci.example.com/ref/{name}"
      }
    ],
    …
  }

then anyone that understood oci-index-template-v1 could resolve references to descriptors via those resources, check that descriptor's casEngines (if set) to locate the blobs, and connect to that CAS engine to retrieve the blobs.

And as Aleksa does with the discovery metadata 7, you can define a default ref-engine discovery value for folks who don't want to bother providing their own, although in that case they'd have to provide their own ref engine wherever the default ref-engine discovery content pointed. And folks who wanted to defer everything to a third party could point at their ref engine and either have that third party also run the CAS engine or delegate that to additional parties.

The reason why I didn't go with the same thing your proposal does is
that your proposal makes the assumption that the
publishing/distribution system is able to modify
/.well-known/oci-index/... on the opensuse.org domain (for example).

Parcel doesn't need this requirement, all of the redirection and
templating is done on the client which means that there's no need to
modify the /.well-known/ directory unless you're changing the image
policy.

This is a good point, and a good reason to not host the ref engine itself under .well-known (which is what I'd been suggesting in my earlier discussion with Keyang).

Cheers,
Trevor

 Although I don't mean that layout format in particular, just
 anything that supports a content-addressable get like [9].

from oci-discovery.

[From Aleksa]: Options Discovery Mate Policy SHOULD be light-weight as ref-engine be insufficient

An image-spec PR until we have:

a) An implementation, with a spec.
b) Evidence that the implementation is sane (in other words, that it is usable).

I also recommend referencing the AppC image spec when discussing discovery and distribution.

"Discovery URI" is something like opensuse.org/leap.

"Distribution URI" is more like

https://download.opensuse.org/some/project/some-manifest.json.

However, as I mentioned previously, I have a much nicer version of
the document that uses "Template Descriptors". It might be possible
for the Distribution URI to be removed without losing the
functionality.

I think a discovery/distribution distinction is important to separate
mutable references from CAS blobs. Aleksa has some motivation in [1],
and the opening point in #11 is about delegating image hosting [2].
The discovery resource is easy to host locally where clients can find
it, and then you can point at any distribution resource you like (your
own and/or several third parties). Distribution is via CAS and Merkle
links, which is much easier to cache and verify, even over untrusted
channels and from untrusted souces. Having some trust in the
discovery provider helps avoid getting sent down a malicious Merkle
tree (although with something like [3] you could protect against that
too). So there are maybe three services in play:

1. The CAS engine which will eventually serve the image blobs [4].
2. A ref engine which resolves the name into an initial descriptor.
   For example, and index.json [5] and index [6] parser.
3. A way to find 1 and 2 starting from the user-supplied name.

Say example.com wants to delegate both 1 and 2 to a third party.
Aleksa's discovery and distribution services [7,8] are something like
that, although they don't let you delegate to the Docker regsitry API
[9], etc. He assumes that at some point you'll be fetching OCI index
JSON (indexuris), and that the blobs will be available via a blob URI
(bloburis) [10]. And his distribution object delegates both the ref
engine and CAS engine at the same time.

I'm working on improving that. Delegating to a Docker Registry is definitely something that I intend to make sure is usable.

This is probably going to be part of my template descriptor improvements, where I'll change the "distribution object" to be able to have different backends (similar to what you're proposing, but rather than being part of descriptors it's all on the upper "distribution" layer).

I'd rather update our descriptor format to allow for CAS engine
hinting. We currently have ‘urls’ [11], but that's a direct location
for that blob. I want ‘casEngines’ or some such, which identifies CAS
engines which likely hold that blob and its descendants. Something
like:

I don't agree to be honest. There's a couple of reasons for this:

a) It feels like we're overloading what a descriptor is used for. Is it used during storage, or is it used as part of distribution? If both, does that mean you are going to store casEngines inside the CAS?
Or is this a modified descriptor you only provide when you send it?
b) It requires the thing that is generating the image to either be aware of where it's going to be hosted (bad) or it requires you to generate modified versions of the image descriptors after it's been created (possibly bad or disastrous, depending on whether the casEngines is expected to be stored in the image or just provided as a "fake" descriptor).
c) This all sounds quite backwards to me. You should get the descriptors through distribution, not require the descriptors to define the distribution scheme. Or as in (a) is this just a way to avoid defining a separate construct for blob distribution?

There is a point to be made about having digests and sizes for distribution. I definitely think that the current incarnation of parcel suffers from requiring clients to "do the right thing" a bit too much (my current template descriptor WIP explicitly states that for "opaque" types you have to know the MIME and the digest before you pull it, and that you should verify it).

"casEngines": [
  {
    "protocol": "docker",
    "uri": "https://quay.io/coreos/etcd:1.0.0"
  },
  {
    "protocol": "oci-template-v1",
    "uri": "https://cas.coreos.com/{algorithm}/{encoded}"
  },
  {
    "protocol": "oci-template-v1",
    "uri": "https://docker.com/cas/{algorithm}/{encoded:2}/{encoded}"
  }
]

In parcel I favour using URI schemes over a separate protocol field, but I'll have to think a little more about it. In either case, at first glance you have to generate a lot of derivative objects in order to make it work. One of the main benefits of parcel is that there is no dynamic generation required for any of the "image policy"
decisions for both discovery and distribution. That means that specifying where to download certain images from and so on is all implementable statically, purely through HTTP redirects and having static JSON blobs.

RFC 6570 doesn't seem to have a way to remove the leading two chacters
[12], so the template forms are not flexible enough to handle sharding
cleanly [13].

I don't think suffix slicing is required. While git does suffix slicing, other sharding stores (like camlistore from memory) don't.
It's a personal taste thing.

With casEngines, anyone providing a descriptor can help with
discovering CAS engines.

While I appreciate the "p2p" nature of this, I think a more fediverse style distribution scheme better describes how people want to download their software.

Next you need a ref engine protocol. You can do something clever
here, but I'm not really interested in the specifics. Minting a new
protocol for “fetch an index [6] over HTTPS” lets Aleksa's undexuri be
more generic, making room for other ref engine protocols in the
future. Let's call that protocol oci-index-template-v1 and use URI
templates again. There are many other ways you could handle this,
just give those alternatives their own protocol name.

Going back to my service enumeration, the only thing we still need is
a way to get from 3 (the name) to 2 (a ref engine, or set of ref
engines). Let's call this ref-engine discovery. One approach to this
would be to declare a well-known URI
(https://{authority}/.well-known/oci/ref-engines) with content like:

{
"refEngines": [
{
"protocol": "oci-index-template-v1",
"uri": "https://{authority}/ref/{name}"
},
{
"protocol": "oci-index-template-v1",
"uri": "https://oci.example.com/ref/{name}"
}
],
…
}

I feel like having a separate "refEngine" concept doesn't make much sense. What problem does it solve that you cannot solve by just defining the way you access the CAS (or the registry, if you prefer) through template descriptors? If you require having a "refEngines"
thing, then why not just expand that concept to also handle "casEngines" (like parcel does). I appreciate wanting to separate the two, but it feels like modifying descriptors in order to do it is a bit backwards (you should get the descriptors through distribution, not require the descriptors to define the distribution scheme).

The reason why I didn't go with the same thing your proposal does is
that your proposal makes the assumption that the
publishing/distribution system is able to modify
/.well-known/oci-index/... on the opensuse.org domain (for example).

Parcel doesn't need this requirement, all of the redirection and
templating is done on the client which means that there's no need
to modify the /.well-known/ directory unless you're changing the
image policy.

This is a good point, and a good reason to not host the ref engine
itself under .well-known (which is what I'd been suggesting in my
earlier discussion with Keyang).

Yeah. It's important to note that any scheme for distribution that doesn't allow us (openSUSE) to distribute the blobs through download.opensuse.org, or delegate to somewhere else (potentially even doing both for different sets of images) is not really solving the problem of distribution sanely IMO.

--
Aleksa Sarai (cyphar)
www.cyphar.com

from oci-discovery.

On Fri, Sep 01, 2017 at 01:05:19PM +1000, Aleksa Sarai wrote:

I'd rather update our descriptor format to allow for CAS engine hinting. We currently have urls, but that's a direct location for that blob. I want casEngines or some such, which identifies CAS engines which likely hold that blob and its descendants. Something like:

I don't agree to be honest. There's a couple of reasons for this:

a) It feels like we're overloading what a descriptor is used for.

I don't think casEngines is overloading it any more than urls is already overloading it; they are very similar information.

And since casEngines is just for that blob and its ancestors, you can use an oci-template-v1 entry with no template markup (just a regular URI) to get everything we currently get from urls for leaf blobs. That addresses the initial motivation for urls, because layers are always Merkle leaves (they provide no way to link further children).

Is it used during storage, or is it used as part of distribution? If both, does that mean you are going to store casEngines inside the CAS?

I expect it to be mostly used in ref engine responses (more on what I mean by ref engines here). I don't expect many casEngines entries on CAS blobs, but I have no problem with them being there. They could go stale (just like urls), but who cares? It's just a hint.

Or is this a modified descriptor you only provide when you send it?

That works for the root descriptor(s) in the ref engine response, but you can't mutate anything deeper than that without re-hashing the whole Merkle tree (and breaking any signatures on it unless you have the signing key). So deeper mutation would require cooperation between the ref and CAS engines and a local signing key. That might happen, but I don't expect it to be a frequent occurrence. However, a ref engine can dynamically populate casEngines in the root descriptor(s) it returns without touching the rest of the Merkle tree, so you can be a more helpful ref engine by mentioning CAS engines that you expect to hold most of the tree, and not mentioning CAS engines that do not.

b) It requires the thing that is generating the image to either be aware of where it's going to be hosted (bad)…

No, you can leave casEngines off of all the in-CAS descriptors if you like. The only case for populating them there is if you do have a resonable commitment for long-term hosting at a particular location (as we currently do for base Windows layers).

… or it requires you to generate modified versions of the image descriptors after it's been created (possibly bad or disastrous, depending on whether the casEngines is expected to be stored in the image or just provided as a "fake" descriptor).

The root descriptor(s) returned by the ref engine are outside of CAS. I don't think that makes them “fake”. And I don't see anything bad/disasterous happening if the ref engines adds additional metadata to them. As long as the mediaType, digest, and size are unchanged, you're still referencing the same Merkle tree. If you trust the ref engine, you'll trust those root-descriptor mutations. If you use something like opencontainers/image-spec#176 for in-CAS trust, the ref engine won't be able to alter any of that. Can you provide more detail on your bad/disasterous workflow?

c) This all sounds quite backwards to me. You should get the descriptors through distribution, not require the descriptors to define the distribution scheme. Or as in (a) is this just a way to avoid defining a separate construct for blob distribution?

It separates the name → root descriptor API (served by a ref engine) from the root descriptor → CAS engine connection API (just read casEngines on the root descriptor). That means you can go forth and define any number of ref engine APIs, and have a single library that takes the output of any of them, connects to a suggested CAS engine (or a local one, or whatever), and fetches the blobs while walking the Merkle tree. That also means that the ref-engine discovery service can completely ignore CAS engines, and delegate those suggestions to the ref engines and the root descriptors they provide. So you can say “use ref engine ${FOO} to lookup all my images” in your ref-engine discovery response, and not have to also say “and then fetch the images they tell you about from CAS engine ${BAR}”. But really, it doesn't matter where you get the CAS engine connection information from. If you want to (optionally) include that in the ref-engine discovery service (making it a ref/cas-engine discovery service), that would be fine too. The more CAS engine hints a client gets, the better. It can figure out which one it likes best, and ignore the rest unless it gets a CAS miss from it's favorite service.

from oci-discovery.

My early comments is a little jumble, I rearrange my questions like below:

@wking

I think a discovery/distribution distinction is important to separate mutable references from CAS blobs. Aleksa has some motivation in [1], and the opening point in #11 is about delegating image hosting [2].
The discovery resource is easy to host locally where clients can find it, and then you can point at any distribution resource you like (your own and/or several third parties).

If that means the images digest MUST be identical between different found distribution URLs? I've not much experience on publishing product. If software/binary publish and delegation usually do like this way? (I mean not the way that different URLs provide same software name with different content)

{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"size": 7143,
"digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
"platform": {
"architecture": "amd64",
}

How to get this CAS blob descriptor during discovery process? If it need to retrieve the blob of the descriptor from all distribution urls? If it is, I think it should be work of distribution, not discovery.

So deeper mutation would require cooperation between the ref and CAS engines and a local signing key. That might happen, but I don't expect it to be a frequent occurrence.

I'm still a little unclear about the above scenario. Do you mean we actually only need casEngines for most cases?

"casEngines": [
  {
    "protocol": "docker",
    "uri": "https://quay.io/coreos/etcd:1.0.0"
  },
  {...}
]  

Can protocol be removed, just one line like:

"urls": [
  "https://quay.io/coreos/etcd:1.0.0",
  "https://cas.coreos.com/{algorithm}/{encoded}",
  "https://docker.com/cas/{algorithm}/{encoded:2}/{encoded}"
]

And, about ABD metadata, I think it is a little incorrect. That one discovered object should have same mirrors.

@cyphar parcel makes easy to discovery process. But I still feel it is too simple by returning only distribution urls. It is likely feature of discovery of distribution urls, not discovery of images. As I think consumers (at least me) really want to get image basic information when discovering it, not only distribution urls.

from oci-discovery.

from oci-discovery.

from oci-discovery.

from oci-discovery.

from oci-discovery.

from oci-discovery.

@wking I've said this earlier in the email chain: the current status of parcel is being reworked quite significantly. I have a wip branch that has some of the new "template descriptors" text which solves effectively all of the issues you just highlighted.

The next stage of image retrieval is not limited to a single protocol, unlike disturi which requires the next stage to follow @cyphar's distribution protocol [5].

That's not true. The appendix of parcel's spec explicitly states how you can specify alternative protocols, and supporting other protocols (as I've mentioned several times to you, Trevor) is an explicit design goal of parcel. Please stop repeating this incorrect statement.

Multiple entries. You can suggest several places to look for this image, not just one.

Template descriptors solve this problem, because they use an array. In fact, I might end up making it possible to also specify that certain mediatypes should be retrieved from one source but others from another.

from oci-discovery.

@xiekeyang I would recommend looking at https://github.com/appc/spec/blob/master/spec/discovery.md (which is the AppC ACI discovery). I'd have to ask @jonboulle, but given how ABD doesn't appear to be an alternative (or newer version) of ACI discovery.

from oci-discovery.

@cyphar

@xiekeyang I would recommend looking at https://github.com/appc/spec/blob/master/spec/discovery.md (which is the AppC ACI discovery). I'd have to ask @jonboulle, but given how ABD doesn't appear to be an alternative (or newer version) of ACI discovery.

Yeah, I've read both ABD and ACI discovery. Just feel ABD's meta is more likely fit to OCI.

the current status of parcel is being reworked quite significantly.

I've deeply read wip-rework branch of parcel. One question:

The defined namespaced variables of parcel.discovery.authority, userAuthority, name... They are definite URL fragment and query so on. Why you define them as variables, and parser them as query in explore.go?
You might just need clarify in spec that:

URI template MUST need the canonical query of authority, userAuthority, name...
the example looks like:
https://{authority}/.well-known/cyphar.opencontainers.parcel.v0.json?authority=coreos.com&name=etcd

I guess you want implementation do more thing than above?

These variables are namespaced -- implementations MAY extend the following list of variables (and SHOULD also namespace their variables)

It is from parcel. Why they MUST be namespaced? They've already under fragment of cyphar.opencontainers.parcel.v0.json.

from oci-discovery.

It is from parcel. Why they MUST be namespaced? They've already under fragment of cyphar.opencontainers.parcel.v0.json.

Oh, I'm wrong. They should be for client tools arguments, and then be parser to generate exact URI in implementation. So, it CAN only be defined as variables in spec.

from oci-discovery.

@xiekeyang The reason for using URI templates, and having them as variables is so that it's possible to offload redirection to clients (making it possible to have a static webserver which might be updated out-of-band frequently). Serving results like this:

https://{authority}/.well-known/cyphar.opencontainers.parcel.v0.json?authority=coreos.com&name=etcd

Would not be reasonably possible with static pages (if I changed authority to something else you'd expect a different result -- how would you achieve that for every possible values of the URL arguments?). Also that example is not right -- the point of cyphar.opencontainers.parcel.v0.json is to provide the image policy for the domain. The lookup stage for a particular image is after that.

Quite importantly too, the .well-known directory must be treated as static IMO. Using it for anything other that describing domain policy is a misunderstanding of the RFC in my view (which I think @wking's original proposal did not correctly do with the oci-index thing).

But yes, you're completely right that I need more examples. The current document is quite confusing and I really do need to fix that (trust me, it's very high on my list of things to do, but I currently have some other higher priority tasks I'm working on).

from oci-discovery.

from oci-discovery.

Perhaps as you flesh the idea out it will become more clear to me how
it supports delegation to multiple ref engines and provides for
structured, extensible protocol objects [4].

I'm still trying to decide whether I can remove a stage from the current parcel spec, which is why it hasn't been updated in a while. But effectively my plan is to do the following:

• Change the discovery object to have an array of template descriptors rather than disturi, which can point to different distribution objects (or more discovery objects, or another bare template descriptor). This is the level at which I think delegation to schemes like docker:// or ACI should be done.
• Change the distribution object to have a single array of template descriptors (I'm still trying to decide if we need two) with the MIME type specifying if that endpoint only supports a particular object type or an arbitrary object type (I might make the MIME entry an array, I haven't decided yet).

I'm wondering whether there might be some nice way of doing further namespacing at the discovery layer (other than just forcing the client to try all of their options). But that's a future improvement I can work on once I have template descriptors in place.

Does that better help explain my current plans?

The text you have there says http(s) schemes refer to HTTP (over TLS)
[5]. It doesn't have anything to distinguish between, for example,
the Docker registry API [6] and an oci-template-v1 API [4] when both
of them are over HTTPS. Perhaps you intend to coin a docker+https
scheme for the Docker registry API, and that would work, but as I
pointed out in [7,8], a {"protocol": "…", "uri": "…"} object is to
extend if you want to provide additional data for a custom protocol.

I didn't mention Docker, but in my mind you would specify it with docker://. I'm not sure whether we should have separate objects as you mentioned, or something more like https+oci or w/e. But the fact that Docker uses HTTPS is not really very relevant, in the same way that it's not relevant that both FTP and HTTP use TCP.

from oci-discovery.

from oci-discovery.

@wking

Squashing CAS and ref engines together in a single array and then
differentiating with protocol strings doesn't seem like fundamental
change. It's just a different structure for similar information.

On the other hand, I don't see how your ref engines concept is actually adding needed features. It feels effectively the same as parcel's discovery objects to me, except that it doesn't seem to work with static files.

What do you think is the meaningful distinction between a CAS and a ref engine, now that OCI references don't exist anymore?

I still think there are some gaps in your plan for an authority that
wants to delegate to a Docker registry for both refs and CAS.

It's not very clear to me that there aren't similar gaps in your scheme (not to mention it not being possible to use with static files). I can sort-of see how the "ref engine" would look for a Docker mirror, but how would the "mirrors" entries look in the descriptor for a particular object? You could go the layer violation route and just provide the URL directly, but the "official" interface to a Docker registry only provides you manifest granularity.

Objects are easier to extend.

Yeah, fair enough. Though your example doesn't sound quite right to me:

"uri": "https://quay.io/coreos/etcd:1.0.0",

from oci-discovery.

from oci-discovery.

CAS is a very specific thing [1]. Clearly mapping a name to a
descriptor (which is what a ref engine does, see [2]) is not something
a CAS engine can help you with.

I am aware what a CAS is, the main thrust of that comment was that OCI doesn't have references in the classic sense anymore so your core proposal of a ref-engine that provides mappings doesn't really work for a stock OCI image. And if you reduce it to "fetch the index and get the client to decide what to do" you've now recreated effectively how parcel does things, with some object changes but nothing "fundamental".

Having ref engines as a concept for that initial root descriptor/blob
lookup lets you separate that name-addressed resolution from the
content-addressed resolution of a CAS engine.

And my point was that I don't see how this is significantly different (or as you said "fundamentally different") to how distribution objects will work. That's effectively the same purpose that parcel's image policy serves, it's just that my scheme for distribution of OCI CAS blobs is described by part of the image policy. Distribution objects are separate from discovery objects (or if you prefer "ref engines", but I much prefer the ACI terminology). I understand that parcel needs some work to better explain how you could use it to delegate to docker.io (a usecase that is obviously important), but I don't understand how your proposal is "fundamentally different".

It feels like we're using different words to describe incredibly similar things.

I'm not in favor of a ‘mirrors’ property. I'd expect a helpful ref
engine to set casEngines in the root descriptor/blob it returns [5,6].

Which is what I meant by your proposal not being static-files (or dumb publishing platforms) friendly. If casEngines cannot be set, how does your scheme work with that? parcel handles it by making that part of the "delegated" image policy (delegated in this context meaning through redirection).

from oci-discovery.

from oci-discovery.

@cyphar

Quite importantly too, the .well-known directory must be treated as static IMO. Using it for anything other that describing domain policy is a misunderstanding of the RFC in my view (which I think @wking's original proposal did not correctly do with the oci-index thing).

I partly agree with you, for I see a risk if we enforce implementation to use oci-index: The existing URI system service have rules like /.well-known/example.txt, and just want to add the implementation to support OCI image discovery.

For that it have to break their rule, to add /.well-known/oci-index/oci.txt. The character oci-index may be opaque and be unable to parser to its system. This will make the system recorded data hard to be managed.

However to the contrary, how to distinguish OCI image URI and other URI in one discovery service if not using oci-index or other sub-path? Only depend on *.txt or *.json segment?

from oci-discovery.

I think our different opinions might be accordance by trading off: which is the more popular approach for well-known URI system, @cyphar 's or @wking 's?

from oci-discovery.

from oci-discovery.

Should we close this issue in favor or more focused parcel and/or oci-discovery issues?

from oci-discovery.