Adding artifactType filtering to the Referrers API

[michaelb990]

Draft PR on top of #59 to add artifactType filtering in the Referrers API.

Pros:

• Enables registries and clients to more easily work with large numbers of references for an image.
• Prevents a use case which pushes large numbers of artifacts from impacting the performance of latency sensitive use cases.

Cons:

• Fragments registry behavior because not all registries may end up supporting this, so clients will still need a fall back.
• Only allows for filtering based on artifactType, not other fields or annotations.

[jdolitsky]

Please rebase as #59 is in

[jdolitsky]

this is probably to go away depending on #72

[jdolitsky]

should this be codified into the proposal?

[sajayantony]

So from the discussion just an indication of the field without he values makes the response for unmatched artifacts cachable.

[sajayantony]

As a part of the response are all annotations expected to be returned in the referrers /cc @michaelb990

[jdolitsky]

I've gone ahead and resolved merge conflicts / committed suggested changes to keep this moving. @michaelb990 - is this ready for review/merge?

[sudo-bmitch]

I've gone ahead and resolved merge conflicts / committed suggested changes to keep this moving. @michaelb990 - is this ready for review/merge?

On the WG meeting last week, I think we ended up unsure if this made sense to implement since it would result in added complexity for registry servers that would reduce the ability to cache the output, and clients already have client-side filtering implemented to support the tag output and any registries that don't support filtering. Lets save this for a merge or close decision on tomorrow's meeting.

[michaelb990]

@sudo-bmitch

On the WG meeting last week, I think we ended up unsure if this made sense to implement since it would result in added complexity for registry servers that would reduce the ability to cache the output, and clients already have client-side filtering implemented to support the tag output and any registries that don't support filtering. Lets save this for a merge or close decision on tomorrow's meeting.

• Does the fact that it is a SHOULD not a MUST help with the complexity worries?
• The recent updates to the annotations should solve the caching issues.
• I think not having server-side filtering is one of the big drawbacks of the tagging scheme, so I'm hoping we see things move to server-side solutions "soon".

Will post to a vote.

[sajayantony]

LGTM for merging once the vote is in. Any minor adjustments can be made post merge in my opinion.

[sudo-bmitch]

• Does the fact that it is a SHOULD not a MUST help with the complexity worries?

I'd lean towards MAY, but that's not a strong opinion.

• The recent updates to the annotations should solve the caching issues.

Thank you!

• I think not having server-side filtering is one of the big drawbacks of the tagging scheme, so I'm hoping we see things move to server-side solutions "soon".

Will post to a vote.

The big advantage of having the API to me isn't filtering, but the lack of client side maintenance of the tag, and elimination of race conditions. (Plus it declutters the tag listing.) Thanks for getting the vote out. 👍

[dlorenc]

+1 here too. Thanks!

[rchincha]

lgtm