Giter VIP home page Giter VIP logo

Comments (13)

vbatts avatar vbatts commented on June 4, 2024 6

I for one am on board for a rename of image spec and clarification of the different structures.

Since it was brought up recently about moving something like the descriptor from image-spec into distribution-spec, it was pointed out that this would be a breaking change.
This kind of breaking changes will be the focus

from wg-reference-types.

jdolitsky avatar jdolitsky commented on June 4, 2024 1

Seems like we are on the same page on this, closing

from wg-reference-types.

SteveLasker avatar SteveLasker commented on June 4, 2024

The OCI Artifacts repo was always intended to evolve to support broader scenarios. We said it was scoped, at the time, but I don't think it was ever said it couldn't evolve, rather it needs TOB approval to become a spec.
My personal opinion has always been the artifacts repo should converge into the distribution-spec, as the distribution-spec should have the manifest definitions for what it supports. This is simply the evolution that the distribution-spec supports all types of artifacts (container images, helm charts, signatures, sboms, bicep modules, etc.)

from wg-reference-types.

imjasonh avatar imjasonh commented on June 4, 2024

The OCI Artifacts repo was always intended to evolve to support broader scenarios. We said it was scoped, at the time, but I don't think it was ever said it couldn't evolve, rather it needs TOB approval to become a spec. My personal opinion has always been the artifacts repo should converge into the distribution-spec, as the distribution-spec should have the manifest definitions for what it supports. This is simply the evolution that the distribution-spec supports all types of artifacts (container images, helm charts, signatures, sboms, bicep modules, etc.)

I don't think the intention of the WG was to propose anything to the artifacts repo. Instead, I believe we intend to propose changes to the existing OCI specs (somebody please correct me if I'm wrong).

How and whether artifacts evolves toward becoming a spec, or part of a spec, feels separate and orthogonal to me in answering how (or whether) the reference types WG's proposals land in OCI specs.

from wg-reference-types.

jdolitsky avatar jdolitsky commented on June 4, 2024

The only reason I mention anything besides image-spec/distribution-spec is the new manifest type being proposed in Proposal E: https://github.com/opencontainers/wg-reference-types/blob/main/docs/proposals/PROPOSAL_E.md#artifact-spec

Where would that belong? In my opinion, this either

  1. Lands in image-spec alongside other documentation for supported manifest types
  2. Lands in a new artifact-spec repo that feels similar to image-spec

from wg-reference-types.

mikebrow avatar mikebrow commented on June 4, 2024

The only reason I mention anything besides image-spec/distribution-spec is the new manifest type being proposed in Proposal E: https://github.com/opencontainers/wg-reference-types/blob/main/docs/proposals/PROPOSAL_E.md#artifact-spec

Where would that belong? In my opinion, this either

  1. Lands in image-spec alongside other documentation for supported manifest types
  2. Lands in a new artifact-spec repo that feels similar to image-spec

or distribution spec, or rename/rescope artifacts, or some other combination...

is a good sign the wg is getting closer to a proposal/output :-)

from wg-reference-types.

dlorenc avatar dlorenc commented on June 4, 2024

The simplest option to me seems to be be to keep the new manifest types in image-spec, and perhaps consider renaming it later. It already includes other types such as descriptor and index, so another one isn't that far from where we are today.

Then the new API changes would live in distribution-spec.

from wg-reference-types.

SteveLasker avatar SteveLasker commented on June 4, 2024

Proposal: Decoupling Registries from Specific Artifact Specs #91

from wg-reference-types.

sudo-bmitch avatar sudo-bmitch commented on June 4, 2024

Ultimately, this will be a TOB decision. (Perhaps tagging @opencontainers/tob will raise some visibility).

I believe we will have changes to image-spec and distribution-spec that will document here and then raise as PR's to this projects.

For artifact-spec, we can define what that should look like as a folder within the WG repo. Once we get to that point, the TOB can make the decision on whether that gets pushed as a new repo, artifacts gets renamed and extended with new content, or artifacts gets merged into the new artifacts-spec repo.

The other option I thought about for artifact-spec was to create a new repo and have the WG populate it ourselves. That might get more complicated with sorting out maintainers of the new repo just to make the proposal, so I was leaning towards the simple solution of a directory in this repo.

The simplest option to me seems to be be to keep the new manifest types in image-spec, and perhaps consider renaming it later. It already includes other types such as descriptor and index, so another one isn't that far from where we are today.

I was pushing for that early on, but it got shot down. I believe the image-spec maintainers want to limit the scope of their repo.

from wg-reference-types.

dlorenc avatar dlorenc commented on June 4, 2024

I was pushing for that early on, but it got shot down. I believe the image-spec maintainers want to limit the scope of their repo.

Do you have a link to that? I don't remember it :(

Keeping all the manifest specs together seems the simplest to me. The maintainers have changed, so it might be worth revisiting.

from wg-reference-types.

sudo-bmitch avatar sudo-bmitch commented on June 4, 2024

I'm not sure when exactly that was, but I'm pretty sure it was within the last year. @samuelkarp may remember.

from wg-reference-types.

samuelkarp avatar samuelkarp commented on June 4, 2024

Thanks for the tag @sudo-bmitch!

I believe the image-spec maintainers want to limit the scope of their repo.

I don't really have a memory of this, but possibly opencontainers/image-spec#907 (@vbatts) is relevant here as it implies that the image-spec maintainers think things-that-are-not-images might not belong in the image-spec?

The simplest option to me seems to be be to keep the new manifest types in image-spec, and perhaps consider renaming it later. It already includes other types such as descriptor and index, so another one isn't that far from where we are today.

Then the new API changes would live in distribution-spec.

My initial inclination is to agree with this, but (a) I'm not speaking on behalf of the TOB here, (b) I haven't really been following the WGs efforts so I'm not up to date on the details of any proposal, and (c) I'd want to hear both what the WG itself wants to propose as well as what the image-spec maintainers think about it.

is a good sign the wg is getting closer to a proposal/output :-)

💯 I'm excited to see that we're getting closer!

from wg-reference-types.

jdolitsky avatar jdolitsky commented on June 4, 2024

I for one am on board for a rename of image spec and clarification of the different structures.

@vbatts we discussed on the call and agree we should go this general direction.

Maybe rename image-spec to github.com/opencontainers/schema with subdirectories:

  • artifact-spec/
  • image-spec/

??

Either way, we seemed to agree on 2 PRs as the initial output of this working group:

  1. To image-spec: Modification of existing spec and adding new artifact-spec
  2. To distribution-spec: Addition of new referrers API endpoints

from wg-reference-types.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.