You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 14, 2020. It is now read-only.
Actually the spec doesn't clarify when an endpoint template should be accepted or
not. Now, the appc/spec implementation returns only endpoints that can
be fully rendered. This means that it will also accept a template if it
doesn't contain some of the required discovery labels.
This looks good, but, trying to implement some meta discovery ideas it
will bring to unwanted endpoints.
Example 1:
Suppose I want to implement the "latest" pattern behavior:
```html
<!-- ACIs with specific version -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-{version}-{os}-{arch}.{ext}">
<!-- Latest ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-latest-{os}-{arch}.{ext}">
```
If, on discovery, I ask for the _name_, _os_ and _arch_
labels only the second template will be rendered (since the first cannot
be fully rendered due to missing _version_ label). So I achieved latest
pattern.
But if I'm asking for a specific _version_ both templates will be
rendered.
Example 2:
As an extension of the first example, suppose I want to create a global
meta discovery for all my images on example.com. So on the root of my
server I'll put some meta tags using example.com as prefix:
```html
<!-- ACIs with specific version -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-{version}-{os}-{arch}.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-{version}-{os}-{arch}.{ext}">
<!-- noarch ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-{version}-noarch.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-{version}-noarch.{ext}">
<!-- Latest ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-latest-{os}-{arch}.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-latest-{os}-{arch}.{ext}">
<!-- Latest noarch ACIs -->
<meta name="ac-discovery" content="example.com https://storage.example.com/{name}-latest-noarch.{ext}">
<meta name="ac-discovery" content="example.com https://mirror.storage.example.com/{name}-latest-noarch.{ext}">
```
With this tags I want to implement global "latest" and "noarch" patterns
and also return multiple mirrors.
If, on discovery, I ask only for the _name_ and _version_ labels the
template 3 and 4 will be rendered. So I achieved a versioned noarch pattern.
But, unfortunately, also the last two templates will be rendered.
And, as the first example, if I'm asking for a specific _name_,
_version_, _os_ and _arch_ ALL the templates will be rendered.
Since the spec says:
```
Note that multiple `ac-discovery` tags MAY be returned for a given
prefix-match [snip] In this case, the client implementation MAY choose
which to use at its own discretion.
```
If an implementation chooses the second it can download the wrong image version.
This patch makes template matching stricter choosing only best matching templates.
Best matching templates are the one where all the templates labels can
be substituted and with the highest number of substituted labels.
With this we can obtain various patterns like latest and noarch and also
keeping the ability to return multiple mirror urls. See also the tests
added in this commit.
It also documents this behavior.
It should not BREAK many of the current meta tags implementation (it
depends on how the client uses the returned endpoints, for example rkt,
currently, only uses the first one)
where _name_, _version_, _os_, and _arch_ are set to their respective values for the image, and _ext_ is either `aci` or `aci.asc` for retrieving an App Container Image or signature respectively.
61
61
62
+
The client MUST accept only best matching templates. Best matching templates are the one where all the templates labels can be substituted and with the highest number of substituted labels.
If the client requires the image name _name_ and labels _version_, _os_, _arch_ only the first two templates will be rendered since they match 3 labels (while the the last matches only 2 labels since it doesn't match the _version_ label).
72
+
If the client requires the image name _name_ and labels _os_, _arch_ only the last template will be rendered since in the first template '{version}' cannot be substituted.
73
+
62
74
Note that multiple `ac-discovery` tags MAY be returned for a given prefix-match (for example, with different scheme names representing different transport mechanisms).
63
75
In this case, the client implementation MAY choose which to use at its own discretion.
64
76
Public discovery implementations SHOULD always provide at least one HTTPS URL template.
0 commit comments