quay/mirror-registry

Clarity around mirror-registry & upstream quay releases

BadgerOps opened this issue · 3 comments

Howdy all!

I am hoping to get some clarity around how mirror-registry tracks to upstream Quay releases. This currently appears to be a manual process, looking at previous PR's.

What triggered this question is https://access.redhat.com/errata/RHSA-2023:7341 and an attempt to figure out a good process on our end for rolling out patched builds.

If there is already a conversation going on, cool - if not, I'd be happy to collaborate on a process to track releases based on upstream RH releases.

Cheers,

BadgerOps

@BadgerOps Yeah, that's right. It's a manual process at the moment, but might be able to be automated in the future based on Quay upstream releases. We've typically tried to get the latest Quay release into mirror registry the week following a Quay release, however, with the Quay v3.10.0 release I think we encountered an issue kept it on the v3.9.x branch. This should change with v3.11.0.

It might be good to call out that we're making some heavy changes to mirror registry to try and shrink it's footprint. We are aiming to release a v2.0.0 around the end of the quarter that will replace Postgres with SQLite. You can see the current proposal here: https://github.com/quay/enhancements/pull/26/files.

Ok, I'm excited to see the direction there, imho reducing moving parts is a fantastic move for mirror-registry. I definitely get the complexity in automatically tracking to upstream, especially with the difficulty in regression testing multiple systems that don't exactly lend to automated testing.

➕ for SQLite.

Closing this since there is a path forward mentioned