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

Add artifacts proposal #60

Merged
merged 4 commits into from Aug 21, 2019
Merged

Add artifacts proposal #60

merged 4 commits into from Aug 21, 2019

Conversation

@SteveLasker
Copy link
Contributor

@SteveLasker SteveLasker commented Jul 25, 2019

based on discussion during the OCI Call on July 17, 2019 and feedback on Artifact registry support #65, proposing a new repository for artifacts
Signed-off-by: stevenlasker@hotmail.com

@caniszczyk
Copy link
Contributor

@caniszczyk caniszczyk commented Jul 25, 2019

RFC @opencontainers/tob

Also can you amend the commit @SteveLasker and sign off via 'git commit -s'

Loading

@caniszczyk caniszczyk requested a review from Jul 25, 2019
proposals/artifacts.md Show resolved Hide resolved
Loading
SteveLasker added 2 commits Aug 6, 2019
Signed-off-by: stevenlasker@hotmail.com

Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
estesp
estesp approved these changes Aug 7, 2019
Copy link
Contributor

@estesp estesp left a comment

LGTM

Loading

@thecloudtaylor
Copy link

@thecloudtaylor thecloudtaylor commented Aug 7, 2019

LGTM

Loading

@caniszczyk
Copy link
Contributor

@caniszczyk caniszczyk commented Aug 7, 2019

I sent an email to the @opencontainers/tob and dev@ list for a final RFC before we vote on this formally next week: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/yBV-lE3BZHo

Loading

proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
Copy link
Member

@dmcgowan dmcgowan left a comment

LGTM

Loading

@vsoch
Copy link
Contributor

@vsoch vsoch commented Aug 8, 2019

What will be the guidelines for contributing artifacts? There haven't been clear guidelines in the past about what can be contributed, and who can do it, so let's get it spot on here. :L)

Loading

@estesp
Copy link
Contributor

@estesp estesp commented Aug 8, 2019

@vsoch I assume you mean contributing artifact types? The proposal states the new repo will be a clearing house for well known artifact types. If accepted, just like any other OCI new repo/spec/project, it is up to the maintainers of the specific repo to determine acceptance criteria, and I believe Steve's word choice of well-known would apply to this example:

If I have a personal registry in which I archive binary blobs which are actually just super-cool pictures of my pet rat, and I've created a metadata type for cool.rat.pics it probably doesn't need to reside in a registry of well-known artifact types. And I would hope the maintainers would recognize that and politely ask me to not submit my artifact type to the OCI artifact repo.

I believe instead you are referring to the potential frustration (which I think I acknowledged in your proposal discussion) that the OCI's charter potentially wasn't clear to new participants as to what the scope of "things that should exist under the OCI umbrella." That is the only thing the TOB has purview on, and I hope we've clarified that the OCI has a narrow scope, specified by charter, focused on the definition of runtime, images, and distributing "image" artifacts. Hopefully that is much different than a random affinity to turn away contributions and contributors randomly, and if it ever appeared like that, I am truly sorry.

Loading

@vsoch
Copy link
Contributor

@vsoch vsoch commented Aug 8, 2019

You have a pet rat? :)

I would specifically be interested in adding the Singularity (sif) binary type, and I'm wondering if that passes the threshold for well known. My original question is around this - give some kind of artifact appropriate for a registry, which is a standard for some (possibly well known?) software, can there be more clear criteria than "well known?" I think the distinction would be fairly clear for some artifacts, but I would expect there to be a gray zone when you get to lesser known container technologies, or more niche files associated with well known technologies. While it's a hard problem, I'm hoping that more clear criteria, or a clear process for determining inclusion, could be added to the proposal. Someone that wants to contribute should see this information, clearly presented.

Loading

@estesp
Copy link
Contributor

@estesp estesp commented Aug 8, 2019

Fair point @vsoch; but as you note I'm not sure you could ever create exhaustive and undisputable criteria for something like "well-known," but maybe it's worth trying to be a bit more specific? I'll let @SteveLasker chime in here as it is his proposal.

But, to specifically address SIF, I don't see how that would even be a gray area. There is an open source project, a company, and an enterprise product with some level of adoption that is behind the format. A major cloud provider's registry already accepts your format. Although my pet rat was mythical (sorry), the contrast is night and day. To me, that's the kind of adoption data that would make a clear case between "my pet project that only I use" and something that easily meets the criteria. How many things are in the middle gray area I don't know. But given the purpose of the artifact registry, I'm not sure why anyone would care to be in the artifact repo if you don't already have adoption. This doesn't make certain formats "OCI compliant" or allow for any promotion beyond what those formats already get--it is just a hinting tool for implementors/operators of registries to know type details and have some guidance around formats that are already being used so they can decide on support/inclusion with respect to their registry implementation.

Loading

@vsoch
Copy link
Contributor

@vsoch vsoch commented Aug 8, 2019

I didn't mean SIF as an example for something in the gray zone (I don't think it is).

Loading

@SteveLasker
Copy link
Contributor Author

@SteveLasker SteveLasker commented Aug 8, 2019

