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

Conversation

@SteveLasker
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2019

RFC @opencontainers/tob

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

@caniszczyk caniszczyk requested a review from opencontainers/tob Jul 25, 2019

SteveLasker added some commits Jul 25, 2019

Add artifacts proposal
Signed-off-by: stevenlasker@hotmail.com

Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
incorporate versioning feedback, resolve typos
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch from e450acf to ecbb378 Aug 6, 2019

@estesp

estesp approved these changes Aug 7, 2019

Copy link

left a comment

LGTM

@taylorb-microsoft

This comment has been minimized.

Copy link

commented Aug 7, 2019

LGTM

@caniszczyk

This comment has been minimized.

Copy link
Contributor

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

proposals/artifacts.md Outdated Show resolved Hide resolved
Add clarity for media-type filtering
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
@dmcgowan
Copy link
Member

left a comment

LGTM

@vsoch

This comment has been minimized.

Copy link
Contributor

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)

@estesp

This comment has been minimized.

Copy link

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.

@vsoch

This comment has been minimized.

Copy link
Contributor

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.

@estesp

This comment has been minimized.

Copy link

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.

@vsoch

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

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

@SteveLasker

This comment has been minimized.

Copy link
Contributor Author

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.

@garethr
Copy link

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.

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

left a comment

LGTM overall... see nit comments

proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved
@SteveLasker

This comment has been minimized.

Copy link
Contributor Author

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.

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch 2 times, most recently from 14b4920 to 1b7003d Aug 9, 2019

@mikebrow
Copy link
Member

left a comment

/LGTM
see nits

proposals/artifacts.md Outdated Show resolved Hide resolved
proposals/artifacts.md Outdated Show resolved Hide resolved

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch from 1b7003d to 1c78362 Aug 12, 2019

proposals/artifacts.md Outdated Show resolved Hide resolved

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch from 1c78362 to 2677c76 Aug 13, 2019

proposals/artifacts.md Outdated Show resolved Hide resolved

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch from 2677c76 to 9600beb Aug 14, 2019

proposals/artifacts.md Outdated Show resolved Hide resolved

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch from 9600beb to c7950d9 Aug 14, 2019

@caniszczyk

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2019

proposals/artifacts.md Outdated Show resolved Hide resolved
Add stevvooe as maintainer
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>

@SteveLasker SteveLasker force-pushed the AzureCR:artifacts branch from c7950d9 to 41b78f6 Aug 15, 2019

@vbatts

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

LGTM

@caniszczyk

This comment has been minimized.

Copy link
Contributor

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

@caniszczyk

This comment has been minimized.

Copy link
Contributor

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

@caniszczyk caniszczyk merged commit 440c771 into opencontainers:master Aug 21, 2019

1 check passed

DCO DCO
Details

@SteveLasker SteveLasker deleted the AzureCR:artifacts branch Aug 21, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.