Cincinnati is periodically (each 5m) listing all tags in quay.io/openshift-release-dev/ocp-release to discover newly added releases to be added into the upgrade graph it serves.

Such poll it inefficient (especially given the quay.io/openshift-release-dev/ocp-release has over 7k tags) and expensive, and it is known to fail occasionally when Quay is under some kind of load (PROJQUAY-5502 discussed on Slack https://redhat-internal.slack.com/archives/C7WH69HCY/p1679913378496759).

It was suggested that Cincinnati could use Quay webhooks (https://docs.quay.io/guides/notifications.html) to be informed about new releases instead of the expensive polling.

This would likely need to be optional and possibly non-default. The heavy RH OSUS instance would set this to avoid polling quay.io/openshift-release-dev/ocp-release. The customer-run OSUS instances would likely not need this, because 1) they do not process that many tags 2) they would depend on Quay (not possible in restricted network?) and have its setup more complicated.

We should have a safeguard that if triggered continuously, there should be some delay or minimum time before we hit quay again. 

What if the endpoint just reaches one graph-builder pod?

Definition of Done: 

• Discuss the architecture of how this will work on prod OSUS
• create follow up cards to implement this.