Add artifacts proposal

[SteveLasker]

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]

RFC @opencontainers/tob

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

[estesp]

LGTM

[thecloudtaylor]

LGTM

[caniszczyk]

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

[dmcgowan]

LGTM

[vsoch]

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)

[estesp]

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

[vsoch]

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.

[estesp]

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.

[vsoch]

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

[SteveLasker]

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.

[garethr]

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.

[mikebrow]

LGTM overall... see nit comments

[SteveLasker]

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.

[mikebrow]

/LGTM
see nits

[caniszczyk]

FYI @opencontainers/tob can you please send your vote to this mail thread:
https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/zkIbBwwFlCQ

[vbatts]

LGTM

[caniszczyk]

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

[caniszczyk]

+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