[CentOS-devel] CentOS SIGs and lookaside cache

Mon Feb 28 14:51:28 UTC 2022
Neal Gompa <ngompa13 at gmail.com>

On Mon, Feb 28, 2022 at 9:48 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.
> I have just realized something, I don't think we're planning on restricting the
> access to the old lookaside upload script (the idea you're talking about in the
> first paragraph), so if we are not, we are not breaking backward compatibility,
> just introducing/offering another way to do things:
> - either you keep your current workflow and upload as you do today with the
>   current lookaside upload endpoint
> - or you adjust your workflow and upload to the lookaside cache using the new
>   endpoint.
> Both approach would work equally well.
> And this is where it does ties the git server and git structure to the
> lookaside, if a SIG keeps using git.centos.org, they will have to keep using the
> current branch structure and thus changing their workflow to use the new
> lookaside cache endpoint does not bring them anything, they can just keep doing
> their work the way they have always been.
> If a SIG chooses at some point to start using gitlab, they will have to adjust
> their workflow (if only to change the hostname of the git server) and they will
> have the choice:
> - either keep using the branch structure that git.centos.org imposes (but that
>   time it won't be imposed, it'll be by choice) and then they pick which
>   lookaside upload endpoint they use
> - or they choose a different git branch structure (so another change in their
>   workflow) and there, they won't have the choice and will have to use the new
>   lookaside upload endpoint.
> So it seems simpler to me to keep with the original idea of having two lookaside
> upload endpoint, the current one keeping the current structure and a new one
> using the structure used by CentOS-Stream and Fedora.

So what you're saying is that I could just use the new endpoint? If
that's the case, then I can *still* use this with git.centos.org if I
want. I would just get the flexibility to use the flat layout and I
can cherry-pick commits from Fedora or CentOS Stream as needed.

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