[Vote] Should we switch to predictable digest tags

[sudo-bmitch]

To pick a direction for #61 on whether we want to use predictable tags or use unique tags that require a tag listing to avoid race conditions, please vote on this issue. We'll leave this open for 1 week and move forward based on the results in the 2022-07-29 meeting. Vote by giving one of the below comments a thumbs up.

[sudo-bmitch]

Yes, switch to predictable tags. This includes the possible option to include the artifact type in the tag name.

[sudo-bmitch]

No, use unique tags, one per artifact.

[imjasonh]

My own personal pro/con list:

• Predictable tags let you discover attached content without using the list API and making potentially many paginated requests.
• Unique tags give you some protection against race conditions when updating.

Given those trade-offs, I'd prefer to push for better race condition handling in distribution-spec and in registry implementations, which leaves predictable tags as the better solution since discovering content doesn't require listing.

[Jamstah]

Does anyone get to vote?

I would say that race condition handling is worse than pagination, and that with pagination generally implemented using the last syntax, you can quite easily start at the right point (list from sha256-[digest].) so there isn't too much overhead.

So my vote would be a no, but I won't hit the button because I'm not a member of the WG :)

[dlorenc]

Does anyone get to vote?

Yep! Anyone can vote, go ahead and hit the button.

[dlorenc]

I agree with Jason. We've used the predictable tags method in cosign for a while now, and while the race condition is real I can't recall anyone ever hitting it. I'd lean toward fixing that in the distribution-spec.

I'd feel much differently if people were regularly running into the race condition.

[Jamstah]

Yep! Anyone can vote, go ahead and hit the button.

Thanks, I'm the only no vote but you know, doing my part for democracy :)

while the race condition is real I can't recall anyone ever hitting it.

Dangerous way to think about race conditions, they're harmless until you hit them, then they're deadly (IMO). As artifacts get popular I can imagine many build processes will generate an image then spawn off multiple processes to sign etc which could easily start to race. By then we'd hopefully not be using the tags anymore though, so maybe it doesn't matter.

I'd lean toward fixing that in the distribution-spec.

I think that's worth doing regardless!

[nishakm]

Is using the predictable tags dependent on fixing the race condition issue in the distribution spec?

[imjasonh]

Is using the predictable tags dependent on fixing the race condition issue in the distribution spec?

I wouldn't say "dependent" exactly (i.e., that we should block this decision on the outcome of opencontainers/distribution-spec#251), but that we expect questions about handling race conditions to be solved by distribution-spec, and not build workarounds for that in this spec.

[sudo-bmitch]

Is using the predictable tags dependent on fixing the race condition issue in the distribution spec?

I suspect the reality will be inversed. We may approve a spec with a known race condition for existing registries. And new registries may fix race conditions, but they'll also add the new API to query referrers, negating the need to fix race conditions in this spec (fixing race conditions in distribution-spec still has value outside of this spec).

[jdolitsky]

Based on the vote alone, we are planning to go with the first option:

Yes, switch to predictable tags. This includes the possible option to include the artifact type in the tag name.

@sudo-bmitch to follow up with PR to clarify