[CentOS-devel] CentOS SIGs and lookaside cache

Mon Feb 21 16:22:08 UTC 2022
Neal Gompa <ngompa13 at gmail.com>

On Mon, Feb 21, 2022 at 11:16 AM Pierre-Yves Chibon <pingou at pingoured.fr> wrote:
> On Mon, Feb 21, 2022 at 10:58:58AM -0500, Neal Gompa wrote:
> > On Mon, Feb 21, 2022 at 10:51 AM Pierre-Yves Chibon <pingou at pingoured.fr> wrote:
> > The git server and git structure is orthogonal to the lookaside
> > problem. Fundamentally, the issue was that the same upload endpoint is
> > used for both Red Hat compliance and SIG work. We already have
> > authentication/authorization on branches at the Pagure level, so we
> > just lacked a way to handle this for the lookaside upload. By
> > splitting the endpoint, it should be possible to solve that since you
> > can deny access to the Red Hat endpoint to everyone.
> >
> > However, I'd make a small suggestion: instead of changing the endpoint
> > URL for SIGs, change the endpoint URL for Red Hat. RCM uses that
> > endpoint through automation (I assume), so changing the endpoint for
> > the one service is considerably simpler than dealing with everyone's
> > own scripts to adjust for SIGs.
> That is an interesting point, I'll ask around to know how feasible it would be.
> > As an example, I've written automation to deal with Hyperscale work
> > because doing it by hand is a lot of grunt work. While I can probably
> > tweak my stuff easily enough, I don't know if *everyone* can.
> Your automation doesn't use the `lookaside_upload` script from
> centos-git-commoin then?

I have a vendored copy of stuff from centos-git-common. But other
people may have taken different approaches.

> > And again, the lookaside thing is completely orthogonal to the git
> > structure. I should be able to use it just fine from git.centos.org in
> > the current branched package structure.
> I agree, though dropping the branch structure that git.centos.org imposes
> exacerbates this.
> I don't know that we want to change the current structure used for all SIGs (vs
> making it opt-in), but it is an interesting thought.

There are some advantages to the existing per-branch structure. I've
used to easily sync and merge Hyperscale modifications onto c8s
packages for Hyperscale 8 package builds. That benefit will be gone
with c9s, but it was handy with c8s.

真実はいつも一つ!/ Always, there's only one truth!