Remove _catalog API, reference as reserved #69

SteveLasker · 2019-08-16T00:17:44Z

Amends: #45
This PR is the result of conversations on the dev alias and weekly online meetings (https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#Agenda-Items18)

_catalog
- (lasker) there are registries that have not implemented it and will not.
- So removing _catalog from the spec doesn't mean that folks will have to remove it from their registry, but rather that it will be easier for others to be compliant.

Signed-off-by: Steve Lasker StevenLasker@Hotmail.com

mikebrow · 2019-08-16T01:10:28Z

Hey Steve... on the CI failure ... git-validation is very picky wrt what the commit header has to look like. I just use git commit -s -m "fixes issue ..." to sign vs trying to cut-n-paste to the commit header and get it right :-) Needs the empty line between the 80char or less commit description and before the signature.. example:

adds cni config data to the cri status/info

Signed-off-by: Mike Brown <brownwm@us.ibm.com>

# Please enter the commit message for your changes. Lines starting

hallyn · 2019-10-06T15:11:35Z

Hi,

the commit message doesn't explain the reason for removing it. It's certainly a hacky thing, not well specified, and eventually will be a security issue, but especially until there's a querying api (or did I miss it's recent addition?) it's a useful hack :)

I assume my list of reasons for removing it is about right? :) But it would be good for the commit message to say so, or to correct me.

SteveLasker · 2019-10-07T19:36:02Z

Hi @hallyn
I updated the PR info to reflect the previous conversations.
The new working group search/listing discussion moved from Hackmd and the KubeCon 2019 meeting notes, to a distribution-spec requirements discussion.
For the purposes of this PR, we just want to remove _catalog as a required implementation, that many registries won't implement, and leave it as reserved, so registries that did implement it won't get clobbered by a new api.

hallyn · 2019-10-07T19:54:11Z

Oh! I misread the diff before, thought the 'optional' mention was being removed.

+1, thanks.

vbatts · 2019-10-09T15:28:57Z

So this PR is not just removing _catalog, but now specifying a listing. Is that a stop gap until the search discussion is done?

SteveLasker · 2019-10-09T16:21:41Z

The diff viewing is a bit confusing as the tag listing spec made references to _catalog rules, only addressing a superset, unique to tag listing.
Once I removed _catalog, I had to bring forward the specifics to paging and such.
Did we want to remove tag listing as well? I thought, but could be wrong, that most registries supported tag listing and it wasn't problematic.
That said, whatever the future replacement is, it would need to address repositories and tag listing.
Is this a vote to remove tag listing as well?

vbatts · 2019-10-09T16:29:18Z

i get that. Folks do need/want listing. I just personally don't recall the iteration on what the requirements on the new API should be

…

On Wed, Oct 9, 2019 at 12:21 PM Steve Lasker ***@***.***> wrote: The diff viewing is a bit confusing as the tag listing spec made references to _catalog rules, only addressing a superset, unique to tag listing. Once I removed _catalog, I had to bring forward the specifics to paging and such. Did we want to remove tag listing as well? I thought, but could be wrong, that most registries supported tag listing and it wasn't problematic. That said, whatever the future replacement is, it would need to address repositories and tag listing. Is this a vote to remove tag listing as well? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#69?email_source=notifications&email_token=AAAQL2LS5ZRKHI6WJ27AOOTQNYAJLA5CNFSM4IMC4RPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYOXPI#issuecomment-540076989>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQL2MRQRGQUTJ5EEYU42TQNYAJLANCNFSM4IMC4RPA> .

SteveLasker · 2019-10-09T16:40:42Z

This PR isn't about defining a new API. It's just clearing out inconsistently supported APIs so we can release a 1.0 of the distribution-spec. As written, the _catalog api isn't, and apparently won't be implemented by many registries. This is just removing it form the spec, so registries can be compliant with a 1.0 of the spec, but reserving _catalog so registries that did implement it won't get clobbered by a new api.

mikebrow

LGTM

dmcgowan

LGTM

jzelinskie

after this point, i'm in agreement with this change

the diff seems non-ideal, maybe a different git algorithm would fix it, but it's no big deal

jzelinskie · 2019-10-11T23:07:20Z

spec.md

-The list of available repositories is made available through the _catalog_.
+Repository listing is reserved for a future version of the distribution spec.
+
+The `_catalog` api is reserved for historical usage. Registries MAY implement _catalog, but are NOT required.


Can we link to Docker v2 registry protocol spec in reference to this.
Because as of right now there is absolutely no context about what _catalog was

We discussed on the call this week. Rather than have a pointer for someone to implement an old, inconsistently implemented spec, we agreed to focus on defining a new api. The intent here isn't to say here's a deprecated api. Rather, we're stating _catalog isn't part of the spec, however we do reserve it so a future version of the spec wouldn't attempt to use it. Thus, preserving any previous implementations.

https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#Notes1

General discussion on how to move along with the removal of the _catalog endpoint as a required part of the 1.0 distribution spec. It will be a reserved API route, but there will be no recommended (or optional) implementation of a Catalog API.

