Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2 tag routes #4

Open
h3kker opened this issue Apr 18, 2022 · 3 comments
Open

v2 tag routes #4

h3kker opened this issue Apr 18, 2022 · 3 comments

Comments

@h3kker
Copy link

h3kker commented Apr 18, 2022

I was wondering about the /v2/tags routes that are used in the scs-library-client:

https://github.com/sylabs/scs-library-client/blob/eeab0e8dd3a70c3b0d448e7fc0768db67b3646ad/client/api.go#L271

https://github.com/sylabs/scs-library-client/blob/eeab0e8dd3a70c3b0d448e7fc0768db67b3646ad/client/api.go#L243

They're also missing in the openapi.yml, are they not for "public consumption"? I've implemented them in hinkskalle, it's been a while, I think it was because when you report api version 2.0.0-alpha.2 singularity uses this to get/set arch-specific tags.

@vsoch
Copy link
Member

vsoch commented Apr 18, 2022

I recall tags being part of v1 maybe? https://github.com/singularityhub/sregistry/blob/a076fc15c1322fa2e145067c38825c8575168b56/shub/apps/library/urls.py#L64. For the updated version I think tagging was a bit of an afterthought - like do the whole interaction first and then tell the registry the tag to apply. Ping @dtrudg in case he doesn't see this (he will know the right person to ask!)

In terms of what should be part of the spec here, I would say endpoints that are essential for the main push pull, and then implementations are free to vary from that.

@dtrudg
Copy link

dtrudg commented Apr 18, 2022

I believe that the omission of the v2/tags from the public spec was intentional, when @tri-adam and @EmmEff were preparing that.

The general intent was for the OpenAPI spec file to list the required stable set of endpoints, and not to include things that may have been less than perfectly stable across versions of our (private) server implementations. There are definitely pieces of scs-library-client code that have been added, but might be supporting functionality that was later deprecated. For various reasons, the Singularity client side might have to cope with behavior around these (hence they are still represented in scs-library-client code)... but a third party server shouldn't have to implement them.

Pining @tri-adam to see if there's any more context we can add here.

@h3kker
Copy link
Author

h3kker commented Apr 19, 2022

so the safer bet would be to report version 2.0.0-alpha.1 like in

"apiVersion": "2.0.0-alpha.1"
? that would make the scs-library-client use the non-arch-specifig /v1/tags and there's no need to offer the /v2/tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants