On Mon, Feb 28, 2022 at 09:51:28AM -0500, Neal Gompa wrote: > 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. That is the idea yes. You'll have to adjust your script to point to the new endpoint, but yes you'll be able to use it regardless of where the git repo is hosted. Pierre