Skip to content
This repository has been archived by the owner on Sep 23, 2022. It is now read-only.

How do we propose these changes land across OCI repos? #62

Closed
jdolitsky opened this issue Jul 7, 2022 · 13 comments
Closed

How do we propose these changes land across OCI repos? #62

jdolitsky opened this issue Jul 7, 2022 · 13 comments

Comments

@jdolitsky
Copy link
Member

Came up during the general call today-

  • What parts are to be proposed in distribution-spec
  • What parts are to be proposed in image-spec
  • What parts are to be proposed in artifacts?
  • Will we require a new repo (e.g. "artifact-spec") for the new manifest type?

Is this a recommendation that should from from the WG or TOB?

cc @SteveLasker @sajayantony @sudo-bmitch @mikebrow

@SteveLasker
Copy link
Contributor

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.)

@imjasonh
Copy link
Member

imjasonh commented Jul 7, 2022

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.

@jdolitsky
Copy link
Member Author

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

@mikebrow
Copy link
Member

mikebrow commented Jul 7, 2022

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 :-)

@dlorenc
Copy link

dlorenc commented Jul 7, 2022

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.

@SteveLasker
Copy link
Contributor

@sudo-bmitch
Copy link
Contributor

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.

@dlorenc
Copy link

dlorenc commented Jul 8, 2022

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.

@sudo-bmitch
Copy link
Contributor

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

@samuelkarp
Copy link
Member

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!

@vbatts
Copy link
Member

vbatts commented Jul 8, 2022

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

@jdolitsky
Copy link
Member Author

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

@jdolitsky
Copy link
Member Author

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

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

No branches or pull requests

8 participants