agreement from a few maintainers on the call to get reviews completed soon, no disagreement on the general direction and wording.

I think that people trying to understand pre-existing registries also read the spec, so I can at least see value linking to something in that use case. Either way, I'd rather drop this sooner than later, so this is fine.

Thanks Jimmy,
Are you ok if we don’t reference it? You’ve got this mares as requesting the change.
I’m sure there are many places to get the info. Just keeping the spec as clean as possible.

I'm fine with not including it because it keeps the spec more self contained and will only become more irrelevant over time.

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

jzelinskie · 2019-10-15T14:03:27Z

LGTM

SteveLasker · 2019-10-21T22:35:00Z

@mikebrow, can we merge this?

vbatts · 2019-10-21T22:37:03Z

LGTM

mikebrow · 2019-12-16T20:33:20Z

@mikebrow, can we merge this?

thx for merging vince... missed the @ ping from Steve... something about my daughter having a daughter that week :)

vbatts · 2019-12-16T21:02:58Z

:-D

SteveLasker · 2019-12-16T23:33:56Z

@mikebrow wow, congrats. That's something to celebrate!

mikebrow approved these changes Oct 9, 2019

View reviewed changes

dmcgowan approved these changes Oct 9, 2019

View reviewed changes

SteveLasker mentioned this pull request Oct 11, 2019

Moves _catalog as required to reserved #73

Closed

jzelinskie requested changes Oct 11, 2019

View reviewed changes

Remove _catalog API, reference as reserved

b4e9833

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

jzelinskie added this to the v1.0.0-rc1 milestone Oct 15, 2019

jzelinskie approved these changes Oct 15, 2019

View reviewed changes

jonjohnsonjr mentioned this pull request Oct 18, 2019

Support docker private registry API google/crfs#14

Open

vbatts merged commit add4980 into opencontainers:master Oct 21, 2019

jonjohnsonjr mentioned this pull request Nov 21, 2019

Use Link header for pagination google/go-containerregistry#607

Merged

vbatts mentioned this pull request Sep 30, 2020

1.0.0-rc1 #190

Merged

This was referenced Nov 4, 2021

_catalog reserved reference missing from the current spec #306

Closed

What do you want to see in OCI Support? helm/helm#10312

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove _catalog API, reference as reserved #69

Remove _catalog API, reference as reserved #69

SteveLasker commented Aug 16, 2019 •

edited

Loading

mikebrow commented Aug 16, 2019

hallyn commented Oct 6, 2019

SteveLasker commented Oct 7, 2019

hallyn commented Oct 7, 2019

vbatts commented Oct 9, 2019

SteveLasker commented Oct 9, 2019

vbatts commented Oct 9, 2019 via email

SteveLasker commented Oct 9, 2019

mikebrow left a comment

dmcgowan left a comment

jzelinskie left a comment

jzelinskie Oct 11, 2019

SteveLasker Oct 11, 2019 •

edited

Loading

jzelinskie Oct 15, 2019

SteveLasker Oct 15, 2019

jzelinskie Oct 15, 2019

jzelinskie commented Oct 15, 2019 •

edited by caniszczyk

Loading

SteveLasker commented Oct 21, 2019

vbatts commented Oct 21, 2019 •

edited by caniszczyk

Loading

mikebrow commented Dec 16, 2019

vbatts commented Dec 16, 2019

SteveLasker commented Dec 16, 2019

Remove _catalog API, reference as reserved #69

Remove _catalog API, reference as reserved #69

Conversation

SteveLasker commented Aug 16, 2019 • edited Loading

mikebrow commented Aug 16, 2019

hallyn commented Oct 6, 2019

SteveLasker commented Oct 7, 2019

hallyn commented Oct 7, 2019

vbatts commented Oct 9, 2019

SteveLasker commented Oct 9, 2019

vbatts commented Oct 9, 2019 via email

SteveLasker commented Oct 9, 2019

mikebrow left a comment

Choose a reason for hiding this comment

dmcgowan left a comment

Choose a reason for hiding this comment

jzelinskie left a comment

Choose a reason for hiding this comment

jzelinskie Oct 11, 2019

Choose a reason for hiding this comment

SteveLasker Oct 11, 2019 • edited Loading

Choose a reason for hiding this comment

jzelinskie Oct 15, 2019

Choose a reason for hiding this comment

SteveLasker Oct 15, 2019

Choose a reason for hiding this comment

jzelinskie Oct 15, 2019

Choose a reason for hiding this comment

jzelinskie commented Oct 15, 2019 • edited by caniszczyk Loading

SteveLasker commented Oct 21, 2019

vbatts commented Oct 21, 2019 • edited by caniszczyk Loading

mikebrow commented Dec 16, 2019

vbatts commented Dec 16, 2019

SteveLasker commented Dec 16, 2019

SteveLasker commented Aug 16, 2019 •

edited

Loading

SteveLasker Oct 11, 2019 •

edited

Loading

jzelinskie commented Oct 15, 2019 •

edited by caniszczyk

Loading

vbatts commented Oct 21, 2019 •

edited by caniszczyk

Loading