The overall process is a good question, that I defer to the TOB maintainers.
For the artifact types, Phil covered the majority of the thought process, thus far. The one thing I realized might not have been clear, was where do the artifact media-type definitions reside.
The artifacts, themselves, such as SIF and Helm would exist in their respective repos. Public or private. However, I'm proposing the media-types promoted for a specific artifact type would be submitted as PR to this new artifac repo. See Defining Artifact Types in this PR. It describes the process by which someone can submit their artifact media-type definition. It covers the actual container image artifact type, as well as SIF and Helm. Registry operators can pull these definitions as an ingress to their opt-in/out filtering. We'll get into more detail when the repo PR comes through.

I've defined a few artifactTypes, including SIF that would be submitted to this repo.

The pet rat, SIF are great examples. If the artifact types aren't meant for broad consumption, they wouldn't be submitted. Phil could try and submit his pet rat type, and if it was thought to be broad use, it might get approved. I expect the majority of the feedback would be two stages:

  1. does the artifact meet the sniff test of broad consumption, that other registries would be interested in
  2. does the mediaType have a unique id, meaningful display name, and does the logo exist in good taste.

I realize these can be somewhat subjective, which is why I made the "good taste" reference. By having several maintainers, we should be able to avoid the opinions of one.

Loading

Copy link

@garethr garethr left a comment

A few minor wordage things, but LGTM.

Regarding the process of submission, I think is is better to be explicit than implicit here. Maybe adding something like:

  1. Proposals for new artifact types should be opened as pull requests on the artifact repository
  2. The artifact project maintainers will review new proposals, ask clarifying questions, and choose or not to accept the suggested artifact type
  3. Acceptance requires at least 2 +1s from the maintainers (currently 3 maintainers)
  4. Where the submitter disagrees strongly with the decision they can bring to the issue to the TOB for a vote, under the current voting rules (printed below for reference)

In various situations (2.c, 6.h, 6.j, 6.n) the TOB shall hold a vote. These votes can happen on the phone, email, or via a voting service, when appropriate.

TOB members can either respond "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes with two-thirds vote of votes cast. An abstain vote equals not voting at all.

I think at present 1 and 2 are assumed, and 3 and 4 are undefined, but probably assumed. Better to write down those assumptions so everyone is in agreement.

Another edge case that might be worth calling out. media types and legally protected words.

For example, I worked on defining media types of Open Policy Agent, and we used the prefix vnd.cncf.openpolicyagent. Now I'm not technically affiliated with CNCF, nor Open Policy Agent. Can:

  1. I just submit that anyway and it's a case by case decision for the process above
  2. Need supporting evidence that we have agreement from the open policy agent project (which is what happened in this case)
  3. Need supporting evidence that we've talked with CNCF

Wanted to raise, 1 is certainly simpler but risks inconsistencies.

Loading

proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
Copy link
Member

@mikebrow mikebrow left a comment

LGTM overall... see nit comments

Loading

proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
@SteveLasker
Copy link
Contributor Author

@SteveLasker SteveLasker commented Aug 9, 2019

Another edge case that might be worth calling out. media types and legally protected words.

For example, I worked on defining media types of Open Policy Agent, and we used the prefix vnd.cncf.openpolicyagent. Now I'm not technically affiliated with CNCF, nor Open Policy Agent. Can:

  1. I just submit that anyway and it's a case by case decision for the process above
  2. Need supporting evidence that we have agreement from the open policy agent project (which is what happened in this case)
  3. Need supporting evidence that we've talked with CNCF

Wanted to raise, 1 is certainly simpler but risks inconsistencies.

This is a great area to think about. I didn't put it in the repo proposal as I expect we'll iterate quite a bit when we make the PR. I would suggest this is the case for any PR, where the content must pass some ownership boundaries. However, when we identify the process for submitting artifact PRs, within the repo, calling out the submission must have some ownership of the namespace they are claiming is important.

The thing I'm trying to avoid is clogging up the creation of the repo process, with the actually content of the repo as we do separate PRs.

Loading

Copy link
Member

@mikebrow mikebrow left a comment

/LGTM
see nits

Loading

proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
@caniszczyk
Copy link
Contributor

@caniszczyk caniszczyk commented Aug 15, 2019

Loading

proposals/artifacts.md Outdated Show resolved Hide resolved
Loading
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
@vbatts
Copy link
Member

@vbatts vbatts commented Aug 16, 2019

LGTM

Loading

@caniszczyk
Copy link
Contributor

@caniszczyk caniszczyk commented Aug 20, 2019

There are now enough @opencontainers/tob votes for this to pass, we will officially close the vote tomorrow per the process

Loading

@caniszczyk
Copy link
Contributor

@caniszczyk caniszczyk commented Aug 21, 2019

+1 votes from the @opencontainers/tob have hit supermajority (7/9)

https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/zkIbBwwFlCQ

  • Taylor
  • Phil
  • Derek
  • Vincent
  • Michael
  • Jon
  • Steve

Loading

@caniszczyk caniszczyk merged commit 440c771 into opencontainers:master Aug 21, 2019
1 check passed
Loading
@SteveLasker SteveLasker deleted the artifacts branch Aug 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet